23:26 原君 » Just 平生一笑

读白寿彝《中国通史》看到的,及至之前刚刚涉猎的《六韬》、《三略》,深为古人的思想而折服。也许如冯友兰所说:“根据中国哲学的传统,哲学的功能不是为了增进正面的知识,而是为了提高人的心灵,超越现实世界,体验高于道德的价值”。用哲学替代宗教,深以为然。

Continue reading»»

20:44 技术:从来不是中立的 » It Talks-魏武挥的blog
家人早上用短信告诉我,某大型门户的Blog服务采取了“先审后发”制。虽然,这个审核的时间很短(估计在五分钟左右),但还是令他很不爽。 搞先审后发制的Blog服务,不是什么新鲜事。另...
19:38 SNS 站点中的'水葫芦' » DBA notes

看这个题目可能有人会有疑问,SNS 站点和水葫芦有啥关系?

周六周日和项目团队去华庄生态农业园玩了一次,钓鱼,钓龙虾都挺有趣的. 不过给我印象最深还是水道上到处可以看到的水葫芦。有的地方已经占据了大半的水面。据说这玩意儿已经在滇池、太湖以及不少水域肆虐多时,因为繁殖飞快,很难根治。其危害来自"生长中消耗大量溶解氧,又会加剧水体富营养化",最近又有"专家"要用这玩意儿以毒攻毒对付蓝藻,我看完全是欠抽。

网络上也有'水葫芦', 在 SNS 站点里尤甚。拿我在 Wealink 中的体验来说,里面所谓的从事猎头和营销的用户就和水葫芦差不多,拥有几千个'连接'的猎头不在少数,而且这些人在里面折腾的还挺欢,每天收件箱里面都能收到转发来的所谓体现"人生智慧"之类的玩意儿。以致于我现在看到猎头人员发来的连接请求一律拒绝。记得很久以前 Wealink 还是不能主动和联系人断开链接的,我申请了几次后新功能也开发出来了。新型 Web 2.0 站点是这样,其实传统的论坛里也存在类似的情况,我以前喜欢去的一个技术论坛,就是因为有些用户大量的自我繁殖,发送格调低下的垃圾信息而导致不少用户流失,当然,很多站长还是喜欢这样的"水葫芦用户",毕竟带来了更多的 PV --垃圾 PV。

水葫芦消耗大量氧气,而"水葫芦用户"消耗大量网站资源,水葫芦使水体富营养化,使得其他生物大量死亡,"水葫芦用户"使得 SNS 站点"富信息化"--导致其他用户信息过载。这一点不少 Twitter 用户也深有体会吧?! 水葫芦破坏生态,"水葫芦用户"破坏一个社区的生态,而且会"暗示"更多的用户加入水葫芦的行列,如果不信的话,看看那些喜欢树立 "用户标兵" 的站点(比如新浪)就知道了。

任何站点都不可能没有"水葫芦用户",关键还是看管理者的态度。有些听之任之,甚至喜欢"水葫芦用户"带来的虚假繁荣,短期内可能好像有所收益,长期来看,最受损伤的还是站点自身。

国内的站点中,豆瓣在这克制水葫芦用户上做得很好,值得表扬。

--EOF--
18:56 SGI - Developer Central Open Source | XFS » del.icio.us/chedong
NFS Compatibility With NFS version 3, 64-bit filesystems can be exported to other systems that support the NFS V3 protocol. Systems that use NFS V2 protocol may access XFS filesystems within the 32-bit limit imposed by the protocol.
15:13 topography tableware » information aesthetics

topoware.jpg
a tableware collection that questions the "landscape of dining". inspired by the popularity of geography & topographic maps as a media of visual communication. made up of cups, plates, bowls, place mats & a tablecloth, the collection explores the visual landscape of dining by using outlines & descriptions to illustrate the eating experience, making it feel like a journey.

[link: topoware.org & flickr.com|via mocoloco.com]

我的WebLucene安装经验厚土-浮云 » Che, Dong's shared items in Google Reader

    由于项目的需要,最近看了一些有关lucence的内容,后来才发现我们所需要的在车东先生在开源项目weblucene中已经完全实现了,这几天尝试了安装,其间发现了一些问题,这里与大家分享一下

    首先大家应该看看车先生的weblucene中的build.txt和  http://blog.donews.com/dev2dev/archive/2006/08/29/1021739.aspx

后者是一篇非常详细的安装说明,我只是就我在安装时遇到的不一样的和特别要注意的地方做出一些说明,大家可以两边对照来看

1、安装系统环境

(1)javaJDK

   这里我的是1.6.0

(2)JavaCC

 这里我也是JavaCC 2.1

(3)Ant

   我装的是1.7.0版本

