zhrb的空間

            BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
            20 隨筆 :: 0 文章 :: 29 評論 :: 0 Trackbacks

          2007年10月18日 #

          jEdit,一款用java編寫的代碼編輯器,可定制性很強,還有功能豐富的插件。
          官方網(wǎng)址:   http://www.jedit.org/
          先上一個官方網(wǎng)站其他人配置的圖片吧。然后隨便寫一些前陣子折騰出來的常用設置





           
           

          常用設置
              Utilities--Global Options
                  Appearance(設置外觀,其中Swing look $ feel如果設置成Metal風格,可以更改菜單等字體大小)
                  Docking(設置插件、組件在編輯器中出現(xiàn)的位置,一般將FileBrowser設置在left,將console與Errolist設置在bottom)
                  Editing(Tab witdh設置tab的空格數(shù),Indent width設置縮進的空格數(shù),Soft(emulated with space)tabs用空格模擬tab)
                  Gutter(編輯區(qū)左邊條狀區(qū)域)
                      1.Line numbers(顯示行號),Gutter font
                  Text Area(編輯區(qū))
                      1.Text font(字體大小)
                  View
                      1.Show full path of buffer in title bar(在標題欄顯示打開文件的完整路徑)
                      2.show buffer switcher(buffer switcher,打開文件切換器)
                  File System Browser
                      1.Default path(打開browser時默認打開的目錄)
                  Plugin Manager
                      1.Update mirror list(插件升級服務器鏡像列表)
                      2.Install plugins in
                          jEdit setting directory(jEdit設置目錄,在windows操作系統(tǒng)下通常是在MyDocument目錄下的 .jedit 目錄)
                          jEdit application directory(jEdit程序目錄)

          jEdit的設置目錄(.jedit)
              存放jEdit設置、插件的目錄(可以備份此文件夾來保存自己的設置與插件)位置(在windows操作系統(tǒng)下通常
          是在MyDocument目錄下的 .jedit 目錄,也可以通過菜單Utilities--TroubleShooting--Activity log查看含有 message字
          樣的信息,一般包含.jedit的信息就是jEdit的設置目錄)

          常用插件及設置
              Plugins--plugin manager
                  Install下可以選擇想要安裝的插件
                  常用的插件
                      console(控制臺)
                      error list(錯誤列表)
                      buffer tab(以標簽頁的方式顯示打開文件)
                      code book(代碼自動完成)
                      java style(修飾代碼風格)
                      javainsight(反編譯)
              插件不僅需要安裝還需要設置,選擇plugin options
              常用設置
                  console(general下選擇字體大小。Character encoding選擇編碼,請選擇GBK,否則無法顯示中文。Compile & run,選擇編程語言對應的編譯器等)
                  buffer tabs(選擇Enable BufferTabs by default)

          先寫這么多比較基礎的設置,還有更多強大功能還有待挖掘。嘿嘿
          posted @ 2010-03-02 22:49 zhrb 閱讀(7927) | 評論 (4)編輯 收藏

          原帖地址:
          http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis

          業(yè)務很重要...呵呵
          posted @ 2008-06-25 23:06 zhrb 閱讀(295) | 評論 (0)編輯 收藏

          轉(zhuǎn)載:奧卡姆剃刀

          發(fā)表于:2008年6月25日 22時59分0秒評論(1) 舉報本文鏈接:http://user.qzone.qq.com/2882888/blog/1214405940
          發(fā)信人: Vulcain (龍★火神), 信區(qū): Philosophy
          標  題: 轉(zhuǎn)載:奧卡姆剃刀
          發(fā)信站: 水木社區(qū) (Wed Jun 25 22:48:38 2008), 站內(nèi)
          Phil Gibbs 著 
          杉原廣 補充
          柯南 譯   
            奧卡姆剃刀(Occam's Razor, Ockham's Razor)是由14世紀邏輯學家、圣方濟各會修
          士奧卡姆的威廉(William of Occam)提出的一個原理。奧卡姆(Ockham)在英格蘭的薩里郡,那是他出生的地方。
            這個原理稱為“如無必要,勿增實體”(Entities should not be multiplied
          unnecessarily)。
              威廉使用這個原理證明了許多結(jié)論,包括“通過思辨不能得出上帝存在的結(jié)論”。這使他不受羅馬教皇的歡迎。  許多科學家接受或者(獨立的)提出了奧卡姆剃刀原理,例如萊布尼茲的“不可觀測事物的同一性原理”和牛頓提出的一個原則:如果某一原因既真又足以解釋自然事物的特性,則我們不應當接受比這更多的原因。
            對于科學家,這一原理最常見的形式是:
            當你有兩個處于競爭地位的理論能得出同樣的結(jié)論,那么簡單的那個更好。
            在物理學中我們使用奧卡姆剃刀切掉形而上學的概念。愛因斯坦的狹義相對論與洛侖茲
          的理論就是一個范例。洛侖茲的理論認為在以太中運動的尺收縮、鐘變慢。愛因斯坦關于空—時變換的方程與洛侖茲方程在鐘慢尺短效應上一致,但是愛因斯坦和龐加萊(法國數(shù)學家——譯注)認為以太不能根據(jù)洛侖茲和麥克斯韋方程組檢測到。根據(jù)奧卡姆剃刀,以太就被排除了。
            這一原理也被用來證明量子力學的不確定性。海森堡從光的量子本性和測量效應中推出了不確定原理。
            史蒂芬·霍金在他的《時間簡史》中解釋說:我們?nèi)匀豢梢韵胂瘢瑢τ谝恍┏匀坏纳铮嬖谝唤M完全地決定事件的定律,它們能夠觀測宇宙現(xiàn)在的狀態(tài)而不必干擾它。然而,我們?nèi)祟悓τ谶@樣的宇宙模型并沒有太大的興趣。看來,最好是采用稱為奧卡姆剃刀的原理,將理論中不能被觀測到的所有特征都割除掉。
            但是“不能確定以太的存在”和“以太的不存在”都不能僅僅根據(jù)奧卡姆剃刀推出。它可以區(qū)分兩個能做出同樣結(jié)論的理論,但是不能區(qū)分其他可能做出不同結(jié)論的理論。實驗的證據(jù)仍然是必需的,并且奧卡姆本人支持經(jīng)驗主義,而不是反對。
            厄恩斯特·馬赫提倡奧卡姆剃刀的一個版本,他稱作“經(jīng)濟原理”,表述為:“科學家應該使用最簡單的手段達到他們的結(jié)論,并排除一切不能被認識到的事物”。把它引入哲學就形成了實證主義哲學,即認為某物存在但無法觀測與根本不存在是一碼事。馬赫影響了愛因斯坦關于時空不是絕對的論述,但是他(馬赫)也把實證主義應用到分子的概念。馬赫和他的追隨者認為分子是形而上學的概念,因為它們太小而不能被直接探測到。這種主張不顧分子論在解釋化學反應和熱力學上的成功。具有諷刺意味的是,當使用經(jīng)濟原理拋棄了以太和絕對參照系的時候,愛因斯坦幾乎同時發(fā)表了一篇關于布朗運動的論文,它證實了分子的實在性,這就打擊了實證主義的使用。這個故事意味著,我們不能盲目使用奧卡姆剃刀。正如愛因斯坦在他的《自傳筆記》中寫道:
            即使是大膽而天才的學者也會因為哲學上的偏見而妨礙他認清事實,這是一個很有趣的例子。
            人們常常引用奧卡姆剃刀的一個強形式,敘述如下:
            如果你有兩個原理,它們都能解釋觀測到的事實,那么你應該使用簡單的那個,直到發(fā)現(xiàn)更多的證據(jù)。
            對于現(xiàn)象最簡單的解釋往往比較復雜的解釋更正確。
            如果你有兩個類似的解決方案,選擇最簡單的。
            需要最少假設的解釋最有可能是正確的。
            ……或者以這種自我肯定的形式出現(xiàn):
            讓事情保持簡單!
            注意到這個原理是如何在上述形式中被加強的。嚴格的說,它們應該被稱為吝嗇定律,或者稱為樸素原則。最開始的時候我們使用奧卡姆剃刀區(qū)分能夠做出相似結(jié)論的理論。現(xiàn)在我們試圖選擇做出不同結(jié)論的理論。這不是奧卡姆剃刀的本意。我們不用檢驗這些結(jié)論嗎?顯然最終不是這樣,除非我們處于理論的早期階段,并且還沒有為實驗做好準備。我們只是為理論的發(fā)展尋求一種指導。
            這個原理最早至少能追溯到亞里士多德的“自然界選擇最短的道路”。亞里士多德在相信實驗和觀測并無必要上走得太遠。樸素原理是一個啟發(fā)式的經(jīng)驗規(guī)則,但是有些人引用它,仿佛它是一條物理學公理。它不是。它在哲學和粒子物理中使用的很好,但是在宇宙學和心理學中就不是特別好,這些領域中的事務往往比你想象的還要復雜。或許引用莎士比亞的一句話要勝過引用奧卡姆剃刀:“天地之大, 赫瑞修, 比你所能夢想到的多出更多”(出自《哈姆雷特》,第一幕,第五景——譯注)
            樸素是主觀的,宇宙并不總是像我們認為的那樣簡單。成功的理論往往涉及到對稱、美與簡單。1939年保羅·狄拉克寫道:
            研究者在把自然法則轉(zhuǎn)變?yōu)閿?shù)學形式的時候,應該為數(shù)學的美而努力。對于簡單和美的需求往往是等價的,然而當它們發(fā)生沖突的時候,后者應該優(yōu)先。
            吝嗇原理不能取代洞察力、邏輯和科學方法。永遠也不能依靠它創(chuàng)造或者維護一個理論。作為正確性的判別方法,只有邏輯上的連貫性和實驗的證據(jù)才是絕對的。狄拉克的理論很成功,他構(gòu)造了電子的相對論場方程,并用它預言了正電子。但是他并沒有主張物理學僅僅應該基于數(shù)學的美。他完全贊同實驗檢驗的必要性。
            最后的結(jié)論來自愛因斯坦,他本身也是一位格言大師。他警告說:
            “萬事萬物應該盡量簡單,而不是更簡單。” 
          --
          如果我們仔細的研究唐詩宋詞,就會發(fā)現(xiàn)里面有全部已知和未知的現(xiàn)代數(shù)學和物理學定理。現(xiàn)在我確知李衛(wèi)公所寫的春宮解說詞里包含了費爾馬定理的證明,但我沒法把它讀出來——這是因為費爾馬定理的證明應該是怎樣的,現(xiàn)在沒有人知道,或者說,現(xiàn)在還沒有人能夠證出費爾馬定理。它就如隋時發(fā)明的避孕套,到唐代就失傳了,因此給了洋鬼子機會,讓他們可以再發(fā)明一次。因為它已經(jīng)失傳,所以我也不知該怎樣解釋這些說明詞。最簡單的解釋是:那是一些性交的訣竅。但是不應該是這樣子的。不應該的原因是有我們存在。我們的任務就是把性交的訣竅解釋成數(shù)學定理,在宋詞里找出相對論,在唐詩里找出牛頓力學。——王小波《紅拂夜奔》
          ※ 來源:·水木社區(qū) http://newsmth.net·[FROM: 210.78.58.*]
          posted @ 2008-06-25 23:03 zhrb 閱讀(384) | 評論 (0)編輯 收藏

          發(fā)信人: kabbesy (Arthas), 信區(qū): Java
          標  題: zz做JAVA開發(fā)要掌握的知識
          發(fā)信站: 水木社區(qū) (Sun Jun  1 23:42:19 2008), 站內(nèi)

          http://www.javaeye.com/topic/183513


          來自http://www.bjsxt.com/zixue/zixuezhilu_1.html


          一:J2SE
          面向?qū)ο螅庋b、繼承、多態(tài)
          內(nèi)存的分析
          遞歸
          集合類、泛型、自動打包與解包、Annotation
          IO
          多線程、線程同步
          TCP/UDP
          AWT、事件模型、匿名類
          正則表達式
          反射機制

          2:數(shù)據(jù)庫(Oracle或者MySQL)
          SQL語句
          多表連接,內(nèi)外連接, 子查詢等
          管理表、視圖、索引、序列、約束等
          樹狀結(jié)構(gòu)存儲
          存儲過程、觸發(fā)器
          數(shù)據(jù)庫設計三范式、

          3:JDBC
          JDBC基礎
          連接池
          樹狀結(jié)構(gòu)存儲與展現(xiàn)
          DataSource & RowSet
          JDBC連接Oracle及MySQL

          4:HTML_CSS_JAVASCRIPT
          html、css、javascript基礎語法
          JavaScript Form判斷
          Dom編程基礎(事件處理等)
          JS常用效果如TreeView、下拉聯(lián)動等
          JS學習方法
          JS調(diào)試方法
          DreamWeaver初步(建立HTML、Table、Form、CSS)等

          5:Servlet & JSP

          tomcat基礎
          servlet基礎
          web.xml配置基礎
          web application的結(jié)構(gòu)
          servlet生命周期
          request response等常用方法
          ServletContext類
          HTTP協(xié)議基礎(GET POST)
          Cookie
          Session
          Application

          JSP的幾種語法(包括JSTL等)注意在項目中練習,不要拘泥于語法細節(jié)而裹步不前。

          6:Struts
          多層架構(gòu)理論
          Model 1 and Model 2
          Struts基本概念
          MVC
          Action與業(yè)務邏輯類的關系
          在Struts與JSP之間傳遞數(shù)據(jù)
          Struts處理流程(控制流)
          Struts TagLib(了解常用的)
          JSTL
          ActionForm
          字段收集
          上傳文件
          類型轉(zhuǎn)換
          DTO
          動態(tài)Action Form
          驗證框架
          ActionForward 轉(zhuǎn)發(fā)與重定向
          動態(tài)生成ActionForward
          全局與局部的ActionForward
          Action Forward Scope
          UnknownActionMapping
          Action的線程安全
          I18N
          如何切換語言環(huán)境
          Struts異常處理機制 程序處理 自動處理 自定義異常處理器
          Struts的多模塊配置

          7:XML
          (XML/XSL、XSLT/DTD、SCHEMA等基礎的概念、關于Java的編程可以暫時扔在一邊)

          8:Hibernate
          OR Mapping原理
          Hibernate基礎開發(fā)步驟
          Hibernate基本接口(重點Session)
          普通屬性映射
          關聯(lián)關系映射
          Native SQL
          inverse lazy cascade
          繼承關系映射
          HQL
          性能優(yōu)化 一級緩存 二級緩存 查詢緩存
          事務與并發(fā) 悲觀鎖、樂觀鎖
          OpenSessionInView
          CurrentSession
          (至于JTA、聯(lián)合主鍵、自然主鍵、動態(tài)主鍵、Any類型 Creteria Queries Intercepter and Event 自定義類型等,可以暫時扔在一邊)

          9:Spring
          IOC/DI
          Spring配置
          Spring架構(gòu)
          AOP及Spring AOP
          聲明式事務(AOP)
          Spring + Hibernate Spring支持Web
          Scope
          (其他的Spring模塊對于自學來說可以暫時扔在一邊)

          10:EJB3.0
          J2EE架構(gòu)基礎(JTA JMS等)
          EJB基礎(地位及基本理論、分類等)
          Annotation
          Ant編譯與部署EJB
          Session Bean
          EJB的依賴注入
          Persistence API
          (可以用JBoss學習EJB3.0)

          11:至于SOA,對于自學的同學來說,暫時不用特別關注。

          梳理一下,你就會發(fā)現(xiàn)東西不是想象中的那么多呀!

          --
          The pact is sealed!


          ※ 來源:·水木社區(qū) newsmth.net·[FROM: 125.33.176.*]

          posted @ 2008-06-02 12:01 zhrb 閱讀(391) | 評論 (1)編輯 收藏

          應用lucene建立簡單的索引軟件
          可以使用lucene進行程序的編寫

          發(fā)信人: minos (卡妙), 信區(qū): NewSoftware
          標 題: 有什么軟件能夠為office文檔建立索引目錄?
          發(fā)信站: 水木社區(qū) (Mon May 12 11:16:28 2008), 站內(nèi)

          就如同word的索引,它是為word里面的文字建立索引。

          能有個方便的軟件能為doc,ppt,xls文檔建立索引,并添加注釋就好了

          posted @ 2008-05-12 21:33 zhrb 閱讀(285) | 評論 (0)編輯 收藏

          主要功能:為用戶群建立群組,群組中含有任務分發(fā)與管理、論壇、發(fā)放通知、資源共享(照片、文件等)。每個用戶都有自己的信息中心,里面包含任務、信息、個人功能。成熟以后,可以為用戶開發(fā)相應的客戶端,類似qq。其實本質(zhì)上就是開發(fā)一個個人信息中心。

          可能涉及的難點:權(quán)限管理、任務分排與管理


          以后的工作:C/S

           

           自己隨便的一個想法,不知道國內(nèi)有沒有已經(jīng)做得很成熟的系統(tǒng)可供參照,希望大家可以幫忙介紹一下。呵呵

          posted @ 2008-04-20 00:54 zhrb 閱讀(317) | 評論 (0)編輯 收藏

          發(fā)信人: gentboy (老流氓,老水車,老男人就是快樂的一家), 信區(qū): Java
          標  題: 填坑:oo的前世今生及后世
          發(fā)信站: 水木社區(qū) (Fri Apr 18 13:27:06 2008), 站內(nèi)

          摘要:需求一直在擴展,邏輯復雜度以更高的速度增加,而人的邏輯處理能力沒有任何變?
          。oo解決了一個stage的問題,但是類似于軟件危機的問題肯定還會出現(xiàn),期待新的邏輯或
          者工具來解決這個問題。


          N多年前,軟件危機的出現(xiàn)基于三個事實,一個是需求迅速增長,功能要求越來越多;再者軟件的復雜度并不是與軟件的體積成正比的,復雜度的增長速度要遠大于代碼的行數(shù)的增長速度。

          還有一個沒有被強調(diào)的原因就是,人的能力是有限的,對于復雜的軟件,沒有任何一個人能掌握所有的邏輯,即使他了解所有的邏輯,也不可能同時考慮到這些邏輯。因此,人們在編寫軟件時,只能在有限的視野內(nèi)工作,這種情況本身就決定了軟件中的缺陷難以避免。

          oo被認為是解決軟件危機一個比較好的方法,主要原因就是oo將整個軟件中的大量邏輯和數(shù)據(jù)封裝起來,從而使得程序員不必關注所有的細節(jié),而只關注與自己負責的部分有關的細節(jié)。這大大減輕了程序員的負擔,從而也使軟件規(guī)模得到了較大的擴大。

          但是,需求仍在繼續(xù)增長,而且邏輯的復雜度又以更快的速度增長。用oo編程的程序員們漸漸感覺到即使大量的邏輯被封裝了,剩下的要處理的邏輯仍然足夠復雜。

          而且,oo也是一把雙刃劍,如果封裝的方法不當,同樣會給別人的開發(fā)造成麻煩。而且不同的程序員往往對同一個應用有著不同的理解。這使得協(xié)作中的沖突很常見。

          因此大量的針對具體應用的framework出現(xiàn)了,比如orm, ejb, struts等等,這些framework從某種程度上定義了某種具體應用的范式,把應用中有共性的部分拿出來,而讓程序員做那些有特性的東西。這又讓程序員少考慮了不少東西。

          到目前為止,framework的確起了不小的作用,也出現(xiàn)了很多超大型的framework,能讓程序員寫很少的代碼就能完成原來可能要18個人干半年才能完成的任務。

          但是,framework也有其本身的缺陷,一個是framework往往本身就足夠復雜,難以學習已經(jīng)是一些大型的framework的通病。另外framework本身也有質(zhì)量問題,過分依賴或者不正確的使用framework的后果同樣是致命的。

          framework替你做的事情越多,程序員往往就越難以使用它,但是如果他做的東西少,程序員就會喊自己做了很多重復勞動。因此這兩者之間要有一個平衡。從這個角度來講,spring做的比jboss要好。

          展望將來,需求的規(guī)模還會繼續(xù)增長,而邏輯的復雜度仍然會以相對于需求的復雜度的指數(shù)形式增長。但是人的腦子跟幾十年前沒什么區(qū)別,還是同時能處理那么多邏輯。尖銳問題肯定會出現(xiàn)。

          但是解決問題的方法呢?單單靠語言特性恐怕已經(jīng)難以再做什么。人們應當再次反思程序這個概念本身,提出新的解決方案。或許人們會開發(fā)出更為實用的framework以定義業(yè)務邏輯,更為智能化的集成開發(fā)/協(xié)作環(huán)境工具來擴展我們的大腦,或者其它...


          --


             晶晶姑娘是個好姑娘


          ※ 修改:·gentboy 于 Apr 18 13:28:32 2008 修改本文·[FROM: 210.13.85.*]
          ※ 來源:·水木社區(qū) newsmth.net·[FROM: 210.13.85.*]

          posted @ 2008-04-19 10:34 zhrb 閱讀(260) | 評論 (0)編輯 收藏

          發(fā)信人: NewXin (睡貓|糖果氣泡), 信區(qū): ITExpress
          標  題: 技術(shù)是一種加速器 但重要的不是技術(shù)
          發(fā)信站: 水木社區(qū) (Mon Apr 14 12:32:38 2008), 站內(nèi)

          噴嚏網(wǎng):原創(chuàng) www.dapenti.com
          (一)

           多年以前,我有個學生在一家做“工作流引擎”的軟件小公司里工作。他遇到了一些麻煩

           什么是“工作流引擎”?簡單地說,是一種可以自動執(zhí)行流程的工作元件:使用者設置好
          基本的參數(shù),該元件就能按照預先設定的工作步驟和業(yè)務的流程往下走。

           聽起來很酷,看上去很美。

           學生的麻煩是:公司的產(chǎn)品做得歪瓜劣棗的,開發(fā)人員不夠,人員參差不齊。總的說來,
          技術(shù)問題很多,公司也不太重視。

           他來問我他該怎么辦。

           我說:其實,這不是技術(shù)的問題。而是在于以公司這樣的實力進入這樣的小眾市場,完全
          沒有能力。高端的“工作流引擎”肯定有市場,但是都是很多IT的老大才做。中低端的應用
          ,需要的不是自動化軟件,而是人事關系。這就更與技術(shù)無關。

           技術(shù)是很好的想法,但是沒有生根的地方。從商業(yè)和個人投資來看,就沒有商業(yè)價值。

           我給他的建議是:趕快離場,做點其他的。


          (二)

           我在軟件行業(yè)做過10年以上的技術(shù)工作。我知道技術(shù)人員在某一個階段上會有一個通病,
          就是:太把技術(shù)當回事兒。

           怎么說呢?就是說總是從技術(shù)的觀點去考慮問題,想到希望發(fā)生的事情,而不會從一個普
          通人的角度看待現(xiàn)實。

           理解技術(shù)是好事情,你可以飛快地想象到未來,看到一種趨勢。但是,你一定要明白,這
          種趨勢可能發(fā)生,也可能只是一種錯覺。

           技術(shù)是一種加速器。但是你不知道,這是成功的加速器,還是速死的加速器。

           技術(shù)的思維角度,如果放錯了位置,很多時候,會成為認知上的障礙。你以為你看到的東
          西是重要的,其實,人們根本不是按你想象的方式需要,或者生活。

           技術(shù)是一種異化過程。當你以為你是專業(yè)人士的時候,你也有可能忘記:作為普通人,他
          們的感覺應該是什么樣子。


          (三)

           我經(jīng)常在小區(qū)的周圍散步。我看見各種各樣的小商鋪,開辦的熱火朝天。我最喜歡的是一
          家小面館。這些店鋪的生意各不相同,但都有一個共同之處:跟我的職業(yè)沒有任何的關系。也就是說,他們都是一些遠離互聯(lián)網(wǎng)的又小又好的生意。比如:洗衣店、蛋糕房、小型超市。

           我很清楚,至少在我活著的時候,我還不能從網(wǎng)絡上下載一碗面。這種想法,總是提醒我
          注意在偉大的傳統(tǒng)行業(yè)面前,保持謙卑。

           看著很多2-3個人,10來個人開辦的火熱的小生意。我就在想:什么樣的生意才算是好生意呢?能活著的生意,當然是好的。這些生意還應該有如下的特點:

           【1】有廣泛的需求,無認知障礙,應用的技能簡單,如:吃飯、穿衣。這是誰都需要,誰都會的事情;

           【2】市場龐大,不是只需幾家就能搞定的,而且要方便。需求是有循環(huán)、反復的;

           【3】滿足需求的產(chǎn)品種類獨特,或者豐富;

           作為技術(shù)的互聯(lián)網(wǎng),是如何改變了傳統(tǒng)的市場?

           優(yōu)勢:

           【1】技術(shù)跨越了地域的限制,信息加速,需求被聚合;

           【2】信息流動得更快,用戶間的接觸增加,消費變得可以評價;

           【3】營銷的方式發(fā)生了根本的變化

           劣勢:

           【1】信任成本的建立很高;

           【2】商品的可接觸成本很高;

           【3】需求到消費的轉(zhuǎn)換率不高;

           這樣看來,我們就很容易理解這樣的事實:互聯(lián)網(wǎng)上的生意看著人多,其實一點都不便宜
          。而且,還不太容易存活。難怪那么多人,成天鬧著要忽悠風投。

           能自個賺錢了,還需要風投干嘛。


          (四)

           任何一個成功的互聯(lián)網(wǎng)項目或產(chǎn)品,至少應該具有這樣的基本特征:

           【1】首先要是一個很好的生意。

           上面說過了,無論是用月球的技術(shù)還是火星的技術(shù),生意還是生意,生意的本質(zhì)并沒有改
          變。

           【2】要找到一個跟這種生意匹配的業(yè)務形式,或是商業(yè)模式:

           扎堆,是人多。人多好辦事,但是成本也高。而且,面越廣,實質(zhì)就越少。

           任何一個商業(yè)系統(tǒng)都是中性系統(tǒng),不可能是完美的系統(tǒng)。所以說,長尾是一種浪漫的說法
          。對長尾的正確理解應該是:傳統(tǒng)系統(tǒng)能做5個特性的話。長尾目前也最多能擴展到10或者
          15。

           如果首先有80/20的業(yè)務存在,那么互聯(lián)網(wǎng)的長尾就會看上去非常優(yōu)美。如果沒有,長尾就等于是零。

           所以,那些辦起博客,相冊就叫web 2.0的網(wǎng)站,肯定是:非死不可(FaceBook) 。同時
          ,如果能符合上面的兩個條件的社區(qū)或管它叫什么的網(wǎng)站,卻會活得很好。

           我相信基本的一點:當所有人談論商業(yè)模式,談錢的時候。他們都要回到最根本的問題上
          --商業(yè)的需求從何而來,是怎么樣的一個規(guī)模,在某個具體的平臺下,技術(shù)能提供怎么樣的突破,該如何提供什么樣的產(chǎn)品和服務的形式來滿足這些需求。

           雖然有些社區(qū)是非死不可了,但我仍然看好這樣的一類網(wǎng)站:婚戀市場,如世紀佳緣類的
          ,還有育兒市場,如寶寶樹之類的。

           這樣的網(wǎng)站首先是有一個無限廣闊的市場空間,而且網(wǎng)站的內(nèi)容跟業(yè)務結(jié)合的非常緊密。
          只要不犯大的錯誤,堅持下去,這樣的業(yè)務本身不僅可以賺大錢,而且可以一直做很久。因為,很多業(yè)已存在的傳統(tǒng)生意,被證明已經(jīng)是好生意。

           我一直認為:web 2.0類的網(wǎng)站發(fā)展,是電子商務普及的前哨戰(zhàn)。很多的炮灰會成就電子商務的明天。我敢打賭:活下來的都是不太關心是2還是1的人。

           最后,提一下作為web 2先驅(qū)的豆瓣:盡管?

           如果首先有80/20的業(yè)務存在,那么互聯(lián)網(wǎng)的長尾就會看上去非常優(yōu)美。如果沒有,長尾就等于是零。

           所以,那些辦起博客,相冊就叫web 2.0的網(wǎng)站,肯定是:非死不可(FaceBook) 。同時
          ,如果能符合上面的兩個條件的社區(qū)或管它叫什么的網(wǎng)站,卻會活得很好。

           我相信基本的一點:當所有人談論商業(yè)模式,談錢的時候。他們都要回到最根本的問題上
          --商業(yè)的需求從何而來,是怎么樣的一個規(guī)模,在某個具體的平臺下,技術(shù)能提供怎么樣的突破,該如何提供什么樣的產(chǎn)品和服務的形式來滿足這些需求。

           雖然有些社區(qū)是非死不可了,但我仍然看好這樣的一類網(wǎng)站:婚戀市場,如世紀佳緣類的
          ,還有育兒市場,如寶寶樹之類的。

           這樣的網(wǎng)站首先是有一個無限廣闊的市場空間,而且網(wǎng)站的內(nèi)容跟業(yè)務結(jié)合的非常緊密。
          只要不犯大的錯誤,堅持下去,這樣的業(yè)務本身不僅可以賺大錢,而且可以一直做很久。因為,很多業(yè)已存在的傳統(tǒng)生意,被證明已經(jīng)是好生意。

           我一直認為:web 2.0類的網(wǎng)站發(fā)展,是電子商務普及的前哨戰(zhàn)。很多的炮灰會成就電子商務的明天。我敢打賭:活下來的都是不太關心是2還是1的人。

           最后,提一下作為web 2先驅(qū)的豆瓣:盡管開始人多勢大了,也加了很多功能,但是,本身的特色也在喪失。豆瓣賦予了自己太多的使命。我覺得謙卑一點還是比較好。我喜歡作為讀
          書工具的豆瓣,而不太喜歡作為交友工具的豆瓣。 一會兒是關注,一會兒又是好友。一會
          兒是廣播,一會兒又是日記。

           如果功能太多,只能讓人不知所措。面越廣,實質(zhì)就越少。

           我最喜歡《玩具總動員》里面主人翁的第一句話:focus,speed!

           我的理解是:專注,才有速度。

          --

          ※ 來源:·水木社區(qū) http://newsmth.net·[FROM: 202.108.130.*]

          posted @ 2008-04-14 19:31 zhrb 閱讀(303) | 評論 (0)編輯 收藏

          發(fā)信人: seableu (地球是天上一顆星), 信區(qū): JavaExpress
          標  題: 面向?qū)ο蟮乃季S方法 [zz]
          發(fā)信站: BBS 水木清華站 (Sat Jan  8 20:02:47 2005), 站內(nèi)

              剛才看到一篇文章,是有關面向?qū)ο蟮乃季S方法的,感覺對我很有啟發(fā),貼出來大家一起看,呵呵。
              原文鏈接:http://blog.csdn.net/wooaoo/archive/2004/07/30/56163.aspx

          ------------------------------------------------------------------------
          面向?qū)ο蟮乃季S方法
          作者:范凱
          E-mail: robbin_fan@yahoo.com.cn

          我是從學習Java編程開始接觸OOP(面向?qū)ο缶幊?,剛開始使用Java編寫程序的時候感覺很別扭,因為我早以習慣用C來編寫程序,很欣賞C的簡潔性和高效性,喜歡C簡練而表達能力豐富的風格,特別忍受不了Java運行起來慢吞吞的速度,相對冗長的代碼,而且一個很簡單的事情,要寫好多類,一個類調(diào)用一個類,心里的抵觸情緒很強。

          我對Java的面向?qū)ο蟮奶匦宰聊チ季茫哉J為有所領悟,也開始有意識的運用OOP風格來寫程序,然而還是經(jīng)常會覺得不知道應該怎樣提煉類,面對一個具體的問題的時候,會覺得腦子里千頭萬緒的,不知道怎么下手,一不小心,又會回到原來的思路上去。

          舉個例子,要發(fā)廣告郵件,廣告郵件列表存在數(shù)據(jù)庫里面。倘若用C來寫的話,一般會這樣思考,先把郵件內(nèi)容讀入,然后連接數(shù)據(jù)庫,循環(huán)取郵件地址,調(diào)用本機的qmail的sendmail命令發(fā)送。

          然后考慮用Java來實現(xiàn),既然是OOP,就不能什么代碼都塞到main過程里面,于是就設計了三個類:

          一個類是負責讀取數(shù)據(jù)庫,取郵件地址,調(diào)用qmail的sendmail命令發(fā)送;
          一個類是讀郵件內(nèi)容,MIME編碼成HTML格式的,再加上郵件頭;
          一個主類負責從命令讀參數(shù),處理命令行參數(shù),調(diào)用發(fā)email的類。

          把一件工作按照功能劃分為3個模塊分別處理,每個類完成一件模塊任務。

          仔細的分析一下,就會發(fā)現(xiàn)這樣的設計完全是從程序員實現(xiàn)程序功能的角度來設計的,或者說,設計類的時候,是自低向上的,從機器的角度到現(xiàn)實世界的角度來分析問題的。因此在設計的時候,就已經(jīng)把程序編程實現(xiàn)的細節(jié)都考慮進去了,企圖從底層實現(xiàn)程序這樣的出發(fā)點來達到滿足現(xiàn)實世界的軟件需求的目標。

          這樣的分析方法其實是不適用于Java這樣面向?qū)ο蟮木幊陶Z言,因為,如果改用C語言,封裝兩個C函數(shù),都會比Java實現(xiàn)起來輕松的多,邏輯上也清楚的多。

          我覺得面向?qū)ο蟮木柙谟诳紤]問題的思路是從現(xiàn)實世界的人類思維習慣出發(fā)的,只要領會了這一點,就領會了面向?qū)ο蟮乃季S方法。

          舉一個非常簡單的例子:假使現(xiàn)在需要寫一個網(wǎng)頁計數(shù)器,客戶訪問一次頁面,網(wǎng)頁計數(shù)器加1,計數(shù)器是這樣來訪問的

          http://hostname/count.cgi?id=xxx

          后臺有一個數(shù)據(jù)庫表,保存每個id(一個id對應一個被統(tǒng)計訪問次數(shù)的頁面)的計數(shù)器當前值,請求頁面一次,對應id的計數(shù)器的字段加1(這里我們忽略并發(fā)更新數(shù)據(jù)庫表,出現(xiàn)的表鎖定的問題)。

          如果按照一般從程序?qū)崿F(xiàn)的角度來分析,我們會這樣考慮:首先是從HTTP GET請求取到id,然后按照id查數(shù)據(jù)庫表,獲得某id對應的訪問計數(shù)值,然后加1,更新數(shù)據(jù)庫,最后向頁面顯示訪問計數(shù)。

          現(xiàn)在假設一個沒有程序設計經(jīng)驗的人,他會怎樣來思考這個問題的呢?他會提出什么樣的需求呢?他很可能會這樣想:

          我需要有一個計數(shù)器,這個計數(shù)器應該有這樣的功能,刷新一次頁面,訪問量就會加1,另外最好還有一個計數(shù)器清0的功能,當然計數(shù)器如果有一個可以設為任意值的功能的話,我就可以作弊了。

          做為一個沒有程序設計經(jīng)驗的人來說,他完全不會想到對數(shù)據(jù)庫應該如何操作,對于HTTP變量該如何傳遞,他考慮問題的角度就是我有什么需求,我的業(yè)務邏輯是什么,軟件應該有什么功能。

          按照這樣的思路(請注意,他的思路其實就是我們平時在生活中習慣的思維方式),我們知道需要有一個計數(shù)器類 Counter,有一個必須的和兩個可選的方法:

          getCount()  // 取計數(shù)器值方法
          resetCounter()  // 計數(shù)器清0方法
          setCount()  // 設計數(shù)器為相應的值方法

          把Counter類完整的定義如下:

          public class Counter {
            public int getCount(int id) {}
            public void resetCounter(int id) {}
            public void setCount(int id, int currentCount) {}
          }

          解決問題的框架已經(jīng)有了,來看一下如何使用Counter。 在count.cgi里面調(diào)用Counter來計數(shù),程序片斷如下:

            //  這里從HTTP環(huán)境里面取id值
            ...
            Counter myCounter = new Counter();  // 獲得計數(shù)器
            int currentCount = myCounter.getCount(id);  // 從計數(shù)器中取計數(shù)
            //  這里向客戶瀏覽器輸出
            ...

          程序的框架全都寫好了,剩下的就是實現(xiàn)Counter類方法里面具體的代碼了,此時才去考慮具體的程序語言實現(xiàn)的細節(jié),比如,在getCount()方法里面訪問數(shù)據(jù)庫,更新計數(shù)值。

          從上面的例子中看到,面向?qū)ο蟮乃季S方法其實就是我們在現(xiàn)實生活中習慣的思維方式,是從人類考慮問題的角度出發(fā),把人類解決問題的思維方式逐步翻譯成程序能夠理解的思維方式的過程,在這個翻譯的過程中,軟件也就逐步被設計好了。

          在運用面向?qū)ο蟮乃季S方法進行軟件設計的過程中,最容易犯的錯誤就是開始分析的時候,就想到了程序代碼實現(xiàn)的細節(jié),因此封裝的類完全是基于程序?qū)崿F(xiàn)邏輯,而不是基于解決問題的業(yè)務邏輯。

          學習JDBC編程的經(jīng)典錯誤問法是:“我怎樣封裝對數(shù)據(jù)庫的select操作?”

          面向?qū)ο蟮脑O計是基于解決業(yè)務問題的設計,而不是基于具體編程技術(shù)的設計。我不會去封裝select語句的,我只封裝解決問題的業(yè)務邏輯,對數(shù)據(jù)庫的讀取是在業(yè)務邏輯的編碼實現(xiàn)階段才去考慮的問題。

          回過頭看上面那個發(fā)廣告郵件的例子,應該如何應用面向?qū)ο蟮乃季S方法呢?

          對于一個郵件來說,有郵件頭,郵件體,和郵件地址這三個屬性,發(fā)送郵件,需要一個發(fā)送的方法,另外還需要一個能把所有郵件地址列出來的方法。所以應該如下設計:

          類JunkMail

          屬性:
            head
            body
            address
          方法:
            sendMail()    // 發(fā)送郵件
            listAllMail() // 列郵件地址

          用Java來表示:

          public class JunkMail {
            private String head;
            private String body;
            private String address;
            public JunkMain() {  // 默認的類構(gòu)造器
              // 從外部配置文件讀郵件頭和郵件體
              this.head=...;
              this.body=...;
            }

            public static boolean sendMail(String address) {
              //  調(diào)用qmail,發(fā)送email
            }

            public static Collection listAllMail() {
              //  訪問數(shù)據(jù)庫,返回一個郵件地址集合
            }
          }

          當把JunkMail設計好了以后,再調(diào)用JunkMail類完成郵件的發(fā)送,將是非常輕松的事情。

          如果說傳統(tǒng)的面向過程的編程是符合機器運行指令的流程的話,那么面向?qū)ο蟮乃季S方法就是符合現(xiàn)實生活中人類解決問題的思維過程。

          在面向?qū)ο蟮能浖治龊驮O計的時候,要提醒自己,不要一上來就去想程序代碼的實現(xiàn),應該拋開具體編程語言的束縛,集中精力分析我們要實現(xiàn)的軟件的業(yè)務邏輯,分析軟件的業(yè)務流程,思考應該如何去描述和實現(xiàn)軟件的業(yè)務。畢竟軟件只是一個載體,業(yè)務才是我們真正要實現(xiàn)的目標。

          但是在設計過程中,心里卻往往在擔心,如果我完全不去考慮程序代碼的實現(xiàn)的話,那么我怎么知道我的設計一定合理呢?我怎么知道我設計的類、接口一定可以實現(xiàn)呢?(是個問題:()所以經(jīng)常可以看到的現(xiàn)象就是:

          在設計過程中,雖然知道不能過早考慮代碼實現(xiàn),但是每設計一個類,一個接口,心里都要不知不覺的用自己熟悉的編程語言大概的評估一下,看看能否編出來,因此,一不小心,就會又回到按照程序功能實現(xiàn)的思路進行設計的老路上去了。

          舉個例子來說明,在做Web程序設計的時候,經(jīng)常要遇到分頁顯示數(shù)據(jù)的情況。比如說需要把系統(tǒng)中所有的用戶都列出來這樣的功能。假設使用User類來表示用戶,增加用戶addUser(),刪除用戶deleteUser(),查詢所有用戶listUsers()方法。而數(shù)據(jù)庫中有一個user表,一條記錄是一個用戶的信息。下面考慮一下User類的方法的實現(xiàn):

          addUser()和deleteUser()方法都好實現(xiàn),就是對數(shù)據(jù)庫增加記錄和刪除記錄。對于listUsers()方法,其實就是對user表的select,取出一個記錄集。但是該怎么從listUsers()方法中得到所有用戶的列表呢?

          一個方法調(diào)用的返回值只有一個,沒有多個,所以很多情況下采用的辦法就是返回值定義為集合類型,比如Vector。這樣就可以在listUsers()方法的具體代碼實現(xiàn)的時候,從數(shù)據(jù)庫依次取出一個個記錄,插入到Vector里面來。在主程序里面,調(diào)用listUsers()方法可以返回一個Vector,然后再對Vector遍歷操作,就可以得到用戶列表了。

          public class User {

            public static void addUser(...) {
              //  數(shù)據(jù)庫insert一條記錄
            }

            public static void deleteUser(...) {
              //  數(shù)據(jù)庫delete一條記錄
            }

            public Vector listUsers(...) {
              //  數(shù)據(jù)庫select結(jié)果放到一個集合里面
            }
          }

          這樣的設計基本合理,但是仍然有點小問題。因為在設計的時候,就考慮到了用Java的集合類Vector來實現(xiàn)對不定長數(shù)據(jù)集的存放,因而違反了面向?qū)ο笤O計的一個原則:在設計的時候不應過早的考慮具體程序語言的實現(xiàn)。所以必須用抽象的方法,和具體實現(xiàn)無關的方法來表達業(yè)務邏輯。

          我們知道,通常對具有集合特征的數(shù)據(jù)結(jié)構(gòu)進行遍歷通常可以使用next和hasNext方法,next實現(xiàn)取下一個用戶,hasNext判斷是否還有元素。 因此我們定義一個接口Iterator,這個接口中定義兩個方法next和hasNext:

          public interface Iterator {
            public boolean hasNext() {}
            public Object next()  {}
          }

          而User類的listUses方法返回值改為Iterator接口的實現(xiàn)類:

          public class User {
            ...
            public Iterator listUsers() {
            }
            ...
          }

          這樣就把User類的設計和具體的實現(xiàn)方法分離開了,因為此時任何實現(xiàn)了next()和hasNext()方法的類都可以做為listUsers的返回值,都可以被用來表達“用戶列表”,而不僅僅可以使用Vector而已。比如,我可以用ArrayList來表達用戶列表,因為ArrayList也實現(xiàn)了Iterator,當然我也可以自己專門寫一個類來存放用戶列表,只要實現(xiàn)next()和hasNext()方法就行了。

          這樣在具體的編寫代碼的時候,程序員具有了最大的靈活性,可以根據(jù)具體的情況,采用不同的編程方法來存放用戶列表。特別是降低了程序的耦合度,提高了程序的可移植性。對于上面那個JunkMail的listAllMail()方法也同樣應該改為接口類型。

          然后,在主程序里面就這樣來使用User類的listUsers方法:

          User myUser = new User();
          Iterator iterator = myUser.listUsers();
          while (iterator.hasNext()) {
            iterator.next();
          }

          這樣就可以完全不用考慮程序代碼實現(xiàn)了,從高層次上把功能抽象出來,定義成為接口,同時又可以把系統(tǒng)設計的很合理,完全根據(jù)業(yè)務的需求來進行設計。

          結(jié)語

          通過上面的幾個例子的設計說明,使用面向?qū)ο蟮乃季S方法,其實是一個把業(yè)務邏輯從具體的編程技術(shù)當中抽象出來的過程,而這個抽象的過程是自上而下的,非常符合人類的思維習慣,也就是先不考慮問題解決的細節(jié),把問題的最主要的方面抽象成為一個簡單的框架,集中精力思考如何解決主要矛盾,然后在解決問題的過程中,再把問題的細節(jié)分割成一個一個小問題,再專門去解決細節(jié)問題。

          因而一旦牢牢的抓住了這一點,你就會發(fā)現(xiàn)在軟件設計和開發(fā)過程中,你自己總是會不知不覺的運用面向?qū)ο蟮乃季S方法來設計和編寫程序,并且程序的設計和開發(fā)也變得不再那么枯燥,而一個合理運用面向?qū)ο蠹夹g(shù)進行設計和架構(gòu)的軟件,更是具備了思維的藝術(shù)美感。

          最后,愿面向?qū)ο蟮乃季S方法也能給您的程序設計之路帶來創(chuàng)作的樂趣。



          --
                  有一名年輕人名字叫seableu,
                  他的速度遠勝于光,
                  一天,他啟程旅行,
                  但卻于前一天就返回了!


          ※ 來源:·BBS 水木清華站 http://smth.org·[FROM: 212.194.215.*]

          posted @ 2008-03-25 17:26 zhrb 閱讀(446) | 評論 (3)編輯 收藏

          轉(zhuǎn)某個大牛關于需求分析的一段評論:

          發(fā)信人: zms (來福), 信區(qū): Java
          標  題: Re: 這個怎么解決?
          發(fā)信站: 水木社區(qū) (Tue Mar 18 11:58:58 2008), 站內(nèi)

          這么解決:

          1.  需求分析,把 當前 的需求搞清楚
          2.  需求分析,把 未來 可能出現(xiàn) 的需求搞清楚
          3.  需求分析,把 可能擴展 以及發(fā)揮 的需求搞清楚
          4.  需求分析,預料 可能出現(xiàn) 的 變態(tài) 需求
          5.  需求分析, 把 以上需求加以 綜合 引申
          6.  照需求設計編碼之,沒有什么特殊之處,愛采用什么技術(shù)都行

          posted @ 2008-03-18 12:47 zhrb 閱讀(740) | 評論 (1)編輯 收藏

               摘要: 實現(xiàn)Linux應用二進制兼容的意義


          隨著操作系統(tǒng)技術(shù)的發(fā)展從注重性能到注重服務,操作系統(tǒng)所配套的服務軟件多少以及開發(fā)環(huán)境是否易用就成為決定一個操作系統(tǒng)生命力的關鍵因素。微軟今日壟斷地位的形成,就得益于微軟完整的應用軟件體系。而以前國產(chǎn)操作系統(tǒng)未能形成良性發(fā)展的局面,也是受阻于沒有完整的軟件體系的配套。所以,注重配套服務軟件開發(fā),提高系統(tǒng)適用面就成為Kylin操作系統(tǒng)在設計和開發(fā)只初就統(tǒng)籌考慮的問題。


          通過自己的力量,從頭為Kylin操作系統(tǒng)開發(fā)來所有應用軟件時間不允許,人力、物力上不可行。它山之石可以攻玉,我們必須借助目前現(xiàn)有成熟的應用軟件體系才能在較短時間內(nèi)構(gòu)成較完整的應用軟件體系,滿足用戶的基本需求。  閱讀全文
          posted @ 2008-03-06 22:27 zhrb 閱讀(660) | 評論 (0)編輯 收藏

          原帖地址:
          http://www.runpc.com.tw/content/168/168E18_1.aspx
          2008年必須知道的新技術(shù)——軟體開發(fā)篇 [zz]
          2008年必須知道的新技術(shù)─軟件開發(fā)篇
          文/蔡學鏞.匯整/編輯部
          ________________________________________
          新 技術(shù)不斷出現(xiàn),其中某些技術(shù)很可能會成為我們不可避免的挑戰(zhàn),因此每隔幾年,我們
          都應該審視我們未來應該注意的技術(shù)有哪些。透過本文章,和大家分享我的技 術(shù)觀察與建
          議。 當然對大多數(shù)的開發(fā)者來說,Visual Studio 2008是今年的重頭戲,這也是Windows
          Vista推出之后的第一個全新的Visual Studio版本,不容我們輕忽。但依照慣例,微軟還是
          會用大量的技術(shù)資料、研討會、資源…等,把我們喂得飽飽的。我就不用在此多介紹了。
          另外RIA也是今年的重點,最值得注意的RIA技術(shù)當然是WPF/Sliverlight和AIR/Flash。關于
          RIA,許多文章都已經(jīng)有提及,我也 不在此贅述。我想在這篇文章中帶領大家認識的,是比
          較不一樣的新挑戰(zhàn)。

          多核心與網(wǎng)絡運算
          穆爾定律觀察到,每隔兩年,在單一芯片上能做的事會加倍。但是穆爾定律繞道而行,不是
          產(chǎn)生越來越快的處理器(這幾年CPU頻率的增加已經(jīng)趨緩), Intel與AMD等公司的作法是產(chǎn)
          生多核心的裝置:單一芯片內(nèi)包含兩個、四個、甚至更多個處理器。如果你的程序沒有共時
          (concurrent),則一 次只會在單一個處理器上執(zhí)行,使用者會認為你的程序很慢。對于
          編程員來說,如何充分運用多核心的運算威力,變成一個重要的課題。 而網(wǎng)絡的連結(jié),造
          成分布式的環(huán)境;如何用更有效的方式進行分布式編程,也會越來越重要。 結(jié)合了上面了
          兩點因素,Erlang正開始獲得大家的重視。

          Erlang解決了現(xiàn)今開發(fā)者面對的最迫切問題之一:如何寫出可靠、共時(concurrent)、高
          效能的系統(tǒng)。Erlang已經(jīng)在世界各地被許多公司 廣泛地采用,這些公司用它來產(chǎn)生可靠、
          有效率、具規(guī)模彈性的應用。 Erlang是一個編程語言,它的設計目的,正是為了幫助我們
          建立極度平行、分散、容錯(fault-tolerant)的系統(tǒng)。它已經(jīng)被商業(yè)采用運行多 年,建
          立出許多容錯系統(tǒng)。多年來,這些Erlang所建立的系統(tǒng)出錯率極低。 Erlang程序在多核心
          的計算機上執(zhí)行時,會充分運用系統(tǒng):這意味透過本文章,和大家分享我的技 術(shù)觀察與建
          議。 當然對大多數(shù)的開發(fā)者來說,Visual Studio 2008是今年的重頭戲,這也是Windows
          Vista推出之后的第一個全新的Visual Studio版本,不容我們輕忽。但依照慣例,微軟還是
          會用大量的技術(shù)資料、研討會、資源…等,把我們喂得飽飽的。我就不用在此多介紹了。
          另外RIA也是今年的重點,最值得注意的RIA技術(shù)當然是WPF/Sliverlight和AIR/Flash。關于
          RIA,許多文章都已經(jīng)有提及,我也 不在此贅述。我想在這篇文章中帶領大家認識的,是比
          較不一樣的新挑戰(zhàn)。

           多核心與網(wǎng)絡運算
          穆爾定律觀察到,每隔兩年,在單一芯片上能做的事會加倍。但是穆爾定律繞道而行,不是
          產(chǎn)生越來越快的處理器(這幾年CPU頻率的增加已經(jīng)趨緩), Intel與AMD等公司的作法是產(chǎn)
          生多核心的裝置:單一芯片內(nèi)包含兩個、四個、甚至更多個處理器。如果你的程序沒有共時
          (concurrent),則一 次只會在單一個處理器上執(zhí)行,使用者會認為你的程序很慢。對于
          編程員來說,如何充分運用多核心的運算威力,變成一個重要的課題。 而網(wǎng)絡的連結(jié),造
          成分布式的環(huán)境;如何用更有效的方式進行分布式編程,也會越來越重要。 結(jié)合了上面了
          兩點因素,Erlang正開始獲得大家的重視。

          Erlang解決了現(xiàn)今開發(fā)者面對的最迫切問題之一:如何寫出可靠、共時(concurrent)、高
          效能的系統(tǒng)。Erlang已經(jīng)在世界各地被許多公司 廣泛地采用,這些公司用它來產(chǎn)生可靠、
          有效率、具規(guī)模彈性的應用。 Erlang是一個編程語言,它的設計目的,正是為了幫助我們
          建立極度平行、分散、容錯(fault-tolerant)的系統(tǒng)。它已經(jīng)被商業(yè)采用運行多 年,建
          立出許多容錯系統(tǒng)。多年來,這些Erlang所建立的系統(tǒng)出錯率極低。 Erlang程序在多核心
          的計算機上執(zhí)行時,會充分運用系統(tǒng):這意味著你的Erlang程序在四核心的計算機上會比單
          核心的計算機上快,而最棒的是,你完全不需 要更動程序,就有如此顯著的效果。當然,
          你可以用別的語言做到和Erlang一樣的事,但是只會事倍功半。
           GUI
          在Windows 3.x時代,Charles Petzold的Windows程序設計著作是大家必讀的經(jīng)典。有人要
          他為Windows NT也寫一本這樣的書,他卻說:等NT賣千萬套再說吧!這顯示出Charles
          Petzold一直都是屬于「大眾技術(shù)類」的作家,當他在2007年也寫出一本3D程序書籍時,或
          許代表我們3D程序設計的時代已經(jīng)揭開序幕。 Vista與MacOS都早已經(jīng)進入3D的時代。如何
          運用3D的API,開發(fā)出更炫目的設計,會是未來GUI吸引使用者的重點。

           Java
          除了Sun官方的Java,Google剛推出的手機平臺Android也是一種Java平臺。更不用提AIR也
          可以算是廣義的Java平臺(太多地方都 類似Java,連Bytecode檔案格式都很類似)。由于
          Android和AIR都不是弱勢的平臺,所以可能會造成Java的分歧。 但是雖然彼此分歧,也算
          各有其所。Java用在Web后端,Android用在手機,AIR用在Web前端。

           Shell
          30多年來,沿襲自Unix的Shell用法,再怎么改變,終究是換湯不換藥。在微軟推出
          PowerShell之后,Shell終于有了截然不同的面貌和 更強大的威力。運用.NET,整合各種對
          象模型(WMI、COM…),PowerShell名稱中有出現(xiàn)Power(威力)絕非浪得虛名。相當值得
          系統(tǒng)管 理員與編程員學習。 但是提醒你,PowerShell或許不難上手,但是有太多陷阱。一
          開始不熟悉這些陷阱時,會吃不少苦頭。

           語言
          從Tiobe的編程語言需求排名,可以看到Ruby與D語言快速進入主流;Perl消退,被Python超
          越;C# 慢慢上漲、Java與C維持平盤、C++ 漸漸低落;Delphi持續(xù)探底,Lua往上猛竄。 估
          計未來幾年,OO語言還是主流,函數(shù)語言漸漸流行。目前主要是學術(shù)圈在使用函數(shù)語言(
          Functional Language),但確實有相當多跡象顯示,函數(shù)編程有可能會漸漸走入業(yè)界。

          自己寫parser。除非你用像REBOL這樣的語言,否則寫parser應該會是很痛苦的事,幸好你
          可以利用 ANTLR幫你產(chǎn)生parser。目前ANTLR已經(jīng)支持相當多主流語言,ANTLR相當值得學習

           Security
          網(wǎng)絡的時代,危機四伏。許多系統(tǒng)的保全都是事后加上的,這樣子很危險。事先良好的規(guī)劃
          是建立保全環(huán)境的關鍵,而規(guī)劃的最佳工具是模型塑造 (modeling)。用形式上的作法,
          尋找威脅與弱點,以破除攻擊。 STRIDE是相當知名的威脅分類模型。STRIDE可以用來為系
          統(tǒng)的重大威脅進行分類。威脅正是攻擊者希望發(fā)生的事,也就是我們不希望發(fā)生的事。如果
          我 們塑模所有的STRIDE威脅分類,我們就有很高的機會可以涵蓋大多數(shù)重要的領域。

          STRIDE是Spoofing(偽造)、Tampering(竄改)、Repudiation(否認)、Information
          Disclosure(信息揭露)、Denial of Service(服務阻斷)、與Elevation of Privilege
          (特權(quán)提升)的縮寫。 建立保全模型,有三個部分:威脅、資產(chǎn)、與緩解(mitigation)
          。透過塑模了解你的系統(tǒng)可能面臨的威脅,并緩解問題,保護資產(chǎn)。不要讓你的程序, 布
          滿弱點,危害大眾,程序員必須及早補充Security相關的知識,將STRIDE應用在開發(fā)過程中

           整體而言
          簡單才是王道。PHP、RoR、REST會流行正是因為簡單才是王道。復雜的技術(shù)固然有許多美好
          的愿景(彈性、效率、跨平臺…),但是大多數(shù)的 developer尚未看到愿景,就已經(jīng)半途陣
          亡。復雜的技術(shù),學習門坎太高,開發(fā)過程太長,成本太高,所以只適合用在極少數(shù)的項目
          中。 多語言的時代來臨。以往只要用C/C++,就可以包辦各種應用的開發(fā),不管是系統(tǒng)程序
          、桌面應用、網(wǎng)絡應用。現(xiàn)在卻是多語言的時代。多會幾個語言比較保 險,尤其是學會兩
          、三個Script語言絕對不嫌多。 今天的資產(chǎn)是明天的包袱。不甘心丟棄手中的技術(shù)(畢竟
          是多年學習的結(jié)果),改用(改學)新技術(shù)者,會漸漸被時代拋棄。Paradigm Shift是常態(tài)
          ,所以我們應該積極地接受這些新挑戰(zhàn),畢竟IT產(chǎn)業(yè)就是這樣。

          posted @ 2008-02-28 18:07 zhrb 閱讀(403) | 評論 (0)編輯 收藏

                  接口主要是用來描述這個系統(tǒng)有些什么功能,應該怎么調(diào)用這些功能,是更高的一
          層抽象。主要是用來表現(xiàn)給外界看。同時接口比較穩(wěn)定,不能隨便變來變?nèi)ァR驗槟阋?br /> 變,對于外界來說你的表現(xiàn)就變了。接口對于系統(tǒng)來說,相當于一個規(guī)范的描述,感覺
          有點像虛擬機規(guī)范之于虛擬機。接口對于編程人員來說,相當于幫你隱藏了一些東西,
          這寫隱藏(如何實現(xiàn))的東西,你不需要去關注。

              抽象類,在語法上的區(qū)別,你也說了。實際上抽象類也可以部分的實現(xiàn)接口的功能
          ,即描述一些東西給外界看。抽象類更像一個系統(tǒng)的骨架,里面有一些基本的需要共享
          的代碼。和一些已經(jīng)實現(xiàn)好的方法。想想,如果全都用接口代替抽象類的話,那么我們
          底下子類的編寫就需要編寫大量的代碼。而這些子類,本可以實現(xiàn)代碼和屬性的共享的
          。所以抽象類,更多的是一個對內(nèi)的東西。

              可以說接口是比抽象類更抽象的一個東西。接口和抽象類關注的地方不一樣。當然
          從邏輯上來看,他們的區(qū)別不是那么的明顯。但是從用法上來看,他們還是有比較大的
          區(qū)別。

              寫的有點亂...

          posted @ 2008-02-28 15:43 zhrb 閱讀(1457) | 評論 (3)編輯 收藏

          從某處獲得如下代碼:

           1// WelcomeApplet.java: Applet for displaying a message
           2import javax.swing.*;
           3
           4public class WelcomeApplet extends JApplet {
           5  /** Construct the applet */
           6  public WelcomeApplet() {
           7    getContentPane().add(
           8      new JLabel("Welcome to Java", JLabel.CENTER));
           9  }

          10}
          然后編輯好相應的html文件
          <html>
          <head>
          <title>Welcome Java Applet</title>
          </head>
          <body>
          <applet
            
          code = "WelcomeApplet.class"
            width 
          = 200
            
          height = 70>
          </applet>
          </body>
          </html>

          結(jié)果使用IE7和Maxthon2均無法正常運行,就是顯示一個叉。(機器已經(jīng)正確安裝了sun公司的虛擬機)
          但是使用appletviewer卻可以正常運行,換用opera瀏覽器也可以正常打開。
          看來IE7的設計還是有問題啊。希望微軟和Sun這對冤家早日和解....
          posted @ 2008-02-24 11:12 zhrb 閱讀(2057) | 評論 (4)編輯 收藏

          java類庫中java.util.Arrays 類的toString方法的源代碼。如下:
           1   public static String toString(long[] a) {
           2        if (a == null)
           3            return "null";
           4    int iMax = a.length - 1;
           5    if (iMax == -1)
           6            return "[]";
           7
           8        StringBuilder b = new StringBuilder();
           9        b.append('[');
          10        for (int i = 0; ; i++{
          11            b.append(a[i]);
          12        if (i == iMax)
          13        return b.append(']').toString();
          14            b.append("");
          15        }

          16    }
          for循環(huán)有點奇怪,中間的那個表達式是空的。其實即使加上了條件,for (int i = 0; i<=iMax ; i++) 和源程序是一個效果的,純粹是多余的,但是多余地加上了這條,結(jié)果編譯出錯了!提示沒有返回語句
          上面的文字摘自下面的文章:
          http://www.aygfsteel.com/raylong1982/archive/2007/11/01/157542.html
          我的理解是:
          如果return語句唯一存在于for循環(huán)里面,for中間語句加入任何判斷條件,除非這個判斷條件絕對為真(如空語句、ture、3>2),否則判斷條件就有可能為假導致無法執(zhí)行到這個循環(huán)中的return語句,編譯器顯然不允許這種情況發(fā)生,所以當return語句只在for循環(huán)體內(nèi)出現(xiàn),就不允許for循環(huán)中間的那個語句出現(xiàn)類似i<=iMax這樣的充滿不確定性的判斷,語法上。簡單一句話,包含return的那個句子,至少要讓編譯器覺得,這個return是可以執(zhí)行到的,以減少程序運行后出錯的可能。
          不過即使編譯器如此努力,還是架不住人們可能出現(xiàn)的語義上的錯誤,看下面這段代碼: 
          1    public static int max(int a, int b){
          2        for(;;)
          3            if (falsereturn a>b?a:b;
          4    }

          從語義上分析,return是無論如何也執(zhí)行不到的,但是編譯器認為for循環(huán)內(nèi)的語句肯定可以執(zhí)行到,并且里面還有return語句,所以就想當然的認為應該可以執(zhí)行到return語句,所以沒有報錯。至于到底有沒有錯,想想看、試一下就知道了。呵呵


          posted @ 2007-11-01 22:05 zhrb 閱讀(837) | 評論 (0)編輯 收藏

               摘要: Java中接口與抽象類的區(qū)別(一些學習體會,不知正確與否,請指正)  閱讀全文
          posted @ 2007-10-18 12:10 zhrb 閱讀(1505) | 評論 (2)編輯 收藏

          主站蜘蛛池模板: 依安县| 福泉市| 蒙山县| 略阳县| 建德市| 南川市| 台湾省| 克什克腾旗| 溧水县| 新宾| 宁强县| 梅州市| 海南省| 宁阳县| 西青区| 多伦县| 炎陵县| 青浦区| 宣威市| 文水县| 镇安县| 睢宁县| 汝南县| 前郭尔| 泸溪县| 大荔县| 西丰县| 伊川县| 榕江县| 乌鲁木齐县| 苍山县| 岳池县| 潞西市| 尼勒克县| 乌拉特后旗| 太仓市| 方山县| 凌源市| 湖州市| 明水县| 海城市|