春峰 的个人资料我要去桂林照片日志列表 工具 帮助

I Touch

I Touch

当电影院的侧灯缓缓变暗后,一个富有磁性的声音缓缓说道:每隔几万年,人类就会发生一次变异…。这是电影金刚狼开始序幕的解说词。今天,当我躺在床上,摸着手中的iPod Touch浏览Twitter的时候,忽然一股清晰影像浮现在眼前,也许我们正处在人类历史从自然生物到高科技武装到牙齿的变异萌芽阶段。我猜用不了200年,围绕在我们每个人身上的各种电子设备数量绝对不比现在美女梳妆台上的瓶瓶罐罐的数量逊色。你要是出门身上不带10几块电路板,你都不好意思跟人家打招呼。
从接触电脑开始,被微软教育了这么多年后,才发现原来用户界面还可以这样做。(这件事情让我切实感觉到只听一种声音、只看一种画面是错误的。在此要顶一个人:郑昀。他是我认识的程序员里最有思想的人,是我认识最有思想的人里最会写程序的。正如起来挑战微软霸权一书中说的一样,你愿意你的小孩生活在一个没有选择的世界吗。)Apple把iPod Touch+iTunes+App Stroe串在一起,不仅满足了我的想象,而且在引诱我加入了苹果教。到目前为止我对iPod Touch的满意度是95%,最不爽的地方时YouTube没法用,当然这不是iPod的错。因为。特别是在某个被潜规则的日子快要到来的时候,连blogger也不能访问了。删除脏字。
昨天,5-17日是世界电信日。现在满眼满耳都是铺天盖地的宣传,“沃”,原来是3G来了。李开复和丁磊做了天翼的宣传代言人,连李一男也坐不住了“要把百度所有产品搬上手机”,这个夸张的表达说明百度对3G时代的热切期待。其实在3G时代此手机已经不是彼手机了,他们都是未来互联网的终端,单独为手机而做产品是得不偿失的。对于90%的代码都放在服务器端的百度们来说,如何为不同的互联网终端输出不同的内容和显示风格的需求变得突出起来,或许在未来UI RenderEngine将会作为一个中间件产品单独出现。
当全世界都在“云计算”和互联网终端都在“移动”的时候,看到这篇新闻你不觉得吃惊吗:“09年程序员数量明显下降 应用程序数量反大增”。我对这个现象的解释是,更多的程序员们都SOHO(或者以工作室的方式)去了。也就是说程序员的绝对数量不应该下降,而在公司“坐班”的程序员数量下降了。不信?看看Apple Store带来了多少机会类似的机会吧;Apple , Google,Nokia,Microsoft,甚至魅族M8(已经有了SDK),在未来都会带给我们同样的奇迹。那些抱着程序员过了30岁就过时的想法,那只能说明:你Out啦,喝啤儿茶爽醒醒吧。
让我们一起Touch未来美好世界吧。
iPod , iPod Touch , I Robot。

不选择使用Lucene的6大原因

不选择使用Lucene的6大原因


     Lucene是开放源代码的全文搜索引擎工具包,凭借着其强劲的搜索功能和简单易用的实现,在国内已经很普及,甚至一度出现了言搜索必称Lucene的盛景。上个月Lucene的开发团队发布了 Java Lucene 2.3.1 ,相信很多朋友们都用上了。在国内对Lucene的介绍可以分为3块儿:
第一类是:以车东Lucene:基于Java的全文检索引擎简介 为代表的基础入门介绍;
第二类是Lucene倒排索引原理和Lucene软件包、实现类的介绍;
第三类是以中文分词为中心的介绍;

     任何一个软件,包括所有伟大的软件都有这样或者那样的“缺点”和各自适用的领域,Lucene也不例外。在国内对Lucene这个软件包的批评,似乎没有 看到过。可能大家都忙于做项目,纵然Lucene有再大的缺陷,凭借着Lucene良好的口碑,也不会说上一句不是。

     今天在阅读LingWay (一个做垂直的语义搜索引擎)的CTO Cedric Champeau 先生的博客是发现有一篇题为:Why lucene isn't that good 为什么Lucene并不是想象的那么棒 的文章:Champeau 开门见山指出了Lucene的6大不足之处,鉴于 Lingway 公司使用Lucene已有好几年的历史,我相信Cedric Champeau的对Lucene的评论还是值得一读。

不选择使用Lucene的6大原因:

6、Lucene 的内建不支持群集。
        Lucene是作为嵌入式的工具包的形式出现的,在核心代码上没有提供对群集的支持。实现对Lucene的群集有三种方式:1、继承实现一个 Directory;2、使用Solr 3、使用 Nutch+Hadoop;使用Solr你不得不用他的Index Server ,而使用Nutch你又不得不集成抓取的模块;

