Archive for 十月, 2010

1.   Can’t connect to https://dl-ssl.google.com/android/repository/repository.xml

WorkArounds:

Add proxy in “Settings”

Select “Force https://… sources to be fetched using http://…” in “Misc” tab.

android sdk config

2.   Can’t install Update 7. Error prompt:

Folder failed to be renamed or moved on SDK install

Solution available on http://code.google.com/p/android/issues/detail?id=4410, which is a useful link to query the android open issues. Also abstract the useful one on my PC.

WorkArounds:

I had the same problem: the latest update failed to install because it couldn’t rename the tools folder in android-sdk-windows.  I’m using Avira antivirus and disabling it didn’t help, but I don’t think it had anything to do with the AV program anyway.

Fact is, running the Android SDK setup apparently uses items in the “android-sdk-windows\tools” directory.  I’m on Win 7 x64 so maybe that causes some unique situation – I’m not sure.

Solution:

– I made a copy of the tools folder itself (keeping it at the same directory tree level, thus “tools” and “tools-copy” were both in the “android-sdk-windows” folder).

– I ran Android.bat from that copy

– I ran the update without problems (it updated the original, not-being-used-at-the-moment tools folder, among whatever other items it needed to).

– I closed the SDK, deleted the folder (I had to kill the adb.exe process first – not sure why that always persists but you can’t delete the folder without doing that).

– I restarted the SDK from the normal (now-updated) tools folder.  Worked like a charm!

Note that simply killing adb.exe was NOT sufficient to get around the original issue… only by copying the tools folder and using the copy to run Android for the duration of the update process was enough to rectify the problem.

Tips for SDK configuration:

  1. Add the following environment path and restart:

ANDROID_SDK_HOME  E:\

This very helpful. First, save our C:\ space. SDK will save the created AVD and configurations to C:\Documents and Settings\<user>\.Android by default.  After add the environment path, these will be saved under E:\.Android . Second, reinstall system will not impact the SDK configuration.

TO BE ADD MORE.

Just collection and add some notes.

Abstract from http://androidappdocs.appspot.com/sdk/index.html

Eclipse IDE

  • Recommended versions: Eclipse 3.4 (Ganymede) or 3.5 (Galileo)

Caution: There are known issues with the ADT plugin running with Eclipse 3.6. Please stay on 3.5 until further notice.

  • Eclipse JDT plugin (included in most Eclipse IDE packages)
  • Several types of Eclipse packages are available for each platform. For developing Android applications, we recommend that you install one of these packages:
    • Eclipse IDE for Java EE Developers
    • Eclipse IDE for Java Developers
    • Eclipse for RCP/Plug-in Developers
    • Eclipse Classic (versions 3.5.1 and higher)
  • JDK 5 or JDK 6 (JRE alone is not sufficient)
  • Android Development Tools plugin (optional)
  • Not compatible with Gnu Compiler for Java (gcj)

My workspace: Eclipse 3.5.1 Galileo (include JDT plugin)+ JDK 1.5.0_15 + SDK (update to version 7)

代码上传到了google code:http://code.google.com/p/crawl-tianya-php/

在天涯论坛看小说,水太多了

只想看楼主,想存为文本,想放在ipad、手机里看?

所以写了这个php脚本,利用 http://phpdom.comsing.com 解析html代码,根据第一篇帖子的url,抓取后续所有页面的楼主内容。

下载之后,解压,查看read.php里的php路径是否正确,执行方式:

./read.php “http://www.tianya.cn/publicforum/content/funinfo/1/2309593.shtml” tmp.txt

转载请注明:http://duanple.blog.163.com/blog/static/70971767201091102339246/ 作者 phylips@bmy

为了能够支持可扩展的并行化,google的网络搜索应用让不同的查询由不同的处理器处理,同时通过划分全局索引,使得单个查询可以利用多个处理器处理。针对所要处理的工作负载类型,google的集群架构由15000个普通pc机和容错软件组成。这种架构达到了很高的性能,同时由于采用了普通pc机,也节省了采用昂贵的高端服务器的大部分花费。

很少有网络服务的单个请求像搜索引擎占用那样多的计算资源。平均来看,在google上的每次查询需要读取数百m的数据耗费数10亿的cpu指令循环。为了能够支持峰值在每秒数千次请求流,需要与世界上最大的超级计算机规模相当的硬件设施。通过容错性软件将15000个普通pc机联合起来,提供了一种比使用高端服务器更廉价的解决方案。

本文我们将介绍google的集群架构,讨论那些影响到设计方案的最重要的因素:能效和性价比。在我们的实际操作中,能效实际上是一个关键的度量标准,因为数据中心的电力是有限的,因此电力耗费和制冷成为运作中的关键。

我们的应用本身可以很容易进行并行化:不同的查询可以运行在不同的处理器上,同时全局索引也划分的使得单个查询可以使用多个处理器。因此,处理器的性价比比峰值性能变得更重要。同时,google的应用是面向吞吐率的,可以更有效的利用处理器提供的并行化,比如并行多线程(SMT),或者多核处理器(CMP)。

Google架构概览

Google的软件架构来源于两个基本的观点。首先我们需要在软件层面提供可靠性,而不是通过硬件,这样我们就可以使用普通的pc构建廉价的高端集群。其次,我们不断的裁剪设计是为了达到最好的总体请求吞吐率,不是为了提高服务器的峰值响应时间, 因为我们可以通过并行化独立的请求来控制响应时间。

我们相信使用不可靠的廉价pc来构建可靠的计算设施可以达到最好的性价比。通过在不同的机器上备份服务,以及自动化的故障检测和错误处理,为我们的环境提供软件级的可靠性。这种软件级的可靠性在我们的系统设计中几乎随处可见。检查一下一次查询处理的控制流程,有助于理解这种高级的查询服务系统,同时也有助于对于可靠性考虑的理解。

