zhrb的空間

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

          2008年4月14日 #

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





           
           

          常用設置
              Utilities--Global Options
                  Appearance(設置外觀,其中Swing look $ feel如果設置成Metal風格,可以更改菜單等字體大小)
                  Docking(設置插件、組件在編輯器中出現的位置,一般將FileBrowser設置在left,將console與Errolist設置在bottom)
                  Editing(Tab witdh設置tab的空格數,Indent width設置縮進的空格數,Soft(emulated with space)tabs用空格模擬tab)
                  Gutter(編輯區左邊條狀區域)
                      1.Line numbers(顯示行號),Gutter font
                  Text Area(編輯區)
                      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操作系統下通常是在MyDocument目錄下的 .jedit 目錄)
                          jEdit application directory(jEdit程序目錄)

          jEdit的設置目錄(.jedit)
              存放jEdit設置、插件的目錄(可以備份此文件夾來保存自己的設置與插件)位置(在windows操作系統下通常
          是在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 閱讀(7926) | 評論 (4)編輯 收藏

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

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

          轉載:奧卡姆剃刀

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

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

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


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


          一:J2SE
          面向對象-封裝、繼承、多態
          內存的分析
          遞歸
          集合類、泛型、自動打包與解包、Annotation
          IO
          多線程、線程同步
          TCP/UDP
          AWT、事件模型、匿名類
          正則表達式
          反射機制

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

          3:JDBC
          JDBC基礎
          連接池
          樹狀結構存儲與展現
          DataSource & RowSet
          JDBC連接Oracle及MySQL

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

          5:Servlet & JSP

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

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

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

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

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

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

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

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

          梳理一下,你就會發現東西不是想象中的那么多呀!

          --
          The pact is sealed!


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

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

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

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

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

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

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

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

          可能涉及的難點:權限管理、任務分排與管理


          以后的工作:C/S

           

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


          --


             晶晶姑娘是個好姑娘


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

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

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

          噴嚏網:原創 www.dapenti.com
          (一)

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

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

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

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

           他來問我他該怎么辦。

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

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

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


          (二)

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

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

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

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

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

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


          (三)

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

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

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

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

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

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

           作為技術的互聯網,是如何改變了傳統的市場?

           優勢:

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

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

           【3】營銷的方式發生了根本的變化

           劣勢:

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

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

           【3】需求到消費的轉換率不高;

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

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


          (四)

           任何一個成功的互聯網項目或產品,至少應該具有這樣的基本特征:

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

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

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

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

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

           如果首先有80/20的業務存在,那么互聯網的長尾就會看上去非常優美。如果沒有,長尾就等于是零。

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

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

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

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

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

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

           如果首先有80/20的業務存在,那么互聯網的長尾就會看上去非常優美。如果沒有,長尾就等于是零。

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

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

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

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

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

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

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

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

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

          --

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

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

          主站蜘蛛池模板: 赣榆县| 锦屏县| 平阴县| 克拉玛依市| 靖宇县| 五家渠市| 荆州市| 青冈县| 保康县| 涡阳县| 东兴市| 克什克腾旗| 古浪县| 双牌县| 莱州市| 军事| 乌拉特中旗| 陵川县| 六安市| 应用必备| 河北省| 正定县| 屏南县| 固原市| 郓城县| 镇原县| 仙居县| 信宜市| 辽阳县| 确山县| 遂溪县| 广东省| 信阳市| 甘肃省| 泗洪县| 辽阳市| 凤山县| 永福县| 威远县| 英德市| 文成县|