Month: March 2011

android 如何保存簡單的配置信息(SharedPreferences、File和Properties)

我們知道在android的開發中，保存項目私有數據的存儲方式我們可以使用：SharedPreferences,File,SQLite,Network.四種方式，而要用到應 用程序之間數據的共享要使用ContentProvider 。那今天我們只敘述一下僅僅保存一些我們登錄等的一些配置信息的數據，也就是說用到的數 據量都不是很大，那麼我們就可以選擇SharedPreferences和File的方式。這裡只針對性的結合File和Properties進行敘述。 一。SharedPreferences 1. 它可以保存上一次用戶所做的修改或者自定義參數的設定，當再次啟動程序後依然可以保持原有的設置。這裡只說明一下使用方式。比如下 面的代碼在OnCreate中使用： SharedPreferences mSharedPreferences = getSharedPreferences(“list”,MODE_PRIVATE); String mTempString = mSharedPreferences.getString(“config”,”default”); 其中”list”是SharedPreferences的文件的名字，SharedPreferences是以鍵值映射的關係存放數據。不過多解釋，你也可以這樣用： SharedPreferences mSharedPreferences = getPreferences(MODE_PRIVATE); 這樣默認的文件名是activity的名字。 2. 退出activity的時候保存數據，在OnPause中使用： SharedPreferences mSharedPreferences = getSharedPreferences(“list”,    MODE_PRIVATE); mSharedPreferences.edit().putString(“config”,”data” ).commit(); 3. SharedPreferences 是以xml文件的方式自動保存的，在DDMS中的FileExplorer中展開/data/data/包名/shared-prefs下面就是SharedPreferences文件。 4. SharedPreferences文件只可以用來存放基本的數據類型。 二。結合File和Properties進行保存。 A Properties object is a Hashtable where the keys and values must be Strings. Each property can […]

开发 Eclipse 插件

简介： 在本文中，David Gallardo 向您展示了如何使用 Plug-in Development Environment 的代码生成向导来创建 Eclipse 插件。您将学到如何在运行时工作台中运行和调试插件，并且在 Eclipse 中安装完成的插件。David 还研究了与打包插件相关的问题 ― 包括维护版本信息、以插件片段的形式更新功能，以及组合插件来创建完整的功能部件。   基于插件的体系结构 Eclipse 平台是 IBM 向开发源码社区捐赠的开发框架，它之所以出名并不是因为 IBM 宣称投入开发的资金总数 ― 4 千万美元 ― 而是因为如此巨大的投入所带来的成果：一个成熟的、精心设计的以及可扩展的体系结构。Eclipse 的价值是它为创建可扩展的集成开发环境提供了一个开放源码平台。这个平台允许任何人构建与环境和其它工具无缝集成的工具。 工具与 Eclipse 无缝集成的关键是插件。除了小型的运行时内核之外，Eclipse 中的所有东西都是插件。从这个角度来讲，所有功能部件都是以同等的方式创建的。从这个角度来讲，所有功能部件都是以同等的方式创建的。 但是，某些插件比其它插件更重要些。Workbench 和 Workspace 是 Eclipse 平台的两个必备的插件 ― 它们提供了大多数插件使用的扩展点，如图 1 所示。插件需要扩展点才可以插入，这样它才能运行。 图 1. Eclipse Workbench 和 Workspace：必备的插件支持 Workbench 组件包含了一些扩展点，例如，允许您的插件扩展 Eclipse 用户界面，使这些用户界面带有菜单选择和工具栏按钮；请求不同类型事件的通知；以及创建新视图。Workspace 组件包含了可以让您与资源（包括项目和文件）交互的扩展点。 当然，其它插件可以扩展的 […]

说说Stack Overflow和Quora