Google的一次查询

当用户在google中输入一次查询,用户浏览器首先通过DNS进行域名解析,将www.google.com转换为ip地址。为了对查询可以进行更有效的处理,我们的服务由分布在世界各地的多个集群组成。每个集群大概有数千个机器,这种地理上的分布可以有效的应付灾难性的数据中心失败比如地震,大规模的停电。基于DNS的负载平衡系统,会计算用户的与每一个物理集群地理上的距离来选择一个合适的物理集群。负载平衡系统,需要最小化请求往返时间,同时要考虑各个集群的可用容量。

用户浏览器然后给这些集群中的一个发送一个http请求,之后,对于该集群来说,所有的处理都变成了本地化的。在每个集群中有一个基于硬件的负载平衡器监控当前可用的google web servers(GWS)集合,并在这个集合上将本地的请求处理进行负载平衡。收到一个请求之后,GWS协调这个查询的执行,并将结果格式化为html语言。图1表示了这个过程。

面向星球的网络搜索:google集群架构 - 星星 - 银河里的星星

查询执行由两个主要阶段组成,第一个阶段,索引服务器查阅倒排索引(将每个查询词映射到匹配的文档列表)。索引服务器然后决定相关的文档集合,通过对每个查询词匹配的文档列表求交集,为每个文档计算出一个相关性的分值,这个分值决定了在输出结果中的排序。

搜索的过程非常具有挑战性,因为需要处理海量数据:原始网页文档通常具有数十T的未压缩数据,从原始数据中导出的倒排索引本身也有好几T的数据。幸运的是,通过将索引划分到不同的片段,可以将搜索高度并行化,每个片段具有从全布索引中随机选择的一个文档子集。一组机器负责处理对于一个索引片段的请求,在整个集群中每个片段都会有这样的一组机器与之对应。每个请求通过中间负载平衡器选择组内机器中的一个,换句话说每个查询将会访问分配到每个片段的一台机器(或者是一组机器的子集)。如果一个片段的备份坏了,负载平衡器将会避免在查询时使用它,我们的集群管理系统的其他组件将会尝试修复它,实在不行就用另一台机器来取代它。停工期间,系统的容量需要减去那台坏掉的机器所代表的容量。然而,服务仍然是未中断的的,索引仍然是可用的。

第一阶段的查询执行最终输出一个排过序的文档标识符列表。第二阶段则通过获取这个文档列表,然后计算出所有文档的标题和url以及面向查询内容的文档摘要。文档服务器处理这项任务,从硬盘中获取文档,抽取标题以及查询关键词在文档中的出现片段。像索引查找阶段,这里的策略也是对文档进行划分,主要通过:随机分布文档到不同的小片段;针对每个片段的处理具有多个服务器作为备份;通过一个负载平衡器分发请求。文档服务器必须能够访问一个在线的低延时的整个网络的网页的副本。实际上由于对于这个副本的访问需要性能及可用性,所以google实际上在集群中存储了整个web的多个副本。

除了索引和文档服务阶段,GWS在收到查询时还会初始化几个其他的辅助任务,比如将查询发送给拼写检查系统,广告系统生成相关广告。当所有阶段完成后,GWS生成html输出页面,然后返回给用户浏览器。

使用备份进行容量扩充和容错

我们对系统进行了一些结构化以保证对于索引和其他响应查询相关的数据结构是只读的:更新是相对不频繁的,这样我们就能通过将查询转移到一个服务备份来安全的进行更新。 这条原则,使得我们避免了很多在通用数据库中出现的一致性问题。

我们也尽力挖掘出大量应用中的固有的并行性:比如我们将在一个大索引中的匹配文档的查询转化为针对多个片段中的匹配文档的多个查询加上开销相对便宜的归并步骤。类似的,我们将查询请求流划分为多个流,每个由一个集群来处理。增加为每个处理索引片段的机器组增加机器来增加系统容量,伴随着索引的增长增长片段的个数。通过将搜索在多个机器上并行化,我们降低了响应一个查询的必需的平均延时,将整个计算任务划分在多个cpu和硬盘上。因为独立的片段相互之间不需要通信,所以极速比几乎是线性的。换句话说,单个索引服务器的cpu速度不会影响整个搜索的整体性能,因为我们可以增加片段数来适应慢的cpu,因此我们的硬件选择主要关注那些可以为我们的应用提供出色的请求吞吐率的机器,而不是可以提供最高的单线程性能的那些。

简单来说,google的集群主要遵循下面三个主要设计原则:

软件可靠性。我们没有选择硬件性容错,比如采用冗余电源,RAID,高质量组件,而是专注于软件可靠性。

使用备份得到更好的吞吐率和可用性。因为机器本身是不可靠的,我们备份我们的内部服务在很多机器上。通过备份我们得到了容量,与此同时也得到了容错,而这种容错几乎是免费的。

性价比重于峰值性能。我们购买当前最具性价比的cpu,而不是那些具有最高绝对性能的cpu。

使用普通pc降低计算花费。这样我们可以为每一个查询提供更多的计算资源,在ranking算法中使用更昂贵的技术,可以搜索文档的更大的索引。

使用商业化部件

Google的机柜是专门定制的,由两面组成,总共放置了40到80个基于80×86的服务器(每侧包含20个20u或者40个10u服务器) 。我们对于性价比的偏爱,使得我们选择自己组装的桌面pc通过它们的组件,除了选择大的硬盘驱动器。目前的服务中使用了好几个cpu产品,从533m intel-celeron 到双核1.4G Intel奔三服务器。每个服务器包含一个或者多个IDE硬盘,每个80g空间。与文档服务器相比,索引服务器通常具有更少的磁盘空间,因为它的负载类型是对cpu更敏感。在机柜一侧的服务器通过一个100m 以太网交换机相连,该交换机通过一个或者两个GB级的链路与一个核心的GB交换机相连,该核心交换机连接所有的机柜。