5、区间范围搜索速度非常缓慢;
       Lucene的区间范围搜索,不是一开始就提供的是后来才加上的。对于在单个文档中term出现比较多的情况,搜索速度会变得很慢。因此作者称Lucene是一个高效的全文搜索引擎,其高效仅限于提供基本布尔查询 boolean queries;
4、排序算法的实现不是可插拔的,因为贯穿Lucene的排序算法的tf/idf 的实现,尽管term是可以设置boost或者扩展Lucene的Query类,但是对于复杂的排序算法定制还是有很大的局限性;
3、Lucene的结构设计不好;
    Lucene的OO设计的非常糟,尽管有包package和类class,但是Lucene的设计基本上没有设计模式的身影。这是不是c或者c++程序员写java程序的通病?
    A、Lucene中没有使用接口Interface,比如Query 类( BooleanQuery, SpanQuery, TermQuery...) 大都是从超类中继承下来的;
    B、Lucene的迭代实现不自然: 没有hasNext() 方法, next() 返回一个布尔值 boolean然后刷新对象的上下文;
2、封闭设计的API使得扩展Lucene变得很困难;
   参考第3点;
1、Lucene的搜索算法不适用于网格计算;


详情可以查看:Cedric Champeau 先生的博客:Why lucene isn't that good 为什么Lucene并不是想象的那么棒

 

FriendFeed上的中国人

FriendFeed上的中国人

FriendFeed 刚推出后,很快引爆流行,出现了大量的博客 报道。


对我来说,FriendFeed 似乎没有什么用处。。。,至少目前这个阶段是这样的。

当然,没用处,但并不等于不好玩。

我的玩法是这样的:
1、登录
2、打开everyone标签
3、查看有中文字符的博客
4、如果还没有订阅,就 订阅
5、翻页,重复 3-5步。


在玩了半个月后,我有些厌倦了。这半个月的成果是:

1、Subscriptions 95

2、You are subscribed to 107 people 。

够了。

并且发现我这个玩法,可以机械化,于是,就有了这个:FriendFeed 上的中国人

http://www.domolo.com/friend_feed_china

COM本质论 COMCHAT 源代码下载

COM本质论 COMCHAT 源代码下载



COM本质论是本好书,Don Box 把什么是COM很清楚的写了出来。

这真是本好书,我是说:这本书的纸张质量也不错,我手头的这本COM本质论半截掉到洗衣盆里泡了半个上午后,晾干了还竟然能看,阿弥陀佛....



这本书有一个经典的com例子代码 comchat ,据说很难找到,COM本质论 COMCHAT 源代码很难找到,而且还有一个常见的问题。

请点击这里下载:  COM本质论 COMCHAT 源代码下载

为什么2007年的图灵奖选择了模型检测技术


为什么2007年的图灵奖选择了模型检测技术
像树一样成长,刚听完俞敏洪的在赢在中国的演讲----------题记

2007年图灵奖授予了在模型检测技术领域的奠基性贡献的科学家:Edmund M. Clarke、E Allen Emerson和Joseph Sifakis三位科学家。

什么是模型检测技术呢? 看看wikipedia 上的定义吧:
Model checking is the process of checking whether a given structure is a model of a given logical formula. The concept is general and applies to all kinds of logics and suitable structures. A simple model-checking problem is testing whether a given formula in the propositional logic is satisfied by a given structure.

简单的说:是一套用于判断硬件和软件设计的理论模型是否满足规范的方法。这可真是个抽象的描述,看起来似乎离我们很遥远,遥远的只有像英特尔研究中心副总 裁Andrew Chien才能对模型检测技术用一句话来评价:“英特尔和整个计算机工业都从他们的贡献中直接获益”。

那模型检测技术是不是离程序员也很遥远呢?图灵奖作为计算机界诺贝尔奖,如果把奖项颁给一个离程序员很遥远的技术,还真说不过去。

带着这个疑问,我浏览了wikipedia上长长的一窜模型检测技术的项目,还好不出所料,找到了下面几个项目:

1、Java Pathfinder :是一个用来认证java执行字节代码的系统。类似一个java虚拟机用来检测软件运行状态的验证系统。
2、Mono Model Checker :跑在mono 开源的.net平台上。用来自动侦查 CIL 字节码错误的程序。目前的版本支持CIL的死锁 deadlocks 和 断言冲突 assertion violation 。

3、对于c++ 感兴趣的人还可以看看这两个项目:
      State Exploring Assembly Model CheckerBounded Model Checking for ANSI-C