今天看到一个新闻，Quora的中国克隆“知乎”得到了创新工场的投资。我之前从创新工场的投资经理张亮那里要到了一个知乎邀请码，最近一直泡知乎，觉得Quora类的产品有很多创新的亮点，所以比较感兴趣这类产品，忍不住就谈谈。 Stack Overflow(以下简称SO)和Quora虽然都是知识问答类的网站，但是他们有共同的成功基因，也有本质的差别。 先说SO和Quora共同成功基因，那就是：用户身份的真实性和唯一性。 我看过不少关于SO和Quora如何成功的很多讨论，各种说法都有：如说SO的SEO很好，SO的积分激励机制如何如何，Quora的种子用户运营如何如何等等。其实这些原因都对，但不是最根本的原因。真正根本的原因在于：用户身份的真实性和唯一性。 我们国内做社区网站，特别是知识型社区网站，核心的竞争力就是高质量的内容。如何获取高质量内容的手段自然多种多样，但是当社区成长起来以后，特 别是用户量急剧膨胀以后，很难避免社区的水化，大量低水平用户，特别是不负责任的用户随意的发帖、发言和评论，会破坏整个社区的内容质量，造成劣币驱逐良 币的现象，最终毁掉这个社区。 这个现象是社区特别是BBS型社区的发展宿命，JavaEye也面临这个问题，早先几年采取的运营手段可以称之为“堵”，惩罚低水平用户的发帖， 恐吓不负责任的行为。但是随着社区规模不断的扩大，注册用户数量越来越多(已经超过70万注册用户，每天UV有25万以上)，堵的手段成本越来越高，有效 性越来越低，因此必须改变运营方式。我想到的一个办法就是BBS产品创新，而且是大胆的产品创新。不过这个话题不是本文的主题，我以后会另外撰文。总之这 是一个社区需要解决的大问题。 而SO和Quora很巧妙的解决了这个问题，办法就是：不提供网站账号注册功能，必须通过你在互联网的得到公认的唯一身份标识来登录网站，例如必 须使用你的Google帐户，Facebook帐户，或者Twitter帐户登录。这样的做法就保证了用户使用真实的身份，而且身份是唯一的。 真实而且唯一的身份保证了你必须对自己的发言负责任，保证了你不可能养很多马甲，保证了你必须深思熟虑的行为，确保你自己的网络身份和信誉。特别 是通过Facebook帐户登录以后，可以连带你的好友关系一起导入进来，让你在这个网站的种种行为在你的众多好友的注视之下，更加不可能胡作非为，而且 有了好友关系以后，天然的可以增加网站的用户关系和黏性。 很多人可能以为外国人就是网络素质高，不会像中国人那样网络随地大小便。其实不然，我去过很多国外的小论坛，用phpbb搭建的BBS里面，包括 TSS，照样是Help! Urgent！满天飞，和国内的论坛标题党绝对有的一比。但是一旦用你的真实和唯一身份登录，老外也马上规规矩矩起来，特别是Facebook，外国很多 人就是拿Facebook当作个人的网络通讯录来用的，这个东西有点像国内的MSN。你敢在你的MSN上面对着好友说那些很不着调的话吗？ 所以那些SO和Quora上面的人确实就不会乱来。这就是真实而且唯一身份带来的威力。 不过可惜的是，明知这一点，但国内的网站是绝对抄不到手的，因为国内没有一个具有像Facebook这种占据统治地位的真实身份和用户关系，并且 彻底开放的SNS好友关系平台的存在。这也是国内互联网行业的悲哀之处，国外的互联网基础设施实在太好了，AWS，PAAS，连SNS平台的海量用户都现 成，你只要有想法，会写代码，一堆基础设施拿来就用，三两下，一个创新型应用平地而起，这也是为什么硅谷创业公司这么流行Ruby on rails的原因(呀，跑题了)。 总之，你没有这种海量的真实唯一用户导入，就算你的运营水平和产品做很好，也长不成SO和Quora。说到这里，Facebook现在真的成长为 下一代互联网应用的基础设施了，以后做网站真没有必要搞自己的帐户系统了，直接Facebook账号登录搞定，所以Facebook估值到800亿美刀不 算夸张，什么叫基础设施啊朋友，baidu这种烂货都400亿刀了。（又跑题了） 所以，我并不太看好知乎这个产品的前景，目前严格的邀请准入制迟早要改变的，到时候用什么手段来解决这个问题呢？ 我认为根本无解，或者说如果有解的话，产品形态必须做出重大的改变，那样的话，从一开始就不应该照着Quora的样子去长。 然后说说SO和Quora的差异在于：知识的组织方式：以内容组织结构为基础，还是以用户关系为基础 其实SO和Quora的差异还是很大的，从目前Google Adplanner来看，SO的UV和PV大致是Quora的5倍，考虑到SO只是一个纯技术网站，这个差距不可谓不小。但是这个不重要，重要的你怎么理解“知识”的组织方式： SO是一个标准的内容型社区，不需要登录就可以访问，用tag和search良好的组织整个网站的知识体系，在这个基础上添加用户关系和用户身 份。而Quora是一个标准的Social型的社区，不登录对不起，什么都看不到，登录以后你没有用户关系，还是对不起，什么都看不到，你获取信息要依赖 于你的用户关系之上，用户关系决定了你获取信息的效率。 我们说问答这种知识沉淀的方式包含了两种需求： 沉淀知识需求和快需求： 什么是快需求？ 我就是来找答案的，别TMD的让我自己搜索半天，然后自己摸索，我就是等着你喂我，我不想费任何力气自己去找答案。其实绝大多数中国的论坛充斥的都是这种 快需求的帖子，而满足这种快需求最好的产品形态就是百度知道，没有唯二的了。我不知道如何形容我对百度知道的仰慕之情，以致于我抄袭了百度知道，做了一个 JavaEye问答频道，而且强迫性的不允许JavaEye用户在论坛发提问贴，必须给我到问答频道提问，而且我还老搞问答大赛，刺激答题者的热情，重点 不在于问题是否重复的问，而在于你答题是否及时有效，这就是旗帜鲜明的满足快需求而去的。 SO也好，Quora也罢，可以满足一部分的快需求，但是从产品形态来说，他们主要不是为了满足快需求而量身打造的产品。快需求有一个很大的特 点，就是并不需要回答的内容是高质量的，反而对实效性要求可能稍微高一些，因此这种产品真的不需要特别的追求回答的质量多高，只要能够快速满足提问者的需 求就OK了。 那么沉淀型需求呢？ 沉淀型需求做的最好的产品其实是wikipedia，基本上你可以找到大多数各个领域的知识。当然wikipedia不能覆盖所有的知识领域，一些知识需 要通过问答的形态来组织，因此SO也做的不错。沉淀型需求对内容的质量有要求，越是高质量的内容，越能够加强社区的竞争力和黏性。所以你会看到不管是 SO，Quora还是很多知识型社区的一个基本诉求就是：内容的质量。 这里，我们要更加深入的思考一个问题： 什么叫做高质量的内容？ 你如何评判一个内容的质量高低与否？ […]

