| 春峰 的个人资料我要去桂林照片日志列表 | 帮助 |
我要去桂林田春峰 I TouchI 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 Checker , Bounded Model Checking for ANSI-C 。 举个例子吧,在开发中,利用测试库junit 和 dotunit 写测试代码已经逐渐普及开了,比如下面这段: public void testToppingsOnNewPizza()注意上面加黑的这句: assert( (toppings.size()==0) ); 。 这段代码我们用来检测:pizza.getToppings() 的大小是否为0。那么模型检测和上面的测试代码有什么不同呢? 不同点在于:现在的测试库用来判断结果 , 而模型检测用来判断过程(逻辑)是否符合要求。 我们常说,不但要关注结果,更要关注过程。模型检测就是对过程的关注。 无疑,现在写程序的时候,模型检测的过程,是由广大程序员完成的。如果这个过程可以由机器完成的话?那不是就是实现了自动编程吗?据说word的创始人开发者正在干这样的事儿... ,不知道这个老头有生之年能不能实现他的理想。 当然,我也相信在更高级的人工智能技术中,模型检测技术会大展拳脚。 又是个遥远的事情,洗洗睡吧。 |
|
||||
|
|