举个例子吧,在开发中,利用测试库junit 和 dotunit 写测试代码已经逐渐普及开了,比如下面这段:
public void testToppingsOnNewPizza()
{
Pizza pizza = new Pizza();
List toppings = pizza.getToppings();
assert( (toppings.size()==0) );
}
注意上面加黑的这句: assert( (toppings.size()==0) );

这段代码我们用来检测:pizza.getToppings()  的大小是否为0。那么模型检测和上面的测试代码有什么不同呢?

不同点在于:现在的测试库用来判断结果 , 而模型检测用来判断过程(逻辑)是否符合要求。

我们常说,不但要关注结果,更要关注过程。模型检测就是对过程的关注。

无疑,现在写程序的时候,模型检测的过程,是由广大程序员完成的。如果这个过程可以由机器完成的话?那不是就是实现了自动编程吗?据说word的创始人开发者正在干这样的事儿... ,不知道这个老头有生之年能不能实现他的理想。

当然,我也相信在更高级的人工智能技术中,模型检测技术会大展拳脚。

又是个遥远的事情,洗洗睡吧。



机器智能将会在2029年达到人类的水平

机器智能将会在2029年达到人类的水平
做最重要的事情,并且只有最重要的事情---题记


在过年回家的火车上,有一本《科幻杂志》吸引了我的兴趣。刚过了而立之年,还没有过上小康生活的我,早已对科幻失去了儿时的兴趣。这本杂志吸引我的地方是那份很有分量的序言。由于找不到电子版,我这里只大致把作者的观点重述一下。

作者的观点是:智慧与智慧载体的组成成分无关,而是与这些载体的组成方式有关。还好刚写到这句,我找到这篇文章,大家可以在这里查看:上帝死了?——人工智能的复杂性会最终超越人脑么?

刚才在digg的推荐列表中,看到了这篇文章:Machines 'to match man by 2029'。

2029年似乎是个很遥远的未来;大多数人对于此类预言的反应估计和我一样,看看标题就够了。不过因为上面文章还在我大脑中有些印象,所以我看了一下原文。

也推荐你看一下,因为预言者是  “
US National Academy of Engineering” 选中对21世纪重大科技有影响力的18个人之一,这其中也包括google创始人:Larry Page 和 基因工程的先行者:Dr Craig Venter。

下面是原文:

Machines 'to match man by 2029'

http://news.bbc.co.uk/2/hi/americas/7248875.stm

Machines will achieve human-level artificial intelligence by 2029, a leading US inventor has predicted.

Humanity is on the brink of advances that will see tiny robots implanted in people's brains to make them more intelligent, said Ray Kurzweil.

The engineer believes machines and humans will eventually merge through devices implanted in the body to boost intelligence and health.

"It's really part of our civilisation," Mr Kurzweil explained.

"But that's not going to be an alien invasion of intelligent machines to displace us."

Machines were already doing hundreds of things humans used to do, at human levels of intelligence or better, in many different areas, he said.

Man versus machine

"I've made the case that we will have both the hardware and the software to achieve human level artificial intelligence with the broad suppleness of human intelligence including our emotional intelligence by 2029," he said.

  We'll have intelligent nanobots go into our brains... to make us smarter

Ray Kurzweil

"We're already a human machine civilisation; we use our technology to expand our physical and mental horizons and this will be a further extension of that."

Humans and machines would eventually merge, by means of devices embedded in people's bodies to keep them healthy and improve their intelligence, predicted Mr Kurzweil.

"We'll have intelligent nanobots go into our brains through the capillaries and interact directly with our biological neurons," he told BBC News.


The nanobots, he said, would "make us smarter, remember things better and automatically go into full emergent virtual reality environments through the nervous system".

Mr Kurzweil is one of 18 influential thinkers chosen to identify the great technological challenges facing humanity in the 21st century by the US National Academy of Engineering.

The experts include google founder Larry Page and genome pioneer Dr Craig Venter.

The 14 challenges were announced at the annual meeting of the American Association for the Advancement of Science in Boston, which concludes on Monday.

seo优化:把百度放进数据库

seo优化:把百度放进数据库

 

        有时候我想,能把百度的数据放进数据库,用广大程序员熟悉的sql语句查询百度的搜索结果应该是一个不错的主意。在这方面Google早已经跨出了一大步,利用Google Search API 把Google的搜索结果放进数据库是很容易办到得。当然,Google Search API 有相应的限制,防止被人恶意使用。而百度则忙着在贴吧,新闻和 C2C 上大占拳脚,这些努力除了让百度的股价一再飙升外,对程序员来说一个 BaiDu Search API 仍然是遥不可及的事情。


        每家公司都有自己的策略,百度也不例外。既然百度不提供 BaiDu Search API ,这并不妨碍我们把百度放进数据库的想法往前推一步。

        实际上已经有人在这么做了(中文搜索关键词广告报告之广告主分析 ) , 而且还拿到了 IDG 的投资。

        这篇文章也给你一个工具:把百度放进数据库。 前提很简单,你必须有一个很大,很大的数据库。10个oracle , 100 个oracle,1000 个oracle ?打住吧,这不是本文的中心。