命令行查看Memcached运行状态

很多时候需要监控服务器上的Memcached运行情况，比如缓存的查询次数，命中率之类的。但找到的那个memcached-tool是linux下用perl写的，我也没试过windows能不能用。后来发现个简单的办法可以做到，就是使用Telnet。 首先登录到服务器，然后在cmd命令行中键入 telnet 127.0.0.1 11211 其中127.0.0.1是服务器的地址（这里是本机） ，11211是memcached绑定的端口号。 之后命令行窗口全黑只有光标提示，摸黑输入stats，即可得到描述Memcached服务器运行情况的参数。如下图： 其中，uptime 是memcached运行的秒数，cmd_get是查询缓存的次数。这两个数据相除一下就能得到平均每秒请求缓存的次数——最近niupu的流量很低，所以平均也就一秒请求一次多，这么点大的压力，用文件系统缓存一样没问题，根本不会体现出使用memcached的优越。 下面的cmd_set 就是设置key=>value的次数。整个memcached是个大hash，用cmd_get没有找到的内容，就会调用一下cmd_set写进缓存里。紧跟着是get_hits，就是缓存命中的次数。缓存命中率 = get_hits/cmd_get * 100%。 下面的get_misses的数字加上get_hits应该等于cmd_get。而total_itemscurr_items表示现在在缓存中的键值对个数，在图上total_items == cmd_set == get_misses，不过当可用最大内存用光时，memcached就会删掉一些内容，上面的等式就不成立了。  