我们的根本选择标准是单次查询花费,可以表示为性能/资金花费总和(包括折旧)+管理花费(主机,系统管理,维修)。实际来看,一个服务器的寿命通常不会超过2,3年,因为与新机器相比,无法在性能上保持一致。三年前的机子性能上要远远落后于当前的机子,对于包含这两类机器的集群,很难达到合适的负载分布和配置。有了这个相对的短期分摊周期,可以看到设备的花费在总的开销中占到相当的一部分。

因为google服务器是专门定制的,我们可以使用基于pc的服务器机柜价格做一个展示。比如在2002年,一个88 个双核cpu 2G intle xeon,2G内存,80G硬盘的机柜在RackSaver.com上的价格大概是27800$,转换成三年周期每月的花费将是7700$。剩下的主要花费是人力和hosting。

设备花费的相对重要性使得采用传统的服务器解决方案并不适合解决我们的问题,因为虽然它们可以提高性能,但是降低了性价比。比如4处理器的主板是很昂贵的,由于我们的应用已经进了很好的并行化,这样的主板不需要额外的花费就能获得很好的性能.类似的,尽管SCSI硬盘更快也更可靠,但是它们通常比同样容量的IDE硬盘贵2-3倍。

使用基于基于廉价的PC的集群比使用高端多处理器服务器在成本上的优势是非常明显的,至少对于像我们这样的高并行化应用来说。上面例子中的27800$的机柜包含176个2G Xeon CPU,176G内存,7T硬盘空间。与此相比,一个典型的x86服务器具有8个2GCPU,64G内存,8T硬盘空间,花费大概758000$。换句话说,这个服务器贵了3倍,但是cpu只是原来的1/22,内存是1/3,硬盘空间稍微多了点。价格的差距,主要是源于更高的互联网络带宽和可靠性。但是google的高度冗余架构并不依赖于这两个中的任何一个。

管理数千台中型PC机和一些高端多处理器服务器将会带来完全不同的系统管理和维修费用。然而,对于一个相对同构的的应用来说,大部分的服务器只用来运行少数应用中的一个,这些开销是可管理的。加速安装和更新工具都是可用的,维护1000台和100台服务器所需的时间和成本相差并不大,因为所有的机器都具有相同的配置。类似的,通过使用可扩展的应用监控系统,监控的花费伴随这集群的大小增长也不会有太大的增长。另外,我们可以通过批处理修复将修复的开销保持在一个较低的水平,同时保证我们可以很容易的替换掉那些具有高损坏率的组件,比如硬盘和电源。

电力问题

如果没有特殊的高密度包装,电力消耗和制冷设备将会成为一个挑战。一个中型的1.4G奔三服务器在有负载情况下,通常要耗费90w直流电:55w给cpu,10w给硬盘,25w给DRAM加电和主板,对于一个ATX电源,通常具有75%的效率,这样转化成交流电就是120w,每个机柜就需要10kw。一个机柜需要25 ft2 的空间,这样算下来,用电的密度就是400w/ft2。如果采用高端处理器,一个机柜的用电密度可以超过700w/ft2。

不幸的是,通常的商业数据中心电力密度在70-150w/ft2之间,远远低于pc集群的需求。这样,如果低端pc集群使用相对直接的包装方式,就需要特殊的制冷和额外的空间来降低用电密度使得与标准数据中心兼容。因此只要机柜还存放在标准数据中心中,如果想要往机柜里增加服务器就会在实际部署中收到限制。这种情况就使得我们考虑降低单服务器的电力使用是否是可能的。

对于大规模集群来说,低功耗服务器是非常具有吸引力的。但是我们必须要牢记以下几点:降低电力是迫切的,但是对于我们的应用来说,不能带来性能上的惩罚,我们关心的是每单元性能的瓦特,不是单纯的瓦特,第二,低功耗的服务器必须不能太过昂贵,因为服务器的折旧花费通常要超过电力的花费。前面提到的10kw机柜,每月大概消耗10mwh的电力(包括制冷的开销),假设每kwh电15美分,这样每月需要花费1500$,与折旧的7700$相比并不算大。因此低功耗服务器不能够多于我们通过采用常规pc节省下的那部分花费。

硬件级别的应用特点

检查我们应用的各种架构特点可以帮助我们搞清楚哪种硬件平台可以为我们的索引查询系统提供最高的性价比。我们着重于索引服务器的特点,该模块的性价比对于整体的性价比起着主导性的作用。索引服务器的任务主要包括:对倒排索引中的压缩数据进行解压,找到与一个查询相匹配的文档集合。表1展示了一些索引服务器程序的基本的指令级别的度量,程序运行在一个1G双核奔三系统上。

面向星球的网络搜索:google集群架构 - 星星 - 银河里的星星

考虑到奔三每个circle基本上可以处理三条指令,可以看到该应用程序的CPI(cycles per instruction)稍微偏高。我们可以预见到这种行为,考虑到我们的应用程序使用了很多动态数据结构而控制流是依赖于数据的,这样就会产生大量的很难预测的分支。事实上,如果相同的工作负载在奔四处理器上运行时,CPI几乎增长了2倍,分支预测几乎相同,尽管奔四具有更强大的指令并行和分支预测功能。可见,在这种工作负载类型下,并没有太多的指令级并行性可供挖掘。测量结果显示,对于我们的应用来说,出现在处理器中的大量的乱序不确定性执行成为降低程序性能的关键点。