没人想全面 反向百度 (Reverse),就像 反向QQ的珊瑚中会挨打一样。我们只做一个简单的。

点击这里下载:BaiDu2DB , 把百度放进数据库,没数据库的就放到 Excel 吧 :-) 。

http://www.domolo.com/seo_software

 

下载地址:http://www.domolo.com/seo_software

SEO 比比看: Che168.com VS pcauto.com.cn

SEO 比比看: Che168.com  VS  pcauto.com.cn

        做SEO工作,平常少不了多观察各种网站优化的案例。俗话说的好,懂行的看门道,不懂的看热闹。面对五花八门的网站,如何才能从专家的角度,以最快的速度来了解被观察网站的优化方式呢?如何才能最快、比较全面的评判网站的优化效果呢?相信这是专业SEO面面临的共同的困难。

        这个系列将帮助您来解决上面提出的问题。这里我就用 che168.com 和 pcauto.com.cn 为例来一步步破茧抽丝吧。

        据说 che168.com 是王通优化的一个案例。 并且 che168 在google的排名是“一件恐怖的事情”。原话见“CHE168是他最近一年的案例,大家可以查一下相关汽车品牌在GOOGLE的排名,80%都在第一页,有些热门关键词甚至在第一位,这是非常恐怖的事情”。

这种恐怖的事情是如何发生的呢?

要做到快速,全面,很显然需要工具的帮助了。我这里选用: 多么乐站长SEO助手

XP用户请先下支持库:立即下载微软支持包 XP用户请把解压后的文件放在C盘根目录下执行.

第一步:了解 che168.com  和 pcauto.com.cn 的 域名,目录的组织方式:

这是 che168.com 的子域名列表:

这是 pcauto.com.cn 的子域名列表:

第二步:查询以上各个子域名在 google ,baidu ,yahoo 的索引量:

以下是 che168.com 在google 上的索引量。

以下是 pcauto.com.cn 各个子域名在 google 的索引量。

了解了子域名的分布,查看了他们的索引量,下一步,我们分析关键字排名。

百度BBS收录协议-生成器

百度BBS收录协议-生成器

无论对于普通网民还是搜索引擎,论坛中的信息无疑是一块最重要,甚至最大的信息来源。 然而由于论坛数据交互性极强,导致论坛的链接也比较多样。多样性的链接结构和不断更新的帖子内容对搜索引擎来说一直很头疼。这也就是为什么搜索引擎喜欢静态链接的原因之一。

当然,各搜索引擎巨头也在着力解决收录动态链接的方案。比如:
Yahoo搜索引擎推出动态网址URL的参数管理功能

最近百度也在这方面有所动作,在推出百度新闻提交协议后,又推出了:《百度互联网论坛收录开放协议


刚才忙活了半天,终于实现了这个功能:百度论坛收录开放协议生成工具。下载点击这里:http://www.domolo.com/seo_software

搜索引擎SEO外挂:一边搜索,一边看PageRank

搜索引擎SEO外挂:一边搜索,一边看PageRank

 

下载地址:多么乐站长工具 

 我原来曾写过一篇统计分析搜索引擎排名和Page Rank 关联分析 的文章。很多人引用,回复和我讨论了我的结论。有赞成的,有反对的,有鼓励的,有不以为是的。

当时我一直再想,如果有一个工具,能让seo爱好者们在搜索的同时看到Page Rank ,那该多好啊。

本着这个想法,用了一个周末的时间,我在 多么乐站长工具箱 完善了这个功能。

在这里我不想在重复我原来文章的观点,不管怎么说,有了数据,您自己也可以判断,不是吗?

 

 

 

搜索引擎seo外挂, 一边搜索,一边看Page Rank ,工作从此更惬意;

相关关键字生成器, 从google keywords center 提取最权威的关键字列表,让你的关键字从此无忧!

Baidu2Excel , Google2Excel ,把百度的搜索结果导出到Excel,自动提取域名,可以用Excel 的自动筛选分析批量关键字竞争情况

在线生成Google SiteMap, 也可以从 Apache 日志文件生成 google SiteMap 功能强悍,值得一试;

想知道百度有多少子域名吗? 想知道Sina有多少子域名吗? 利用子域名搜索引擎,一切介在掌握