(4)部署WebLucene工程

   这里我用的是Tomcat 6.0,一样的,大家可以把weblucene压缩包解压缩到tomcat6.0目录下的webapps目录中

2Build项目

(1)  准备build环境

 首先也是讲weblucene下的build.properties.default重命名为build.properties

下面是我的配置:

# ---------------------------------------------------------

# WebLucene  BUILD  PROPERTIES

# ---------------------------------------------------------

#jsdk_jar=/usr/local/resin/lib/jsdk23.jar

 

# Home directory of JavaCC

#javacc.home = /usr/java/javacc/bin

 

# modify following on Windows

# jsdk_jar=c:\\resin\\lib\\jsdk23.jar

# javacc.home = c:\\java\\javacc\\bin

jsdk_jar=D:\\Program Files\\Apache Software Foundation\\Tomcat 6.0\\lib\\servlet-api.jar

javacc.home = D:\\Program Files\\Java\\JavaCC2_1\\javacc2.1\\bin

javacc.zip.dir = D:\\Program Files\\Java\\JavaCC2_1\\javacc2.1\\bin\\lib

javacc.zip = D:\\Program Files\\Java\\JavaCC2_1\\javacc2.1\\bin\\lib\\JavaCC.zip

 

这里要注意的是jsdk_jar一项,这是和resin中不一样的,每一个版本的tomcat这个包的名字也不一样,请大家仔细找

 

(2)build工程 在weblucene目录下(这里我是weblucene2目录)

    直接运行ant build会出现错误

    这里问题的是从java5开始已经将enum保留为关键字,不能再做标识符,大家可以根据出错信息找到org.apache.lucene.queryParser.SimpleQueryParser.javaorg.apache.lucene.search.StringFilter.java两个文件中凡是出现enum的地方都换成其他的比如enum1(前者要修改3处,后者要修改9),再次运行ant build成功通过

 

 

3创建索引

依次运行以下命令

set LIB="D:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\weblucene2\webapp\WEB-INF\lib"

set XMLPATH="D:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\weblucene2\dump"

set VARPATH="D:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\weblucene2\webapp\WEB-INF\var"

 

java -classpath "D:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\weblucene2\webapp\WEB-INF\classes";%LIB%/lucene.jar;%LIB%/xercesImpl.jar;%LIB%/log4j.jar;%LIB%/java-getopt.jar IndexRunner -i %XMLPATH%\blog.xml -o %VARPATH%\blog

请根据自己的情况作更改,这里要注意的是如果你也有Program  Files这样带空格的文件名,一定要在头尾加上双引号,否则会出现错误,正反斜杠的使用也要小心一些

4测试搜索

没什么特别的地方

 

5部署web应用

对于tomcat 这里最简单的方法是将整个weblucene2 \webapp里的内容移动到webapp外面来,即剪切粘贴到weblucene2\下,然后启动tomcat,输入http://127.0.0.1:8080/weblucene2/search.html即可查询

 

 

希望这篇文章可以节省大家的一些时间 

 

最后感谢车东先生对我肤浅问题不厌其烦的回信,谢谢

