- 浏览: 4825823 次
- 性别:
- 来自: 上海
博客专栏
-
robbin谈管理
浏览量:137456
文章分类
最新评论
-
xly1981:
领导者是团队的灵魂。深入一线的过程,包括代码review,能帮 ...
robbin谈管理:改造团队的经验(2) -
jiehuangwei:
像这种总结比较性的ppt文档可以多发啊
Web并发模型粗浅探讨 -
linux1308:
看完学习到了很多东西,感谢推荐!
推荐一篇很好的RoR部署方案性能评测 -
zweite:
直接对搜索的结果进行缓存是不是会更快一点呢
漫谈应用缓存的命中率问题 -
kaogua:
现在已经是ruby2.0了, 不知道这个的效率是怎么样的, 是 ...
Ruby作为服务器端应用已经成熟了
在Java平台上面,lucene是众望所归的全文检索工具,lucene性能不俗,程序稳定,第三方扩展和分词算法众多,但是在RoR方面,就没有那么幸运了,JavaEye网站要做全文检索,怎么来解决全文检索的问题呢?
在ruby平台上面,全文检索有三个途径:
1、solr, acts_as_solr
solr是apache开源组织的一个项目,完全基于lucene的最新版本,在lucene的上层提供了一个基于HTTP/XML的Web Services。solr的发行包自己绑定了jetty6.0应用服务器,可以直接启动,成为一个独立的全文检索的web服务。
由于和solr的通讯方式是标准的基于HTTP的XML,所以你可以使用任何编程语言,Java,C++,Ruby,Python都不在话下。你通过向solr发送xml查询请求,让solr在后台运行lucene,返回结果也被封装为xml,当然你也可以让solr去做索引。基本上solr就是lucene的一个Web服务的封装。solr的优势在于为大规模的全文检索做了很多缓存优化,由于采用xml,也不限于客户端的种类。
RoR有一个叫做acts_as_solr的插件,封装了ruby对solr的访问,如果你喜欢用solr作为全文检索,acts_as_solr是一个不错的选择,他可以很方便的让你的RoR应用添加全文检索功能,考虑到lucene的稳定性,这个方案是一个相当不错的选择。
但是这个方案的缺点也是显而易见的,你的RoR应用所有的全文检索都要依赖后台再次向solr服务器发送web请求来获取结果,单个页面的执行速度肯定会受限于后台的跨http的web请求,这对于那些对全文检索功能依赖特别多的网站来说,恐怕很难接受。因此JavaEye3.0不采用solr方案。
2、sphinx
http://robbin.iteye.com/blog/122696
我已经在上一篇博客当中介绍了sphinx。我个人非常青睐sphinx这种独立的第三方全文检索服务器,而且能够和MySQL结合的很好,更不用说其优异的性能了。但是sphinx的缺点在于没有很好的分词扩展的接口,它是一个纯C开发的服务。这对于中文分词功能的支持来说,就很难实现了,因此不得不遗憾的放弃。
3、ferret
ferret是ruby平台模仿lucene的一个移植软件,但是ferret并非纯ruby实现,而是基本上用C编写而成,只有少量面向程序员的接口是ruby写的。ferret虽然和lucene很像,连API也基本一致,但是ferret的成熟度远远不及lucene,这表现在:
1) ferret不支持中文分词
2) ferret用C编写的,其索引格式和lucene不兼容
3) ferret的索引速度很慢,而且很不稳定
4) windows平台的ferret在search的时候会崩溃
尽管ferret有上面这些缺点,但是RoR平台可供选择的余地却不大,因此还是决定使用ferret。
------------------------------ ferret 分割线 ------------------------------
1、acts_as_ferret (AAF)
AAF是一个相当不错的RoR插件,封装对ferret的操作,但是经过我的考察,决定弃用AAF。这是因为AAF是直接绑定到model上面的,这会带来一些问题:
1) 每当model对象被insert/update/delete的时候,AAF会通过model的回调实时更新全文索引。在生产环境这是一个很可怕的事情,多个ruby进程同时更新索引,就会出问题。所以AAF索性提供一个DRB方式的ferret server让你在生产环境去用。
但即便如此,如果多个ruby进程同时更新索引呢? 考虑到ruby的green thread性能,drb server也很容易就被阻塞住。而且退一步来说,即便drb性能很好,每个全文检索请求都去发起一次ruby远程调用,恐怕也是很难接受的事实
2) AAF索引每条model记录,但我却不想索引隐藏贴,况且我的索引机制也不想绑定在model上面。
2、中文分词问题
如果只是简单的中文单字拆分,到不难支持,只需要利用RegexpAnalysis写个正则表达式去匹配UTF-8编码的中文就行了,目前JavaEye的全文检索就是这样处理的,貌似搜索结果还过得去。
但是如果要追求非常精确的搜索结果,则必然需要通过词典的最大匹配算法去进行中文分词。那就只能自己用ruby来写中文分词算法了,这个是留待我们今后要做的工作。
2、ferret的索引稳定性问题
JavaEye网站有8万topic,30万post,由于ruby本身性能不佳,ferret又不很稳定,在服务器上面直接做index,差点把服务器搞瘫了,所以此路不通。
由于全文检索并不需要很高的实时性,所以我们的解决办法就是每天晚上把数据库数据下载到本地的台式机上面,然后在本地台式机上面导入数据库,进行全量索引,然后在压缩打包上传到服务器上面去。这样每天的全文检索结果只会迟后一天的时间,基本上可以满足需求了。
最近在用lucene+CJKAnalyzer做项目,现在索引和搜索都已经完成,但是测试时发现,对于一些大的word文档的搜索不完全,超过20页之后就搜索不到,不知问题出在哪里?
lucene有一个属性可以设置一个文档的最大单词数,默认好像是10000来着,你设置一下,应该就可以了。
是的,ferret在早期版本的索引格式和lucene是一致的,但是后来ferret作者认为lucene的索引格式不够优化,为了提高性能而采用了自己的索引格式,从而导致不兼容。
但是在我看来,ferret已经实现了lucene的大部分功能了,要说区别,也无非就是ferret做索引的时候速度比lucene慢一些而已。至于中文分词的问题,ferret面临和lucene一样的情形。所以大家用ferret和用lucene是一样的。
你说的有道理,搜索结果可以提供多种排序结果展示给用户看,记下来放在TODO List里面。
javaeye的全文搜索更加不大了,我基本不用,因为根本搜不出结果
哈哈, 一样一样 , 我都是这么搜索的, baidu or google 输入: site:www.iteye.com web 性能
如果整个网站仅仅只是提供一个全站搜索功能而已,用solr没有什么问题。但是将来JavaEye3.0整个网站非常多的功能依赖全文检索,例如每个文章下面的相关文章功能,博客的相关推荐和类,wiki的相关链接,工作职位相关推荐,寻找同好的朋友等等......
如果整个网站的有一半的页面点击都需要发起后台的HTTP/XML请求的话,就要考虑这种方式还能不能采用了。
明白你的意思了
那么选型的重点其实在于,是在后台整合搜索服务,还是在前台页面上整合搜索服务。
JavaEye的全文检索功能刚刚才支持,以前都是SQL查询,你现在可以试试看,效果肯定令你满意。
JavaEye的全文索引不单纯是索引内容,还需要根据帖子的点击次数,帖子投票的分值,帖子回贴的数量,发贴作者的等级来调整帖子的加权因子。即便很老的帖子,也会因为帖子点击次数,帖子投票分值变化而不断改变其加权因子,所以必须每天做全量索引。
如果整个网站仅仅只是提供一个全站搜索功能而已,用solr没有什么问题。但是将来JavaEye3.0整个网站非常多的功能依赖全文检索,例如每个文章下面的相关文章功能,博客的相关推荐和类,wiki的相关链接,工作职位相关推荐,寻找同好的朋友等等......
如果整个网站的有一半的页面点击都需要发起后台的HTTP/XML请求的话,就要考虑这种方式还能不能采用了。
在ruby平台上面,全文检索有三个途径:
1、solr, acts_as_solr
solr是apache开源组织的一个项目,完全基于lucene的最新版本,在lucene的上层提供了一个基于HTTP/XML的Web Services。solr的发行包自己绑定了jetty6.0应用服务器,可以直接启动,成为一个独立的全文检索的web服务。
由于和solr的通讯方式是标准的基于HTTP的XML,所以你可以使用任何编程语言,Java,C++,Ruby,Python都不在话下。你通过向solr发送xml查询请求,让solr在后台运行lucene,返回结果也被封装为xml,当然你也可以让solr去做索引。基本上solr就是lucene的一个Web服务的封装。solr的优势在于为大规模的全文检索做了很多缓存优化,由于采用xml,也不限于客户端的种类。
RoR有一个叫做acts_as_solr的插件,封装了ruby对solr的访问,如果你喜欢用solr作为全文检索,acts_as_solr是一个不错的选择,他可以很方便的让你的RoR应用添加全文检索功能,考虑到lucene的稳定性,这个方案是一个相当不错的选择。
但是这个方案的缺点也是显而易见的,你的RoR应用所有的全文检索都要依赖后台再次向solr服务器发送web请求来获取结果,单个页面的执行速度肯定会受限于后台的跨http的web请求,这对于那些对全文检索功能依赖特别多的网站来说,恐怕很难接受。因此JavaEye3.0不采用solr方案。
2、sphinx
http://robbin.iteye.com/blog/122696
我已经在上一篇博客当中介绍了sphinx。我个人非常青睐sphinx这种独立的第三方全文检索服务器,而且能够和MySQL结合的很好,更不用说其优异的性能了。但是sphinx的缺点在于没有很好的分词扩展的接口,它是一个纯C开发的服务。这对于中文分词功能的支持来说,就很难实现了,因此不得不遗憾的放弃。
3、ferret
ferret是ruby平台模仿lucene的一个移植软件,但是ferret并非纯ruby实现,而是基本上用C编写而成,只有少量面向程序员的接口是ruby写的。ferret虽然和lucene很像,连API也基本一致,但是ferret的成熟度远远不及lucene,这表现在:
1) ferret不支持中文分词
2) ferret用C编写的,其索引格式和lucene不兼容
3) ferret的索引速度很慢,而且很不稳定
4) windows平台的ferret在search的时候会崩溃
尽管ferret有上面这些缺点,但是RoR平台可供选择的余地却不大,因此还是决定使用ferret。
------------------------------ ferret 分割线 ------------------------------
1、acts_as_ferret (AAF)
AAF是一个相当不错的RoR插件,封装对ferret的操作,但是经过我的考察,决定弃用AAF。这是因为AAF是直接绑定到model上面的,这会带来一些问题:
1) 每当model对象被insert/update/delete的时候,AAF会通过model的回调实时更新全文索引。在生产环境这是一个很可怕的事情,多个ruby进程同时更新索引,就会出问题。所以AAF索性提供一个DRB方式的ferret server让你在生产环境去用。
但即便如此,如果多个ruby进程同时更新索引呢? 考虑到ruby的green thread性能,drb server也很容易就被阻塞住。而且退一步来说,即便drb性能很好,每个全文检索请求都去发起一次ruby远程调用,恐怕也是很难接受的事实
2) AAF索引每条model记录,但我却不想索引隐藏贴,况且我的索引机制也不想绑定在model上面。
2、中文分词问题
如果只是简单的中文单字拆分,到不难支持,只需要利用RegexpAnalysis写个正则表达式去匹配UTF-8编码的中文就行了,目前JavaEye的全文检索就是这样处理的,貌似搜索结果还过得去。
但是如果要追求非常精确的搜索结果,则必然需要通过词典的最大匹配算法去进行中文分词。那就只能自己用ruby来写中文分词算法了,这个是留待我们今后要做的工作。
2、ferret的索引稳定性问题
JavaEye网站有8万topic,30万post,由于ruby本身性能不佳,ferret又不很稳定,在服务器上面直接做index,差点把服务器搞瘫了,所以此路不通。
由于全文检索并不需要很高的实时性,所以我们的解决办法就是每天晚上把数据库数据下载到本地的台式机上面,然后在本地台式机上面导入数据库,进行全量索引,然后在压缩打包上传到服务器上面去。这样每天的全文检索结果只会迟后一天的时间,基本上可以满足需求了。
评论
19 楼
小龟爬爬
2008-08-11
引用
最近在用lucene+CJKAnalyzer做项目,现在索引和搜索都已经完成,但是测试时发现,对于一些大的word文档的搜索不完全,超过20页之后就搜索不到,不知问题出在哪里?
lucene有一个属性可以设置一个文档的最大单词数,默认好像是10000来着,你设置一下,应该就可以了。
18 楼
qlhl2000
2007-12-29
最近在用lucene+CJKAnalyzer做项目,现在索引和搜索都已经完成,但是测试时发现,对于一些大的word文档的搜索不完全,超过20页之后就搜索不到,不知问题出在哪里?
17 楼
robbin
2007-12-05
yawl 写道
我有点好奇想了解一下,如果有个ruby库能读lucene本机的索引,会不会就能解决这个个问题了?
因为看上去主要问题似乎是ferret索引格式和lucene不兼容,而solr无法运行于本机。
因为看上去主要问题似乎是ferret索引格式和lucene不兼容,而solr无法运行于本机。
是的,ferret在早期版本的索引格式和lucene是一致的,但是后来ferret作者认为lucene的索引格式不够优化,为了提高性能而采用了自己的索引格式,从而导致不兼容。
但是在我看来,ferret已经实现了lucene的大部分功能了,要说区别,也无非就是ferret做索引的时候速度比lucene慢一些而已。至于中文分词的问题,ferret面临和lucene一样的情形。所以大家用ferret和用lucene是一样的。
16 楼
yawl
2007-12-04
我有点好奇想了解一下,如果有个ruby库能读lucene本机的索引,会不会就能解决这个个问题了?
因为看上去主要问题似乎是ferret索引格式和lucene不兼容,而solr无法运行于本机。
因为看上去主要问题似乎是ferret索引格式和lucene不兼容,而solr无法运行于本机。
15 楼
robbin
2007-12-04
javaeyes 写道
我觉得现在网站上的搜索有个非常大的弊病,就是结果的排序。robbin将各种相关性如点击数,回复数掺杂在相关性排序中,这导致了搜索结果的一成不变,比如搜"lucene",从新搜索功能上线到现在前面几条结果都是一样,对我这样的想掌握javaeyes上的"lucene"动态的人来说非常的郁闷,看来看去都是那些内容在前面。个人建议对历史精华贴做单独的推荐,主要结果还是按时间为主要影响因子进行排序。或者提供两个按钮:按相关度排序和按时间排序
你说的有道理,搜索结果可以提供多种排序结果展示给用户看,记下来放在TODO List里面。
14 楼
javaeyes
2007-12-04
我觉得现在网站上的搜索有个非常大的弊病,就是结果的排序。robbin将各种相关性如点击数,回复数掺杂在相关性排序中,这导致了搜索结果的一成不变,比如搜"lucene",从新搜索功能上线到现在前面几条结果都是一样,对我这样的想掌握javaeyes上的"lucene"动态的人来说非常的郁闷,看来看去都是那些内容在前面。个人建议对历史精华贴做单独的推荐,主要结果还是按时间为主要影响因子进行排序。或者提供两个按钮:按相关度排序和按时间排序
13 楼
dazuiba
2007-10-08
我们网站想从java转到Ruby。目前最头疼的问题是luccen的移植。我现在是这样考虑的,搜索密集的地方,都用apache proxy到后台的tomcat服务器,也就是仍旧由java luccen来做。但生成的页面URL,是由ruby 服务器来服务。
对于实在难分开的全文检索,仍旧传到java 服务器,服务器返回javascript,通过ajax方式和rhtml生成的代码结合使用。
目前还很两难,以上都是自以为行得通,不知大家有什么意见。
反正全文检索,我不想转到ruby,感觉ruby这方面太不成熟了。
对于实在难分开的全文检索,仍旧传到java 服务器,服务器返回javascript,通过ajax方式和rhtml生成的代码结合使用。
目前还很两难,以上都是自以为行得通,不知大家有什么意见。
反正全文检索,我不想转到ruby,感觉ruby这方面太不成熟了。
12 楼
challenge2007
2007-10-08
学习中,还是第一次,看到。
11 楼
capitain
2007-10-07
robbin, 我采用的是ruby通过drb 访问jruby下的lucene, 中文分词都是现成的, jruby利用同样的rails代码访问数据库, 定时更新
10 楼
chinapkw
2007-09-30
robin 可不可以说一下ferret 中文分词
GENERIC_ANALYSIS_REGEX = /([a-zA-Z]|[\xc0-\xdf][\x80-\xbf])+|[0-9]+|[\xe0-\xef][\x80-\xbf][\x80-\xbf]/
GENERIC_ANALYZER = Ferret::Analysis::RegExpAnalyzer.new(GENERIC_ANALYSIS_REGEX, true)
acts_as_ferret({}, { :analyzer => GENERIC_ANALYZER })
用这种方式。貌似可行。但只要多刷新几次。服务器就会停掉
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_suppor
odule/inclusion.rb:4: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [i386-mswin32]
This application has requested the Runtime to terminate it in an unu
Please contact the application's support team for more information.
怎么解决呢
GENERIC_ANALYSIS_REGEX = /([a-zA-Z]|[\xc0-\xdf][\x80-\xbf])+|[0-9]+|[\xe0-\xef][\x80-\xbf][\x80-\xbf]/
GENERIC_ANALYZER = Ferret::Analysis::RegExpAnalyzer.new(GENERIC_ANALYSIS_REGEX, true)
acts_as_ferret({}, { :analyzer => GENERIC_ANALYZER })
用这种方式。貌似可行。但只要多刷新几次。服务器就会停掉
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_suppor
odule/inclusion.rb:4: [BUG] Segmentation fault
ruby 1.8.5 (2006-08-25) [i386-mswin32]
This application has requested the Runtime to terminate it in an unu
Please contact the application's support team for more information.
怎么解决呢
9 楼
icess
2007-09-30
zgd 写道
javaeye的全文搜索更加不大了,我基本不用,因为根本搜不出结果
哈哈, 一样一样 , 我都是这么搜索的, baidu or google 输入: site:www.iteye.com web 性能
8 楼
sorphi
2007-09-29
robbin 写道
wainwen 写道
一直用solr,感觉相当不错
javaeye选择ferret,值得商榷
从稳定性和扩展性两个方面看,还是solr更适合
至于性能,http的开销其实不大。搭建solr测试环境,也就小半天的事情,何不TDD?
javaeye选择ferret,值得商榷
从稳定性和扩展性两个方面看,还是solr更适合
至于性能,http的开销其实不大。搭建solr测试环境,也就小半天的事情,何不TDD?
如果整个网站仅仅只是提供一个全站搜索功能而已,用solr没有什么问题。但是将来JavaEye3.0整个网站非常多的功能依赖全文检索,例如每个文章下面的相关文章功能,博客的相关推荐和类,wiki的相关链接,工作职位相关推荐,寻找同好的朋友等等......
如果整个网站的有一半的页面点击都需要发起后台的HTTP/XML请求的话,就要考虑这种方式还能不能采用了。
明白你的意思了
那么选型的重点其实在于,是在后台整合搜索服务,还是在前台页面上整合搜索服务。
7 楼
robbin
2007-09-29
zgd 写道
solr比较好,http性能没有你想象那么低
而且全文搜寻压力并没有那么大的,大多数人都是看帖的
javaeye的全文搜索更加不大了,我基本不用,因为根本搜不出结果
往solr里面写数据可以做一个简单的队列服务器降低更新频率
而且你的做法是每天做一次完整的索引,那是不必要的,直接做差异就可以了,solr对修改支持非常好
而且全文搜寻压力并没有那么大的,大多数人都是看帖的
javaeye的全文搜索更加不大了,我基本不用,因为根本搜不出结果
往solr里面写数据可以做一个简单的队列服务器降低更新频率
而且你的做法是每天做一次完整的索引,那是不必要的,直接做差异就可以了,solr对修改支持非常好
JavaEye的全文检索功能刚刚才支持,以前都是SQL查询,你现在可以试试看,效果肯定令你满意。
JavaEye的全文索引不单纯是索引内容,还需要根据帖子的点击次数,帖子投票的分值,帖子回贴的数量,发贴作者的等级来调整帖子的加权因子。即便很老的帖子,也会因为帖子点击次数,帖子投票分值变化而不断改变其加权因子,所以必须每天做全量索引。
6 楼
robbin
2007-09-29
wainwen 写道
一直用solr,感觉相当不错
javaeye选择ferret,值得商榷
从稳定性和扩展性两个方面看,还是solr更适合
至于性能,http的开销其实不大。搭建solr测试环境,也就小半天的事情,何不TDD?
javaeye选择ferret,值得商榷
从稳定性和扩展性两个方面看,还是solr更适合
至于性能,http的开销其实不大。搭建solr测试环境,也就小半天的事情,何不TDD?
如果整个网站仅仅只是提供一个全站搜索功能而已,用solr没有什么问题。但是将来JavaEye3.0整个网站非常多的功能依赖全文检索,例如每个文章下面的相关文章功能,博客的相关推荐和类,wiki的相关链接,工作职位相关推荐,寻找同好的朋友等等......
如果整个网站的有一半的页面点击都需要发起后台的HTTP/XML请求的话,就要考虑这种方式还能不能采用了。
5 楼
wainwen
2007-09-29
一直用solr,感觉相当不错
javaeye选择ferret,值得商榷
从稳定性和扩展性两个方面看,还是solr更适合
至于性能,http的开销其实不大。搭建solr测试环境,也就小半天的事情,何不TDD?
javaeye选择ferret,值得商榷
从稳定性和扩展性两个方面看,还是solr更适合
至于性能,http的开销其实不大。搭建solr测试环境,也就小半天的事情,何不TDD?
4 楼
sorphi
2007-09-29
如果不是单纯的研究ror应用,把search做成java webapp,是不是更合适?
3 楼
zgd
2007-09-29
solr做的很好的,本来就是大站的产品,后来贡献给apache而已
2 楼
zgd
2007-09-29
solr比较好,http性能没有你想象那么低
而且全文搜寻压力并没有那么大的,大多数人都是看帖的
javaeye的全文搜索更加不大了,我基本不用,因为根本搜不出结果
往solr里面写数据可以做一个简单的队列服务器降低更新频率
而且你的做法是每天做一次完整的索引,那是不必要的,直接做差异就可以了,solr对修改支持非常好
而且全文搜寻压力并没有那么大的,大多数人都是看帖的
javaeye的全文搜索更加不大了,我基本不用,因为根本搜不出结果
往solr里面写数据可以做一个简单的队列服务器降低更新频率
而且你的做法是每天做一次完整的索引,那是不必要的,直接做差异就可以了,solr对修改支持非常好
1 楼
猫尾摆摆
2007-09-28
仔细看下robbin的开发手记
发表评论
-
《松本行弘的程序世界》推荐序
2011-07-21 13:47 15304在流行的编程语言中,ruby是一个比较另类的存在,这是因为大多 ... -
从Rails聊聊小公司的研发团队建设
2011-03-23 10:49 37233首先分享一点数据吧: JavaEye的PV到了140万了,一 ... -
Ruby作为服务器端应用已经成熟了
2009-11-17 14:55 15975JavaEye网站在过去的Ruby on rails实践当中, ... -
基于资源的HTTP Cache的实现介绍
2009-09-05 00:27 17075我们都知道浏览器会缓 ... -
请注意Rails2.3自带的memcache-client有性能问题
2009-03-23 18:05 14511Rails2.3版本发布了,这个版本内部的改动非常大,相关介绍 ... -
监视Rails进程内存泄漏的技巧
2008-12-30 21:56 10971Rails应用比较容易遇到的两类性能问题:一类是Rails执行 ... -
ruby MBARI大补丁性能评测报告
2008-12-23 12:19 5074JavaEye之前的新闻ruby内存泄漏的罪魁祸首 - 幽灵指 ... -
在top监视窗口显示Rails当前正在执行的请求URL
2008-12-01 14:15 9862这是一个从PragDave的博客上面学来的技巧,很实用,很co ... -
对Ruby VM的GC的思考
2008-09-02 23:41 8986Ruby虽然是动态脚本语言 ... -
推荐一篇很好的RoR部署方案性能评测
2008-07-08 11:55 9679今年年初的时候,我写了一篇RoR部署方案深度剖析的文章,分析了 ... -
Ruby和Rails的缺点
2008-06-25 21:08 17409有人说,robbin你说了那么多RoR的优点,你啥时候说说Ro ... -
Skynet --- ruby的类Google Map/Reduce框架
2008-06-02 00:39 8303Skynet是一个很响亮的名 ... -
rmmseg-cpp - 简洁高效的ruby中文分词程序
2008-05-27 00:47 11243我在前一篇文章向大家 ... -
使用libmmseg实现Ruby的中文分词功能
2008-05-24 21:43 11337用Ruby on Rails开发web2.0网站的人都知道,r ... -
mod_rails尝鲜
2008-04-13 14:32 8085Passenger(俗称mod_rails)是 ... -
Lighttpd和RoR安装配置的疑难解答
2008-03-07 11:09 14866之前写过一篇在Linux平 ... -
JavaEye网站的RoR性能优化经验谈
2008-01-20 16:11 18466JavaEye网站从2006年9月11 ... -
RoR部署方案深度剖析
2008-01-14 03:10 14809RoR的部署方案可谓五花八门,有Apache/Fastcgi方 ... -
RoR网站如何利用lighttpd的X-sendfile功能提升文件下载性能
2008-01-12 17:45 10268传统的Web服务器在处理文件下载的时候,总是先读入文件内容到应 ... -
Ruby为什么会受程序员的欢迎?
2008-01-07 20:08 15754孟岩最近写了一篇博客 ...
相关推荐
### JavaEye3.0开发手记之开发环境搭建详解 #### 一、开发环境搭建概述 随着JavaEye3.0开发计划的启动,本篇文章将详细介绍如何为该项目搭建高效的开发环境。开发过程中不仅需要考虑软件的选择,还需要针对操作...
NULL 博文链接:https://ago520.iteye.com/blog/814571
NULL 博文链接:https://ago520.iteye.com/blog/754087
【JavaEye论坛热点 - 2008年11月 - 总第6期】是2008年11月JavaEye论坛上讨论的热点话题汇总,包含了多个关于Java和软件开发领域的讨论主题。以下将对部分主题进行详细解释: 1. **领域模型的价值与困境** - 领域...
JavaEye新闻月刊2009年3月第13期内容涉及了当时软件开发领域内的一系列重要话题,包括IBM拟收购Sun Microsystems公司的新闻报道、Java社区对此的看法以及各种编程语言、开发工具和技术的新动态。 首先,新闻月刊...
Java是世界上最流行的编程语言之一,尤其在企业级应用开发领域占据主导地位。为了深入学习Java,了解并掌握其API(应用程序接口)以及使用高效的开发工具是至关重要的。下面,我们将详细探讨Java学习网站、API手册、...
【JavaEye论坛热点推荐 - 2009年09月 - 总第16期】 这期JavaEye论坛的热点推荐涵盖了多个Java相关的技术话题,包括JDK7的新特性、HTTP缓存、Android开发、Java编程面试问题、Hibernate缓存、网页数据存储设计、热...
在Linux平台上安装和配置Ruby on Rails详解 - rails - Ruby - JavaEye论坛.htm
9. **移动开发**:随着Android的崛起,Java在移动开发领域的应用也可能是热点话题之一。 10. **面试与职业发展**:Java程序员的面试技巧、职场经验分享、职业规划等内容,对于求职者和开发者都有参考价值。 通过...
【JavaEye月刊2008年6月总第4期】主要涵盖了多个与Java相关的技术和社区动态,其中重点讨论了Eclipse Ganymede的发布、Ruby语言的进展以及Java在实际应用中的案例。 1. **Eclipse Ganymede** Eclipse Ganymede是...
### JavaEye2.0_on_rails:敏捷Web开发实践与Ruby on Rails的应用 #### 敏捷软件开发方法 - **背景**:传统软件工程方法在实际应用中面临着项目延期、成本超支以及软件质量不高的问题。为了克服这些挑战,业界提出...
"JavaEye博文" 本资源摘要信息来自JavaEye博文,作者cutesunshineriver,发布于2010年。...本资源摘要信息涵盖了软件开发、编程、项目管理等多方面的知识点,是软件开发和项目管理专业人士的必读之作。
Jsp-Servlet复习笔记-----第3章 Servlet技术 - 堕落天使 - JavaEye技术网站.mhtJsp-Servlet复习笔记-----第3章 Servlet技术 - 堕落天使 - JavaEye技术网站.mht