1、PageRank 批量查询 , 现在的工具只能查一个网页,没有批量查询,现在您可以批量查询了;

2、网站 keywords , description , title 收割机, 分析网站总体 关键字 情况的最佳工具;

3、友情链接有效性检查,再也不怕对方偷偷撤下你的链接了,还可以同时查询对方的PageRank是否还符合要求哦;

4、搜索引擎收录,反向链接 一键查询, google , baidu , yahoo 统统支持,真是不错;

5、关键字搜索排名实时查看 , 多个关键字,多个网址 , 多对多匹配查询

6、网页关键字密度查询,关键字在网页和链接的密度查询,专门针对中文网站。

  

基于SEO的Log 日志分析软件应该提供那些功能?

基于SEO的Log 日志分析软件应该提供那些功能?



今天是连续第3个要过了12点才睡的日子了,希望今天可以告一个段落.

最近在考虑如何做基于 SEO 的日志分析工具, 每天都熬夜, 还真吃不消啊.


当 用户在浏览器地址栏输入一个网址的时候,web服务器在返回用户需要页面的同时也记录用户的其他数据,比如用户的浏览器是什么牌子的,用户使用的IP地 址,操作系统甚至记录了用户是输入的网址还是从其他链接跳转过来的等等。(好罗嗦)这部分记录无疑是最基础也是最重要的数据,很多web数据挖掘工作都是 从这里作为起点进行的。

看过web服务器(比如apache , iis )日志的朋友们都知道,当用户访问一个页面产生的日志并不是只有一行,而是有很多行。稍加注意就会发现,web服务器为当前访问页面中包含的每个文件(图 片、javascript脚本等)都生成了一行记录。这一行行的记录就组成了原始日志文件。

对SEO工作来说,分析日志是一项必不可少的 基本功。与SEO最相关的信息莫过于搜索引擎的来访记录和从搜索引擎带来的流量2个指标。目前国内网站用户使用的web log 日志分析工具大多使用 awstats 一类的开源工具。可以说awstats的流行,与日志分析爱好者的引荐是有很大关系的比如车东等人。

虽 然我也使用awstats等工具,但毫无疑问现在市场上专门针对seo的log日志分析工具还很少见。同时由于awstats采用perl编写,加上使用 awstats自有的文件格式,这就导致了在awstats的基础上加以修改提供基于seo的日志分析功能也非容易之事。

那么基于SEO的日志分析应该提供那些功能呢,这就是我这几天想的问题.

目前已经实现了以下三个部分:

1.从原始日志文件中提取 页面访问 的记录 .(去掉 .js , .css , .jpg 等记录)见:"原始Log -> 页面 Log "

2.针对提取出的 页面访问记录 进行派重 (bloom filter), 提取唯一的访问记录.见:"页面Log -> sitemap "

3.针对提取出的  页面访问记录 ,提取从 google 和 baidu 过来的搜索关键词 记录.
见:"页面Log-> 搜索关键字分析"


alpha 下载地址





基于SEO的日志分析


google 生活搜索--- 工作搜索数据来源调查

google生活搜索--- 工作搜索数据来源调查
贴图不说话

google-life-search-job-source

统计:抓虾热文的都是那些网站贡献的?

统计:抓虾热文的都是那些网站贡献的?


信息时代的牛人,就是能处理大数据量的牛人,google 算一个, 抓虾也算一个。

----------------------
截止小虾发稿时止,抓虾已经从 4,751,300 个博客和新闻频道中累计抓取了406,969,122 篇文章提供大家订阅阅读。 更多
----------------------

刚才整理回收站的时候,发现我6月份为抓虾热文做的统计数据,原来不准备发的。还是贴上来吧。只显示前50名。
数据来源:Domolo 抓虾热文阅读。    现有热文: 36169 篇。

 数量   抓虾热文博客 rss 域名
4991 feeds.feedburner.com
4131 www.maayee.com
3489 blog.sina.com.cn
2315 blog.techweb.com.cn
1970 null
1948 bullog.cn
1317 blog.donews.com
1096 www.dapenti.com
901 hi.baidu.com
884 www.diglog.com
705 technorati.com
699 www.20ju.com
563 www.cnbeta.com
536 www.wangtam.com
535 club.newdigi.com.cn
534 www.donews.com
479 my.donews.com
476 www.postshow.net
426 www.google.com
424 www.bepet.net
396 cn.engadget.com
394  
393 www.williamlong.info
391 bbs.siwa.cn
359 www.vsharing.com
356 www.cnblogs.com
352 www.technorati.com
332 item.feedsky.com
294 del.icio.us
267 daodao.org
267 www.gseeker.com
255 www.flickr.com
251 www.caobian.info
251 www.douban.com
249 blog.csdn.net
237 www.wangxiaofeng.net
232 bbs.hnol.net
232 bobo945.bokee.com
228 www.21manager.com
227 www.lifebang.com
223 www.amazon.com
222 www.ieyeh.com
218 www.mindmeters.com
205 xiaolang-naruto.blogspot.com
194 www.bullog.cn
186 www.dianping.com
185 www.lnuu.com
179 chinese.engadget.com
175 www.psytopic.com
 