对于像索引服务器这样的应用来说,更合适的挖掘并行性的方式应该是提高平凡的计算并行性。系统在处理每个查询时共享只读数据,建立只需要很少通信的工作单元。我们在集群级别上通过部署大量的廉价节点取代少量的昂贵节点来发挥这个优势, 挖掘在微架构级别上的线程级并行性看起来也是可行的。并行多线程(SMT)和多处理器架构(CMP)都是面向线程级的并行性,都可以大大提高我们的服务器的性能。一些针对Intel Xeon处理器的早期实验表明通过使用两个上下文的SMT比单个上下文具有30%的性能提升。

我们相信对于CMP系统提升的潜力应该是更大的。在CMP的设计中,采用多个简单的,按序执行的,短流水线核取代复杂的高性能核。如果我们的应用具有很少的指令级并行性(ILP),那么由于按序执行所带来的性能惩罚也是很小的。同时短流水线将可以减少甚至排除分支预测失败所造成的影响。线程级的并行性伴随着核的增长可以呈现出接近线性的加速比,同时一个合理大小的共享L2 cache将会加速处理器间的通信。

内存系统

表1 也描述了主存系统的性能参数,我们可以观察到对于指令cache和指令tlb具有良好的性能,由于使用了较小的内层循环代码。索引数据块不具有时间局部性,因为索引数据大小变化剧烈同时对于索引的数据块访问模式是不可预测的。然而对于一个索引数据块的访问可以从空间局部性上获益,这种局部性能够通过硬件预取或者大的缓存line开拓出来。这样如果使用相对合适cache大小就可以得到好的全局cache命中率。

内存带宽看起来并不会成为一个瓶颈。我们估计奔腾系列处理器系统的内存带宽使用率可以很好的控制在20%以下。主要是由于对于索引数据的每个缓存行,需要放到处理器cache里,这需要大量的计算资源,此外在数据获取中还存在天然的依赖关系。在很多情况下,索引服务器的内存系统行为正如TPC-D(Transaction Processing Performance Counicil’s benchmark D)所报告的那样。对于这种工作负载类型,采用一个相对合适的L2cache大小,短的L2 cache和内存延时,长的(比如128字节)cache line可能是最有效的。

大规模多处理

正如前面提到的,我们的设备是一个由大量廉价pc组成的庞大集群,而不是少数大规模的共享内存机组成的。大规模共享内存机主要用于在计算通信比很低的时候,通信模式或者数据划分是动态或者难预测的,或者总的花费使得硬件花费显得很少的时候(由于管理日常费用和软件许可证价格)。在这些情况下,使得它们的高价格变得合理。

在google,并不存在这样的需求,因为我们通过划分索引数据和计算来最小化通信和服务器间的负载平衡。我们自己开发需要的软件,通过可扩展的自动化和监控来降低系统管理的日常费用,这些使得硬件花费成为整个系统开销中显著的一块。另外,大规模的共享内存机器很好的处理硬件或者软件的失败。这样大部分的错误可能导致整个系统的crash。通过部署大量的多处理器机,我们可以将错误的影响控制在一个小的范围内。总的来看,这样的一个集群通过明显的低成本解决了我们的服务对于性能和可用性的需求。

初看起来,好像很少有应用具有像google这样的特点,因为很少有服务需要数千台的服务器和数pb的存储。然而可能有很多的应用需要使用基于pc的集群架构。一个应用如果关注性价比,能够运行在不具有私有状态的多个服务器上(这样服务器就可以被复制),它都有可能从类似的架构中获益。比如一个高容量的web服务器或者一个 计算密集型的应用服务器(必须是无状态的)。这些应用具有大量的请求级并行性(请求可以划分在在独立的服务器上处理)。事实上,大的web站点已经采用这样的架构。

在google规模上,大规模服务器的并行化的一些限制确实变得明显起来,比如商业数据中心在制冷容量上的限制,当前的cpu对于面向吞吐率的应用所做的优化还远远不够。虽然如此,通过使用廉价pc,明显地提高了我们可以为单个查询所能支付的计算量。因此有助于帮助我们提高成千上万的用户的网络搜索体验。

致谢

在这些年里,很多人为google的硬件架构做出了重要的贡献。在这里,特别感谢Gerald Aigner ,Ross Biro,Bogdan Cocosel 和Larry Page所做的工作。

Collaborative Filtering Resources

maintained by Jun Wang

Generally, collaborative filtering (CF) is any algorithm that filters information for a user based on a collection of user profiles. Users having similar profiles may share similar interests. For a user, information can be filtered in/out regarding to the behaviors of his or her similar users.

Users profiles can be collected either explicitly or implicitly. One can explicitly ask users to rate what they have used/purchased. Such a profile is filled explicitly by the users ratings. An implicit profile is based on passive observation and contains users historic interaction data.

The most common usage of CF is to make recommendation. That’s why collaborative filtering is strongly correlated to recommender system in literature, although CF is only one of the methods for recommender system.

In this page, I collected some useful online materials for collaborative filtering research.


Content


Research Software


Data Sets

Explicit Rating Data Sets:

