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 阅读(7754) | 评论 (4)编辑 收藏

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

业务很重要...呵呵
posted @ 2008-06-25 23:06 zhrb 阅读(283) | 评论 (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 阅读(370) | 评论 (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 阅读(380) | 评论 (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 阅读(274) | 评论 (0)编辑 收藏

主要功能:为用户群建立群组,群组中含有任务分发与管理、论坛、发放通知、资源共享(照片、文件等)。每个用户都有自己的信息中心,里面包含任务、信息、个人功能。成熟以后,可以为用户开发相应的客户端,类似qq。其实本质上就是开发一个个人信息中心。

可能涉及的难点:权限管理、任务分排与管理


以后的工作:C/S

 

 自己随便的一个想法,不知道国内有没有已经做得很成熟的系统可供参照,希望大家可以帮忙介绍一下。呵呵

posted @ 2008-04-20 00:54 zhrb 阅读(306) | 评论 (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 阅读(245) | 评论 (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 阅读(290) | 评论 (0)编辑 收藏