10:06 请北京的热心虾友帮忙 » 抓虾日记
各位虾米,大家好~~ 如果你在北京,并且今天(周一)下午或晚上,或明天的上午刚好有空,且希望到抓虾来做客,小虾想请你来帮忙做一个抓虾产品的用户调研,时间大约在半个小时左右,你将有机会跟抓虾的产品人员面对面的交流,并获得我们给你准备的精美小礼品喔 抓虾的具体位置在: 北京市中关村东路66号世纪科贸大厦C座2608,如图所示A的位置上。 我们大概需要5-10位不同使用习惯用户的帮忙,所以如果你想参与的话,第一时间跟我们联系机会会更大哦 ^_^联系方式:yueyonghui@zhuaxia.com,请注明你的如下信息:在抓虾的注册Email、姓名、手机或电话的联系方式、方便到抓虾来的时间段。 小虾现在这里谢谢大家对于本次调研活动的支持了,希望大家明天的抓虾之行愉快!
让你的网站快100倍! (2) web程序的流程和层次demo@virushuo » Che, Dong's shared items in Google Reader
我面试程序员的时候,最爱问的一个问题是:“请描述一下一个php(或.net/jsp...)页面被用户访问后,服务器都做了什么。” 这个问题看似简单,但是很多熟手都说不清。这也就说明了很多程序员并不真正理解web程序是如何工作的。不懂这个,就分不出层次,自然也就无从下手优化。这次我们先要把这个问题说明白了。 静态内容当然是这样。 有程序的就这样 有数据库的就这样 多个数据库作了复制或是集群或是负载均衡的就这样。 多个web服务器作了负载均衡就是这样 类似的东西还有很多。不过本质是一样的。都是用户请求到webserver,经过相应的处理模块(静态直接返回,cgi运行程序,动态脚本运行,虚拟机执行字节码生成html代码),将结果返回,这个过程中如果需要数据库,程序会连接数据库处理,取回结果。这个简单的过程就是web程序的本质。 无论多么复杂的结构,都是这些过程的组合。通常顺序也不会发生变化。知道了这个,我们回头看后面几个架构,就会发现他们做的事情都一样,就是把负载分开。当然这里分散负载的方式有很多,但原理无非就是2种,一种是分散开的各节点内容一样,所谓集群或是分布。这种做法好处是可以有通用产品。因为模式是统一的,就是复制出来多个一样的节点而已。另外一种是拆分服务,把不同的服务拆开到不同的机器上。这样做的好处是效率提升更大,每个部分都可以再进行单独优化,比如把负载最重的部分复制多个节点出来分散压力等等。后面我们讲到架构设计的时候再细致讨论这些问题。这里只做常识介绍。 负载问题的解决,常用的也是两种办法,一是开源,二是节流(其实所有问题解决都是这两种办法,企业管理也好,个人财务也好)。放到我们这个特定问题中,所谓开源,就是提高单个部分运行效率,让该部分能负担更多的工作。比如优化一下程序,优化一下数据库,都属于此类。所谓节流,则指降低对高资源消耗部分的使用次数。通常采用缓存的方式来处理。 我们沿着一个web程序的运行过程来看看具体的东西。这时候,我们先忘掉所有的负载平衡,集群之类的东西,集中精力来解决一个最简单的应用过程中的性能问题。 整个层次用图表示就是这样的: 蓝色是必备的层次,绿色是后期可加入的缓存,黄色是可以进行优化的部分,黄色的比例是一般情况下优化能带来的效果比例。看起来很简单?但实际做起来也没那么容易。 1 用户访问:我们当然可以通过降低用户重复请求同样的内容的方法来提高用户浏览速度和降低压力。 两种办法。一种是利用浏览器缓存,正确的设置http header中相关设置,让浏览器不重复请求没变化的内容。一般来说图片倒是可以这样做。页面也可以作一些,不过考虑到pv就是广告费的问题,还是让用户多多直接访问页面吧:D 另外一种办法是利用js,将部分数据存放在js脚本里面(js会被浏览器缓存),或是存放在cookie里面,用js取回。由此降低用户访问次数。 虽然有一些效果,但这些办法解决不了太实际的问题。所以不放在最优先考虑位置。 2 http server 用户的请求到达了web server,在这个层面,可以去硬盘读取静态文件返回给用户,也可能交给cgi程序继续处理。我们注意到,无论哪种处理方式,返回给用户的都是一个已经完成的html页面(或文件)。换句话说,就算是动态脚本,也是把处理结果生成html文件返回用户。如果我们能不重复这个生成的过程,那么对后端所有模块的压力都降低了。这个办法就是反向代理缓存。在http server之前使用。 3 cgi/vm 应用程序请求到达了cgi程序。那么最直接的考虑就是提高程序运行效率。不过,程序运行效率的提升多在几个毫秒的级别。除非程序非常糟糕,否则提升余地不大。而我们通常所感觉到的“程序响应慢”的原因,其实往往是在数据库上。 当然,这个层面会有一些特定的解决方案,比如zend对php的那些加速方案。(其本质仍然是不同层面的缓存) 4 database 终于到达了数据库这层。脚本和cgi程序访问数据库,获得数据才能生成html页面返回。这层的负担很重。 数据库优化是有效的。设计的好的数据库结构,搭配正确的sql语句,可以比最糟糕的设计提高数百甚至上千毫秒的时间。访问量大的时候,这个累计效应非常明显。 数据库设计往往决定了性能。鉴于目前关系型数据库的普及,很多程序员就把数据库当作了唯一的存储解决方案,任何东西都存放在数据库里。这当然是不对的,存储要结合应用特点,数据库不是万能的,很多操作在数据库中耗费资源巨大而性能非常低。例如全文like的搜索就非常消耗资源,远不如采用倒排索引的查询方式。 除此之外,数据库层面也可以进行缓存,例如memcached,或是在程序中缓存部分数据等。 5 高级优化 这些做起来就有些难度了。当所有性能都压榨完,我们只能回到web server和cgi程序本身。所以大型网站往往使用自己开发的web server(自行定制apache等),采用裁剪过的php库。...

^==Back Home: www.chedong.com

^==Back Digest Home: www.chedong.com/digest/

<== 2007-07-15
  七月 2007  
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
==> 2007-07-17