MongoDB 1.8通过Journaling日志改善可靠性​

面向文档的数据库引擎MongoDB在3月16日发布了1.8版本。关键的变更包括新增Journaling日志、提升分片性能以及Shell的Tab​补全。​ Journaling日志通过预写式的Redo日志为MongoDB增加了额外的可靠性。开启该功能时，变更会先写入Journaling日志，​ 定期集中提交（目前是每100ms提交一次）​，然后在真实数据上进行这些变更。如果服务器安全关闭，日志会被清除。在服务器启动时，如果存在 Journaling日志​，则会进行回放。这保证了那些已写入，但在服务器崩溃前还没有回放的​日志能在用户连接前​被执行。​两次提交之间那 100ms的时间窗口​在未来的版本中有望被缩小。 MongoDB是​一种 NoSQL数据库​，不同于SQL Server这样的关系型数据库，MongoDB中数据的基本单位是文档。类似于JavaScript对象，文档中包含一系列带有类型的键值对​，这些类型可以是字符串、对象、数组、正则表达式和代码。​这些文档以​BSON格式存 储​，根据文档类型被分组到集合（类似于SQL Server里的表）中​。Schema的设计取决于哪些文档应该有自己的集合​，哪些应该被嵌入到其他集合中去。嵌入的文档就像类里的成员对象。在关系 型系统中，你会用一张表来存储订单，另一张外键的表来存储订单项。在MongoDB中，​针对同样的场景，推荐的做法是用一个集合来保存订单，每个订单中 保存一个订单项的数组，嵌入其中。​ 水平扩展是通过​自动分片来 ​做的​，​它允许有序的集合数据分布。每个分片都是一组配置成Replica集的机器​，这意味着分片里的每台机器​都拥有分片数据的完整拷贝。​分片 中会自动进行故障转移。MongoDB会自动将查询引导到合适的分片上，因此应用程序并不需要了解哪个分片持有什么数据元素。​新的Replica集身份 认证功能允许Replica集的成员之间进行自动身份认证，其中使用了密钥文件和 –keyfile 选项。​ Covered索引和Sparse索引也是该版本中新增加的特性。​Covered索引允许​在索引本身里存储数据，而​Sparse索引则会排除掉不包含索引字段的文档。Covered索引在查询所请求的全部字段​都包含在Covered索引中时能提升性能，因为不再需要取出完整的文档记录。Sparse索引在所检索的字段并非经常出现在集合中时能提升性能。目前，Sparse索引只能有一个字段。​ 在MongoDB的工具集中也有一些变化。mongostat 增加了​discover模式（–discover）​，它会自动从集群的节点中取回统计信息。​通过mongodump –oplog 和mongorestore –oplogReplay提供了高级事务日志转储和恢复​功能。​ 欲更多地了解该版本中的新特性，请查看MongoDB 1.8 Webinar。 查看英文原文：MongoDB 1.8 Improves Reliability with Journaling  

舊街市模型

在山頂廣場，見一唐樓展覽，有一些街市模型，做得很精緻。  

JQuery 1.5.2 RC 1 发布

JQuery 1.5.2 RC 1 发布！如果没有重大缺陷发生，3月31日就将发布jQuery 1.5.2正式版了。 该版本主要是bug的修复，没有新功能发布。 详细更新日志：http://blog.jquery.com/2011/03/24/jquery-1-5-2-rc-1-released/ 下载地址：http://code.jquery.com/jquery-1.5.2rc1.js

Ruby on Rails with Nginx on CentOS 5

Ruby on Rails is a popular rapid development web framework that allows web designers and developers to implement fully featured dynamic web applications using the Ruby programming language. This guide describes the required process for deploying Ruby on Rails with Passenger and the nginx web server on CentOS 5.   These instructions work with the […]