MFC 中集成 Html 界面的3种方式

MFC 中集成 Html 界面的3种方式


最近考虑给Domolo SeoHelper 多么乐SEO助手 换上新装,全部用Html界面的方式表现。

据说 GTalk 就是用类似的方式实现的(?)。
灵感点滴 - GTalk的界面居然是用IE控件

雪狼窝: GTalk聊天界面应该是基于IE内核的?

现在看来可行的方式有3种:他们的区别是 程序代码和html 交互的机制不同;

1、如果是弹出对话框的方式,且用户交互项比较简单,建议采用:SHOWHTMLDIALOGFN 的方式来实现,windows.args 脚本的方式来通讯;

2、如果设计到的网页较多,且需要动态生成,建议参考 MSDN 上的这篇文章;
using your CHtmlCtrl in my dialog-based app


3、对于实现的功能比较复杂,用户交互性强的程序,只好派出王牌杀手了:CDHTMLView 了,参考这篇:Integrating DHTML into MFC Views


另:今天实现了很久前就想做的一个功能 博客搬家客户端的核心代码 ,也就是用程序的方式发表博客,可以做到写一篇博客发送到多个BSP上。

原来的博客搬家是服务器端的,现在准备做一个客户端的版本,敬请期待。


本来昨天下班后就写好了,结果今天启动机器用了快半个小时,打开后一看,内存用了1.2G。晕。
 

抓虾的暗示

抓虾的暗示

 

Flick 原是开发游戏的框架,现在成功是顺势而变的结果---题记

 

今天看到keso的博客列举了自己“始终不看好同样采用Digg模式的抓虾热文的原因”。这里我们先抛开抓虾热文是否采用digg模式不说,单单说说抓虾热文是否有用。经常阅读keso博客的朋友们一定还记得这篇:“东拉西扯:过滤器与民主的悖论”,我非常同意他的这个结论:“只有当用户意识到他所获得的信息,以及所联络的人群,越来越同质化,甚至影响了他的视野和对事物的判断,他自会做出调整。”。

 

那么现在我的问题是:用户如何做出调整?用户从那里发现热点?浏览不同的博客,热文是一个很好的途径,因为用户不知道如何发现热点(据说google要推出一个类似流行词语的英文产品)。在这个前提下“抓虾的读者五花八门,兴趣相差甚远”,就成了我们发现热点的一个很好的来源。

 

我想大部分朋友都认同,抓虾热文比“好看”更有价值。平遥的牛肉是:肥而不腻,瘦而不柴;抓虾热文则是:博而有聚,精彩活波。很适合现代人阅读,是阅读,不是因为工作,学习原因的哪类阅读。所以对“10大方法“5条秘籍“100条建议大可看看无妨。

 

当然,对我来说,抓虾的确站在了一个比较尴尬的地位。抓虾的定位是阅读工具,而我却用它来发现热文,然后订阅到Google Reader 来阅读。当我感觉到陷入“过滤与民主的悖论”的时候,抓虾热文帮助我做出了调整。

 

我想抓虾应该向大家说明热文的来源,另外抓虾的定位也并不是digg 类型的。

 

一句话,我支持抓虾热文现在的模式,这也是每天我访问抓虾的唯一理由。这个观点我也在英雄大会上我曾向徐易容和谌振宇提到过。(我非常喜欢这个功能,以至于我自己做了一个抓虾外挂来更好的使用这个功能。)

 

 

面对批评,希望抓虾不要做出太激进的调整,做到充分了解需求持续改进。

 

Keso 2篇文章我印象深刻,1东拉西扯:工具和暗示 2 怎么会是新浪?我也写了: 怎么会是lucene?  抓虾的暗示,这篇文章是我看完东拉西扯:工具和暗示后就想写的,算是对上了吧

 

推荐阅读:RSS:摘要还是全文,这是个问题?

 

 

Domolo SEOHelper 多么乐SEO工具:璀璨登场

Domolo SEOHelper 多么乐SEO工具:璀璨登场