Implicit Rating Data Sets:

  • Audioscrobblers Music Play-list Data-sets.The Audioscrobbler dataset collects the play-lists of the users in a one-line community (http://www.audioscrobbler.com/) by using a plug-in in the users’ media players such as Winamp, iTunes, XMMS etc. The plug-ins send the title and artist of every song users play to the Audioscrobbler server, which updates the user’s musical profile with the new songs. In the database, the user’s profile is recorded as a form of co-occurrence pair like {userID,itemID} pair. The pair means a user {userID} has played a\ song {itemID}. The dataset can be obtained at http://www.audioscrobbler.com/data/
  • AOL Web search query: http://www.gregsadetsky.com/aol-data/

Collaborative Filtering Bibliography

1. Pure Collaborative Filtering

Memory-based

Relevance Models

Latent Class Models

Matrix Factorization

Clustering

Transitive Associations

Trust Inference

Perception-based

  • Online ranking/collaborative filtering using the perception algorithm (2003).

2. Combining Content-based and Collaborative Filtering

3. Distributed Collaborative Filtering

4. Other issues


Related Information Retrieval Papers

In general, collaborative filtering is formulated as a self-contained problem, apart from classic approaches for text retrieval, e.g. RSJ models and language models. However, the collaborative filtering problem can be treated as a prediction problem – a prediction of the relevance between user and item (see user-item relevance models). Under this veiw, the instant benefits are gained from the current advances in these text retrieval models. We found the following papers are pretty interesting and are related to the collaborative filtering problem.


Related Machine Learning Papers

zz from:http://ict.ewi.tudelft.nl/~jun/CollaborativeFiltering.html

SCWS是一款简单的开源中文分词系统,其网址为:http://www.ftphp.com/scws/

在代码中添加了一些输出,以便探究其分词的算法:

[yicheng@chengyi cli]$ ./scws -c utf-8 -d dict.utf8.xdb -r rules.utf8.ini -D -i ‘中国人民在中国人民大学上大学’ -t 10
No. WordString               Attr  Weight(times)
————————————————-
[0,0]Ox11(中)
[0,1]Ox83(中国)
[0,2]Ox81(中国人)
[1,1]Ox31(国)
[1,2]Ox81(国人)
[2,2]Ox31(人)
[2,3]Ox81(人民)
[3,3]Ox21(民)
[4,4]Ox1(在)
[5,5]Ox11(中)
[5,6]Ox83(中国)
[5,7]Ox83(中国人)
[5,10]Ox81(中国人民大学)
[6,6]Ox31(国)
[6,7]Ox81(国人)
[7,7]Ox31(人)
[7,8]Ox83(人民)
[7,10]Ox81(人民大学)
[8,8]Ox21(民)
[9,9]Ox31(大)
[9,10]Ox81(大学)
[10,10]Ox21(学)
[11,11]Ox1(上)
[12,12]Ox11(大)
[12,13]Ox81(大学)
[13,13]Ox21(学)
PATH by keyword = 中国人, (weight=8.9964):
中国人 民
PATH by keyword = 中国, (weight=219.7764):
中国 人民
PATH by keyword = 国人, (weight=0.0218):
中 国人 民
PATH by keyword = 人民, (weight=219.7764):
中国 人民
01. 中国人民大学       nt    10.64(1)
02. 中国                   ns    6.26(1)
03. 人民                   n     4.41(1)
04. 大学                   n     4.23(1)
+–[lt-scws(scws-cli/1.1.2)]———-+
| TextLen:   42                  |
| Prepare:   0.0074    (sec)     |
| Segment:   0.0010    (sec)     |
+——————————–+

以下简单记录今天看代码的收获。

typedef struct

{

xdict_t d;

rule_t r;

unsigned char *mblen;

unsigned int mode;

unsigned char *txt;

int zis;

int len;

int off;

int wend;

scws_res_t res0;

scws_res_t res1;

word_t **wmap;

struct scws_zchar *zmap;

}       scws_st, *scws_t;

是很核心的结构体。其中,使用txt保存用户输入的待分词字符串,使用off记录当前待处理的字节位置,res0为返回的分词结果,wmap就是上面输出的二维数组,zmap为wmap中每个词在txt中的index位置,d是字典,r是rule。

1、在scws_get_result函数中,首先按照最简单的规则,对文字进行分段,比如字母、数字、标点、换行符等,都被当做token来分段。

2、 对于每一段,首先初始化wmap二维数组,在它的对角线上存储每个字。

3、 然后依次访问wmap的对角线,向后匹配,在字典中查找,若找到匹配结果,则存储在wmap的行里。比如

[0,0]Ox11(中)
[0,1]Ox83(中国)
[0,2]Ox81(中国人)

就是从对角线的第一个元素,依次匹配第二个、第三个元素的结果。

4、 根据rule,进行规则过滤

5、 对wmap中的元素遍历,根据tf、idf计算weight,找出weight最大的path,作为最优分词结果。

6、 清理内存,返回。

scws_get_result的返回结果是二维的。每一次返回的是当前段的处理结果,是一个链表。该结果的next,是下一段的处理结果。

所以需要

while (res = cur = scws_get_result(s))

{

while (cur != NULL)

{

printf(“Word: %.*s/%s (IDF = %4.2f)\n”,

cur->len, text+cur->off, cur->attr, cur->idf);

cur = cur->next;

}

scws_free_result(res);

printf(“\n———————\n”);

}

不习惯遮掩,不习惯欺骗,不习惯偷偷摸摸。

但是现在,这个恶俗的玩意,它不让我光明正大。而我明明没有错!

去死吧!!去死吧!!总有一天,一切的爱都可以光明正大!!

我遵守交通规则,因为违反,可能会有事故,有死伤。

我吃饭付账、拿薪水交税,因为有人需要这些。

我老老实实工作、认认真真学习,因为我需要有付出才有回报。

可是,为什么,这次,我没有伤害任何人,没有谁因为我断手断脚。为什么还要遮掩???还要像做错事情一样的怯懦、畏缩???

就做个了断吧!让一切都见到天日,爱怎样就怎样把!!

zz from :

http://firecacada.blog.163.com/blog/static/7074376201091331359910/

雷军7月开微博,讲了四个字“顺势而为”,字字珠玑,仰天长叹。

国庆前,与在淘宝社区工作的同行吃饭闲聊。我对淘宝怎样做论坛一直有点不解,向其打听版面如何分类,答,热门版面主要分三类。

第一类,店家交流经营之道;第二类,买家的交流与维权;第三类是行业版面,根据消费行业来分版,主要由店家发表消费生活攻略,为自己的店铺吸引人气,其中不乏精品。

我一听,一拍大腿,说这社区不火都难。每天几十万店家泡在淘宝上面,没生意上门的时候难免寂寞,很容易聚在一起聊聊怎样做好买卖。而买家吃了亏上了当,得找个发泄的地方,论坛投诉是一个急匆匆的去处。最好的内容则来自行业版面,利益驱动下,不愁没有店家发表好贴,提高整个社区的内容吸引力。按照这个版面定位,不需要多么高明的运营手段,多么庞大的人力投入,社区就能红红火火地拉起来。

他又问,那如果我们大搞“晒单”,你觉得行不行?

这回我有点犹豫。我猜啊,目前的定位下,核心用户主要是店家,而晒单依靠的是社群化的买家。淘宝的买家基本上不成群落,地域群搞不起来,消费主题群的运营投入和时间花费又太大,但离开社群关系就很难促成有质量的晒单行为。你们之前的做法是顺势而为,事半功倍;晒单的想法却是强攻山头,有很大的挑战。对于“拥抱变化”的阿里系来说,难以快速成就的持久战在政治上风险太大。

敏感话题就此中止,又谈起别的社区。他以前在视频网站做过社区,我问,容不容易做?答,容易个屁,根本做不起来。我哈哈大笑,说用户来看完视频就走了,有话直接在视频下面评论(其实评论也不多),又有多少感慨非得去论坛交流呢?大佬只看到社区的用户黏性与内容收益,却不管不顾自家的用户有没有社区交流的需要,霸王硬上弓。结局可想而知。

他冷笑一声说,对头!

我又说,如果视频网站一定要搞社区,只能从用户群落成熟,话题更新快的几类版面入手,如日剧、韩剧、美剧、热门动漫等等。但这和正版大环境冲突,没法大张旗鼓地推。不给推广资源,社区死得更快。

聊完回家一查Alexa,优酷看吧占全站流量仅0.2%,随便点开几个版都是僵尸贴居多;土豆亦如是。虽然运营上使的全是饮鸩止渴的低级手段(KPI驱动嘛),分版也主观生硬得很,但用户天然需求的缺乏才是致命伤——就算不用茅招吧,得有多强的团队,花多少时间使多大劲才能把视频网站的社区搞起来啊。

顺势和逆势,差距就有这么大。对大平台来说,自家的用户已经有了某些旺盛的需求,你去顺着它满足它,那是一马平川的畅快啊。反过来,人家压根没指望在你这里做这个做那个,你非要勾着他来玩,自然如高原行军半死不活。

我去年短暂地带过公司的论坛运营,刚接手两三个月,刚找到主编把论坛部门给建起来,策略与计划也定了下来,很快部门北迁,我的工作也有变更。最近跟同僚叙旧谈到此事,我说,即便当时我不调岗,也是注定会失败的。回顾那时的计划,一半是对的,另一半则是被环境压力扭曲了的,但手头上的资源太少时间太紧,如果不能集中精力做正确的事情,坏腿一定会拖死好腿。

这个道理说穿了很简单,在我接手前,论坛的用户群以中低端的草根网民为主(历史渊源就不讲了),什么版面最热呢?显而易见是社会话题、时政话题、情感话题这些,我们的主流用户喜欢聚集和讨论的版面。顺着这批用户的口味做,引导他们进行一些热闹又不太低级的讨论,会比较容易发展起来——但方向又不符合频道利益。

频道想要什么呢?当然是高品质的内容产出,高水准的作者,巴不得把现有的论坛用户赶跑,换一批专业又高端的新血进来。然而社区大换血在互联网上几乎没有过成功先例。劣币会驱逐良币,低端用户会驱逐高端用户,引入新用户群的难度远高于重新做一个崭新的社区。

在当时的政治环境下,我必须服务于频道需求,而论坛部门初建,人才匮乏,根本不可能两线作战(服务现有用户与服务频道需求),何况后者还是一场必败的战争。最终要不是我被频道需求拖死,要不就是我被频道弹劾下野。

我离开后做得比较好的版面,据说还有一个“理财”。按说我们的用户群讨论不起来理财这么专业的话题啊,对头!火爆的话题是晒工资单,晒低消费,岂不口味相投,轻轻一推就能热火朝天。

在管理论坛运营之前,奥运会期间,那时我还在带产品部,曾经主持过一个短命的项目“易吧”。你们谁都没听说过吧,没听过就对了,还没正式推出就夭折了。它在论坛代码的基础上开发,奥运会期间做了一期试验,效果不行,项目给撤了。

易吧的发起,是基于我对新闻跟帖用户的需求判断,我认为对于持续性报道的热门新闻(比如方舟子遇袭),用户有持续性讨论的需求,但现有环境只允许他们以新闻跟帖的形式进行碎片化交流,不深入,不连贯,因此想针对少数热门新闻,紧密结合新闻页与频道页,设置若干个“主题新闻贴吧”进行引导。借着奥运题材,恰好能搞到一点开发资源,策划加开发花了一个多月,试验成功则全频道推广。

这个初始动机,直到现在我仍认为是有价值的,但验证下来效果不行,以后也没机会再提这茬。失败的原因有二:

1、我对试验环境的判断有误,奥运会他妈的就没什么话题性,一面倒的啦啦队,缺乏话题炒作必须的负面情绪与争议。当时只有男足那个吧火了几天(骂了几天),别的吧是一面倒的加油喝彩,根本讨论不起来,全无内容价值。

2、奥运事大,不敢冒险,因此采用了奥运论坛与易吧并行的方式。有限的推广和运营资源被分流,分给试验产品的肯定是最差的资源——有惊喜固然好,砸了也不心痛。缺乏稳定有效的推广位和强有力的运营,更缺乏上线后的快速调整优化,贴吧印象只是简单的跟帖论坛版,全无品牌识别性,当然达不到原本“持续性讨论引导”的目标,反而被强势跟帖挤压。

回想起来,当时选择奥运期间试验是我最大的失误。错误的时机导致项目过早夭折。但如果不趁此题材之利,恐怕更没机会进行试验。我讲自己这两段社区经历是想说明,仅仅有用户需求并不代表你就能“借势”,你的市场时机、资源背景、管理考核、团队实力,统统都是决定成与败的“势”。顺则昌,逆则亡。

所以我在三个月前看到雷军“顺势而为”这四个字时,悲从心来。进公司做了四年总监,距离自己的职业理想还很远。想找个成功的内部榜样学习一下吧,这四年来除了博客之外,我也没发现公司哪个项目能算得上“成功”。博客为什么能搞上去?除了当年颇有产品特色之外,更重要的是赶上了06-08年全民开博的高峰。那年头最时髦的事情就是开博客,群情汹涌,再加上老板全力推动,借助公司的品牌与流量,不错的产品自然能蒸蒸日上。日子往后,博客泛媒体化的发展导致新浪一家独大,而空间化的分支路径又被社交网站狙击,步子渐行渐慢。

唉,人常嘲笑丁老板保守,但换个角度看,这种保守其实是在谨慎地判断市场风向。一旦找到大势所趋,适合门户投入,又能建立竞争壁垒的项目,也会不惜一切地投入。他的风格未必是对的,也未必错。只是规避风险的个人风格罢了。别说我们公司这四年来大大小小的项目成功率不足1%,其他门户难道就能超过2%?市场上每年发起的新项目没1000也有500,每年的成功者可有五指之数?

过去几个月,我常说,项目成功需要天时地利人和。天时是用户需求与市场时机,地利是公司提供的资源背景与管理支持,人和是每一个核心岗位上都有尽职又得力的人。三者俱备,事已半成。

最近,我又把这道理换了个说法,叫做“成功需要资源与模式的完美结合”。资源包括推广、团队、以及其他一些独到的背景优势;模式则指的是产品架构、运营策略与管理体系。顺势而为也可以理解为“顺着自己的优势去建立经营模式”,根据对市场情况的了解,基于“背景资源最大化”去建立经营模式,就算没有大成功,至少也不会太失败。

举两个例子。

04年底,我在福州受人之托创业,拉了笔风险投资开小公司搞合法外挂“简单游”,用按键精灵的技术(因而合法)。一开始有个竞争对手叫“EZQ”,台湾人创办,我和他起初都采用推广开发平台、招募脚本作者的众包模式,但很快发现征集到的脚本质量太差。这时我比他先转身,赶紧地招了一批程序员进来,自己写脚本,最高时做到每天7位数的使用人次,每个月7位数的下载量;而EZQ的动作太僵硬,死守这个“理论完美”的众包模式,垮了,和蒋委员长一起退守宝岛。

直到06年,公司经营遇到了瓶颈,我觉得距离职业愿景太远,辞掉总经理的职务加入门户。没想到这个瓶颈被继任的陈总(^_^)给突破了。当时简单游已经有了些名气与流量,不像起家那时一穷二白,既然资源环境今非昔比,他重新启动了拖垮EZQ的众包模式,征集作者撰写脚本,平台提供销售分成,经营又上一个台阶。正所谓南橘北枳是也。

再说说美空,算是2008年的一个产品亮点。有人问我为什么不带着相册走美空模式?我叹口气,你知道美空的老板马月吗?曾经做过两年男模,据说还拿过奖,后来转型网站设计,常为名模设计个人网站。人脉资源的优势使美空能顺利连接模特与经纪公司,快速实现良性循环;设计背景又带来独树一帜的潮视觉风格,简洁艳丽的产品与美女艳照完美融合。如果我跟着玩美空模式(先不管政审风险),我去哪里找模特,去哪里找经济公司,去哪里找擅长这种潮风格的视觉设计师?三者缺其一,这模式就玩不转,『同时凑齐』这三者又谈何容易。

其实,图片交易业务也是同样的道理。经常有人劝我去搞原创相片的交易平台,我反问道,谁是买家,谁是卖家?他们也讲不出来,只反复讲,市场很大,市场很大呀。好吧,我不去争论这个市场够不够大,但公司资源并不能帮助我快速拉拢足够多的买家(销售品牌趋近于零),我也不认为现有用户群覆盖了足够多高水准的卖家(目标用户极其分散),既然全无背景优势,为什么我要凭空做这个事情?仅仅是因为“市场很大”还是我“雄心万丈”?又或者在你们的幻想中,门户无所不能所向披靡……安啦,洗洗睡啦。

对照全球最大的摄影产品Flickr,人也没自己搞图片交易,而是外包给了全球最大的创意图片销售商Getty Images。术业有专攻嘛。对于先有鸡还是先有蛋的老问题,成功哲学往往是这么回答:最好你又有鸡又有蛋,然后再去孵化更多的鸡蛋……

或者换一种大家比较能接受的说法:最好在你已有的资源优势基础上去建立产品模式,而不要总想着靠聪明才智去空手套白狼。

惨,一寸经验一寸血。拿我带了多年的摄影项目来说吧。第一年整个策划开发运营团队仅2人,第二年加到了6人,但程序员只得2枚,任何想法都进展缓慢。直到三年半——没错,是三年半之后,开发人力基本解决了,这时也与相册合并了,看起来形势大好……错!因为解决了一些积压的老问题,才发现真正的问题在哪里。摄影社区更适合空间模式,而不是我采用的展区模式,换句话说,我这么长时间所做的事情都是不符合市场需求的,至少不符合现阶段市场需求。虽然也是出于开发资源紧缺的“情非得已”,但动机如何丝毫不影响结果优劣。

与此同时,独立相册的用户与摄影社区用户的重合度很低,品牌联动亦弱,数据已经验证过了,不争了。以相册为基础来运营摄影分享业务,即便不算错,也占不到多少地利之便,如果非得找一个更适合的结合体,那其实是博客。

与博客的合作正在进行中,不便多讲。也许走到这一步,才算是真正接近了“势”,但也还有明知而无力的欠缺。回顾过去,需求判断/团队配置/用户基础/推广效率皆不到位,既然资源优势极小而阻力又大,起初就不该逆行干这票买卖。靠的完全是蛮劲——美其名曰为“意志坚强”,其实就是盲目的死撑。

其实很多事情在一开始已经注定了,只是你自己不知道而已,顺势还是逆势,一开始就决定了项目的曲线。用户的定位是否正确?需求分析是否准确?进入时机是否恰当?资源支持是否充分?产品模式是否能与资源特点完善结合?管理体系是否带来合力而不是阻力?团队核心成员是否齐备又给力?人力部门和人脉关系是否能满足项目扩张的要求?如此等等。基因的优秀与劣等,项目启动个把月后已见分晓。

很多时候你着急做点事情出来,骗自己,哄自己,说这些难题都是可以克服的,推广力度是可以增加的/团队是可以成长的/人才是可以招到的/公共部门是可以依赖的/就连用户习惯都是可以被教育的,然后霸王硬上弓。还有更多的时候,你连顺势还是逆势都看不出来,天真又欢乐地霸王硬上弓。为什么这个行业的项目成功率不到1%?就是因为霸王硬上弓的人太多,而懂得(或机缘巧合)顺势而为的人太少。讲什么“顺着自己的优势去建立经营模式”,压根就是顺着自己的一厢情愿去建立经营模式。

话说到这里,惆怅万分。有时候我们不懂顺势的道理,有时候却根本无势可顺。这二者之间的区别在于,不同的职业目标需要借助不同的“势”。仅仅想升职加薪年入六位数?那容易,在哪里都不难做到。想做点什么了不起的事情?嘿,天底下哪里来这么多了不起的事情,大部分环境的优势未必多,短板未必少……倒是野心难以抑制,贪功冒进,逆水行舟的人如过江之鲫。事前未尝不知道此路崎岖,只是大道难觅,又见不得自己庸庸碌碌。

最近半年不停有人问我,大爷能搞到钱,但这个市场上到底有什么机会值得干一票,这个意思也就是问市场的大势在哪里。答:泛媒体化的微博是大势,但你我都没机会。从有得玩的大方向来讲,一是本地化电子商务,二是垂直电子商务,三是移动互联网。比如今年热门的团购网站,就暗合了“本地化电子商务”的大潮。以前干这事儿非得本地社区不可,现在节约了从呱呱落地到领证结婚的漫长的几十年过程,直接允许你合法做爱。怎可能不勇猛精进。

但是电子商务这种东西,关键是商务这一端,是对线下资源的控制,对销售市场的理解。所以你如果没相关资源,徒具头脑与野心,还是别乱碰的比较好。至于移动互联网嘛,我的信心来自Android低端手机在未来几年的普及,对这块感兴趣但不太懂,不乱点评也罢。

此乃大势。

具体到经手的每一个项目,值不值得做,好做不好做,该怎么做,如何判断“势”在何处呢?饱经沧桑的郭校长可以告诉你一个真理:掌握充足的信息是唯一靠谱的思维方式。大到了解市场与用户,小到了解你自己的用户群与团队特点,了解越多,瞎搞越少。

比如百度的孙云丰(Google事件中一战成名的那位),前日写了篇日志讲,他对人对项目的判断标准基本上是四个问题:“这个产品要提供给用户的核心价值是什么?其次的问题是:要达到这个目的,需要解决哪些关键的问题?接下来的问题是:别人是如何解决这些问题的?最后的问题是:你打算如何解决这些问题?”

这四个问题,天底下能回答好的人很少。这很正常,成功者本来就少,又不是养殖场的鸡,看几本讲成功学的书就可以量产。我所见太多人一脑子雾水,兴冲冲跑去上某个项目,如同昔日的自己。等到在挫折中成长起来,知道什么事做得什么做不得,反而更觉惶恐,因为做得的事情太少,做不得的太多。自己能改变的事情太少,不得不忍耐的太多。坐而论势,腹中枯槁。

使用破解版,盗版软件是不好的习惯,我检讨。但是下面,我还是要告诉大家,我是怎样使用破解版的IPAD的。

首先,名称解释,破解 = 越狱,完成之后就可以免费下载和安装IPAD的应用软件了。

破解第一步,打开IPAD,点击iPad Safari的地址栏并在其中输入http://jailbreakme.com,然后点击完成按钮。这时safari浏览器会打开越狱页面(这个页面利用了flash的漏洞,进行破解),根据提示,滑动以确定破解!(如果只是想看看这个页面,只要不滑动就没关系,不会有任何影响)

然后,安装cydia和installous,这两个都是可以下载并安装软件的工具。我现在用的比较多的是installous,在其中加上威锋网源,这样有很多资源可以用了。

还需要安装BossPrefs,它可以查看IPAD的IP地址、管理连接。

IFile:允许你管理IPAD上的任意文件、目录。

goodreader,看文档超级棒,pdf、doc、txt、video、audio,统统都可以。

Numbers:类似excel。

pages:类似office。

Terminal:这个是iphone版的,目前还没有ipad版,可以进行命令行,对于linux控挺好,但是ipad的键盘输入。。。不说了