六大功能
1、PageRank 批量查询 , 现在的工具只能查一个网页,没有批量查询,现在您可以批量查询了;
2、网站 keywords , description , title 收割机, 分析网站总体 关键字 情况的最佳工具;
3、友情链接有效性检查,再也不怕对方偷偷撤下你的链接了,还可以同时查询对方的PageRank是否还符合要求哦;
4、搜索引擎收录,反向链接 一键查询, google , baidu , yahoo 统统支持,真是不错;
5、关键字搜索排名实时查看 , 多个关键字,多个网址 , 多对多匹配查询

6、网页关键字密度查询,关键字在网页和链接的密度查询,专门针对中文网站。


让您每天的工作量节省一半 , FreeWare 承诺终身免费!!!


相关阅读:给站长们的一把瑞士军刀

地址: http://www.domolo.com/seo_software 或者 这里

网友评价:

shranker :
支持 谢谢 正在下。。


网络之心
看得热血沸腾,我下一个用用。
alan1021
这么好的工具,不下不行啊

RSS:摘要还是全文,这是个问题?

RSS:摘要还是全文,这是个问题?

在Feedburner 的官方博客上有篇关于RSS输出正文还是摘要更有利于ClickThrouth的分析 。FeedBurner(现在维护 660,000个 feeds) 的分析研究表明对于RSS输出全文还是摘要,对ClickThrough 的贡献都是大致相当的。毫无疑问,这是又一个有悖于直觉的数据统计结论。这个结论无疑对于那些只在RSS中提供摘要吸引用户打开新网页才能查看全文的网站 来 说是多么沮丧的啊。

那么造成这种结论的原因是什么呢?

文中分析指出了原因:当用户订阅rss feed后,会逐渐订阅更多的的feeds,更多的feeds就意味着用户在feed 阅读器外“点击查看原文”后要花更多的时间来阅读,消化。也就是说基于feed 的阅读是:耗时的消费导向的,不是以类似点击等为焦点的。

文中还分析了这些网站的其他的一些动机,都是能想到的原因,这里不多说了。

但实际上,很多内容提供商和博客主倾向于提供摘要的RSS发布,而不是全文发布。也许我们还应该加上另一个原因:防止拷贝,特别是在国内拷贝风气日盛的情况下,RSS标准的格式为拷贝内容的人提供了莫大的便利。(我曾实验 用聚合来代替拷贝,不算是偷换概念吧,奇虎早这么干了)

FeedBurner(现在维护 660,000 个feeds),我相信他的分析是基于原始数据的。看来以后RSS输出到底是全文还是摘要,就全凭兴趣了。

RSS:摘要还是全文,这是个问题?

Google的Sawzall,Yahoo的Pig猪和微软的Dryad

Google的Sawzall,Yahoo的Pig猪和微软的Dryad



Greg 最近写了篇介绍Google,Yahoo,微软三大巨头公司分布式架构的Blog。这就是:Google的Sawzall,Yahoo的Pig 猪和微软的Dryad

这真是一个信息爆炸的时代,在这个大背景里消耗CPU最多的计算会越来越多从“软件本身性能提升”逐渐转移到信息处理的过程中。描述计算速度提高的摩尔定 律,据说现在还仍然有效,可 ”Andy giveth, and Bill taketh away“ 的名言似乎应该改为:"Andy giveth, and google(...) taketh away" 了。

言归正传,Yahoo猪年行大礼,在五一期间放出了:PIG 猪 。(猪非彼 ) Yahoo Pig 是一个运行在HadoopDoug Cutting 在06年3月份加入了Yahoo 上的并行处理架构,有了Pig 使得普通的程序员具有了分析处理gigantic数据集的能力。附带一下 Hadoop 基本进入了实用阶段 Amazon 的 EC2 S3已经在使用了Hadoop了。
Yahoo Pig 有如下特点:
1、专注于于大量数据集分析(
ad-hoc analysis , ad-hoc 代表:a solution that has been custom designed for a specific problem );
2、运行在集群的计算架构上,Yahoo Pig 提供了多层抽象,简化并行计算让普通用户使用;这些抽象完成自动把用户请求queries翻译成有效的并行评估计划,然后在物理集群上执行这些计划;
3、提供类似 SQL 的操作语法;
4、开放源代码;

从对 Yahoo Pig 的了解来看,推荐大家使用,Google Sawzall 和 Microsoft Dryad 就别指望了。

Google Sawzall 是google labs 很早就释放出来了,虽然两者都是定位于分布式并行计算的架构,实现方式却大相径庭。
Sawzall 是基于MapReduce 的,变成语法类似于 java 和 c 语言。

下面是 Sawzall 代码的例子:
proto "querylog.proto"
static RESOLUTION: int = 5; # minutes; must be divisor of 60
log_record: QueryLogProto = input;
queries_per_degree: table sum[t: time][lat: int][lon: int] of int;
loc: Location = locationinfo(log_record.ip);
if (def(loc)) {
  t: time = log_record.time_usec;
  m: int = minuteof(t); # within the hour
  m = m - m % RESOLUTION;
  t = trunctohour(t) + time(m * int(MINUTE));
  emit queries_per_degree[t][int(loc.lat)][int(loc.lon)] <- 1;
}
下面是Pig 代码的例子:
a = COGROUP QueryResults BY url, Pages BY url;
b = FOREACH a GENERATE FLATTEN(QueryResults.(query, position)), FLATTEN(Pages.pagerank);
c = GROUP b BY query;
d = FILTER c BY checkTop5(*);

很显然,如果大家需要对结构化(半结构化)的数据进行分析处理时 Pig 的 SQL 的语法更便于掌握。

具体参考Yahoo Pig 的其他例子:

Pig Latin Examples:
Example 1: Word Count
Example 2: Map/Reduce
Example 3: Pages and Queries
Example 4: PageRank


无独有偶,微软的Dryad 集成Linq (随着.net 2.0 正式发布了) 后叫: DryadLINQ 。从个人角度讲我一直看好 Linq 这个产品,出身Aders不说,程序语言和数据处理合2为1对简单的Insert ,update ,delete,query 完全应该集成起来。这一点也是我喜欢Rails的原因吧。



目前微软的  Dryad 已经在 Microsoft's AdCenter 投入使用。


我想用Yahoo Pig 的话,做 Log 分析应该比较适合。

参考资料:
sourcelab
Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks

MapReduce BBS 

DomoloSEOHelper 多么乐SEO助手 预览版发布啦

DomoloSEOHelper 多么乐SEO助手 预览版发布啦

装修是一件烦人的事情,但能亲手参与一次,还是值得的---题记

   

        漫长的装修工程终于结束了。装修的时候最好奇的还是,看到泥工、瓦工、油工的 工具箱 toolkit。有了各式各样的工具,木板、瓷砖、大理石面板就像七巧板一般被组合成了门、橱柜等家居。只要有了恰当的工具,一切皆有可能。

       俗话说,工欲善其事,必先利其器。做SEO也需要有一把顺手的瑞士军刀才行。我相信有了数据,SEO将逐渐归于平淡,由诀窍层次的竞争,转为运营实力的竞争。

        论中国SEO的可持续发展 一文中列出了中国SEO面临的问题,其中提到了SEO工具的缺乏。我希望我可以为这块缺陷添砖加瓦。这也就是 DomoloSEOHelper 的由来。

         现在正式发布“预览版”。收集一下大家的需求。争取早日发布alpha版。

 

 

 

 

 

 http://www.domolo.com/seo_software 

DomoloSEOHelper 的目标很简单  , 就是把下表数据化:

[数据统计]:百度在调低索引库的容量

[数据统计]:百度在调低索引库的容量

宇宙在膨胀,搜索引擎索引库也是---题记


如何监测搜索引擎索引库的膨胀率是我最近关心的一个问题。随着网络的深入应用,越来越多的资料被放到了网络上;搜索引擎会对公开的资料加以收录,建立索引并服务于广大的网民。对于搜索引擎来说,如何达到搜全,搜新,有用,准确的要求,在数据爆炸的时代不能不说是一个严峻的挑战。

据悉 百度在07年第一季度斥资 1.5亿打造数据中心 ,很显然现在百度正在不断加强基础设施,以面对互联网数据爆炸的时代。无独有偶,最近美国的北卡州政府为了吸引google把数据中心建在本州,竟然抛出了免税的橄榄枝。更有甚者把全球变暖和google庞大的数据中心联系起来。

我的前一篇“[数据统计] 搜索引擎索引库:百度大于雅虎中国 之一”,有很多否定意见的回复。不过我仍然坚持我的观点。因为对于搜索引擎来说,特别是对于上百万级的site:统计来说,能了解数字的趋势,比数字本身更重要。


回到本文的正题,如何监测搜索引擎索引库的膨胀率呢?很显然这又是一个不好回答的问题。这里面涉及到了太多的因素。
比如:搜索引擎是如何对待那些过时的数据呢?搜索引擎的排重是如何进行的呢?更重要的是我们可以通过那些指标来进行衡量?


我做了一个抽样调查:
数据来源:
1、Alexa Top100 的中文网站
2、Alexa Top100 的中文网站 在 3月份的 搜索引擎索引量 
  (来源见这里

 注:google最后3天的统计数据为0。(被google封了 :) )


可以看出 在3月份百度整体调低了索引库的容量,而google的基本保持稳定。

SEO 助手, PageRank 批量查询器