这一年的工作

阅米从开始到现在做了半年了。加上之前产品的摸索阶段，来每讯有一年了。从开始学习模仿Flipboard和zite，到慢慢形成自己的特点。邀请码内测了很久, 不断的完善，用户较少，心里没有底。 现在在Q+平台上, 终于用户开始有较快的增长，活跃度也还不错，不禁有一些欣慰。当然产品还有很多需要完善的地方，推荐算法也要进一步改进。还有手机和ipad客户端，希望尽快的能够上线使用。这一年收获很多，研究了不少东西

热文发现：

• 从微博，RSS中发现热门的内容
• 按照热度排序.
• 按照时间衰减。

自然语言处理：

• 网页正文提取, 过滤广告、导航等内容，只保留文章主体。
• 文章标题提取, 自动去掉标题中含有的网站名称、标语等噪音。
• 制作缩略图,制作不同的缩略图，适用不同的版式和终端展示。
• 文本去重，内容相同或者相近的文章识别并只保留一篇。
• 文本分类，自动将内容划分到合适的分类。
• 来源提取，友好的文章来源展示。
• 关键词提取，分词并自动提取适用于展示给用户的关键词。

社会化：

• 接入腾讯微博、新浪微博
• Q+、人人等开放平台
• 社会化分享

个性化算法：

• 用户喜好模型的建立, 用户的主动、被动行为分析。
• 用户模型的快速生成和更新，用于冷启动。
• 新闻按照用户个人喜好等排序.
• 微博过滤，按照时间、热门度、用户关系、用户兴趣排序
• 即时计算用户喜欢的文章列表。
• 各种个性化因子的权重优化、评价。
• LDA话题模型。
• 计算用户间的亲密度
• 杂志化自动排版技术。

跨平台：

• 普通的Web版本, Q+版。
• 手机web版
• 未能完成的HTML5版本
• 即将推出的Andoroid、IPhone手机版本
• 即将推出的IPad客户端

语言层面：

• 在php, javascript之外，也写了一些Java，C++, Python 的代码。
• 此外还研究了HTML5, NodeJs, Objective C等等。

Tags: 个性化阅读, 全网热文发现, 阅米, 推荐算法, 文本挖掘

构建我们的离线Web应用

公司希望为我们的Web站点，开发一个html5版本，拓展到Pad端，给使用高级浏览器的用户一个更加完善的用户体验。其中一个重要的功能就是支持离线应用。

利用html5构建一个离线应用，主要依赖于三个新的特性

1. 离线资源缓存：

可以在一个manifest文件中指明离线应用工作所需的资源文件。缓存的文件可以在manifest文件本身发生变化的时候更新，或者检测window.applicationCache.status，然后调用window.applicationCache.update()更新缓存。

2. 在线状态检测：

html5支持通过navigator.onLine获取当前的在线状态。html5还提供在线和离线事件机制.针对在线状态，我们可以做出不同的处理

3. 本地数据存储：

html5提供了LocalStorage和WebDatabase(WebSQL/indexedDB)两种存储机制。前者提供key/value存储方式，后者提供关系数据库存储功能。

离线资源缓存

要使用离线缓存功能，需要在编写manifest文件，并指定使用的manifest.

manifest文件格式.

• 首行必须是 CACHE MANIFEST。其后，每一行列出一个需要缓存的资源文件名。
• 可根据需要列出在线访问的白名单。白名单中的所有资源不会被缓存，在使用时将直接在线访问。声明白名单使用 NETWORK：标识符。
• 如果在白名单后还要补充需要缓存的资源，可以使用 CACHE：标识符。
• 如果要声明某 URI 不能访问时的替补 URI，可以使用 FALLBACK：标识符。其后的每一行包含两个 URI，当第一个 URI 不可访问时，浏览器将尝试使用第二个 URI。
• 注释要另起一行，以 # 号开头。

文件示例

在线状态检测

上面提到过，目前html5提供了两种检测是否在线的方式

检测 navigator.onLine

侦听document的online和offline事件

本地数据存储

通常我们用cookie来存储数据，但是cookie存储的数据量太小.而且每次发起http请求都要带上，增加了数据的传输量.html5新引入了两种key/value存储方式，提供比较大规模，性能更高安全性更好的存储方式。 localStorage 和 sessionStorage
sessionStorage只在本次浏览器会话中保存，浏览器关闭之后存储就被丢弃。localStoage则可以比较长期的保存。但是使用方式都一样，非常简单.
直接

另一种方式是关系数据库存储，不过虽然chrome提供了websql特性。但是貌似html5工作组停止了这个标准的制定工作，转而支持另一种indexedDb的标准。但是indexedDB目前还没有浏览器实现。我的理解，前者基于Sqlite的Sql来操作数据，后者可能更像是ORM的方式,数据操作更加优雅更加对象化。所以可能暂时这个功能得不到大范围使用。

问题

利用离线资源缓存，我们就可以能够访问读到应用了。然后利用状态检测和数据存储功能，我们就可以在离线的时候，将用户的操作保存起来，等到在线的时候，再将它们发布到服务器上。做了一些demo后发现，已经能实现一些简单的应用了, 还有一些问题需要解决，包括。

1. manifest文件不支持通配符，因此我们的一些通过动态生成的文件，比如合并压缩的js和css文件，不太好缓存。以及很多根据ID通过ajax生成的数据也不容易缓存。
2. 一些离线状态下的操作，比如发表的评论和执行的转发操作。即时能够通过在线的时候同步，但是也可能面对失去了时效性之类的问题。而且下次再次离线上来的时候，还没能够同步到服务器的这些离线操作内容不容易呈现出来。
3. 如何在线上的内容更新的时候，通知客户端更新缓存。动态生成manifest文件，可能导致所有的内容都更新。
4. httpCache和offlineCache的内容无法共享，导致的客户端存储空间浪费。

Tags: 离线应用, html5, webapp, 本地存储

SCRUM方式项目开发

看到同事写的一片博客，项目开发中的小纸条，想想在他的带动下，这一年也试验了很多敏捷开发的方式。包括一开始使用的燃尽图，封闭开发期间推行的单元测试，现在使用的任务小纸条。应该说效果还是非常明显的，虽然不是在所有的项目中都采用了，但是在我们团队多人配合的周期在三周以上的大点的项目中，基本都是采用了。

使用燃尽图的时候，产品的理想开发周期应该在三周左右。我们一开始将任务拆分出来，粒度在半天左右的。列出开发计划，每一天完成多少个功能点。需求不明确的，要尽快跟产品人员沟通确认。在白纸上或者白板上，以功能点个数为纵轴，开发工作日为横轴的坐标上，标出每天的剩余的未完成功能点数，连成曲线。然后每天标出实际的剩余功能点数，汇出另外一条曲线。如果发现实际曲线高于计划曲线，说明项目进度慢于预期，那么项目将可能面临延期的风险。如果实际曲线低于计划曲线，并且差距越来越大，说明项目可能能够提前完成。理想的情况应该是两条曲线基本吻合，否则要么是我们的估计出现了偏差，要么是项目中出现了意外情况。根据曲线的偏离情况，可能需要及时的做出调整，保证项目的正常完成。项目中团队每天下班前需要碰一下，报告完成的功能点数。
根据项目的情况，我们可以在几个关键的功能点上标明项目的里程碑，重点关注几个里程碑的开发进度。相对完整的功能块及时提交给测试人员。使得他们能够提前介入测试，缩短项目周期。
任务条的部分我们是上一个项目开始使用的，详细情况参见同事的文章。

燃尽图和小纸条都属与scrum开发方式的组成部分。它要求我们一开始就将任务能够拆分的足够细致。开发过程中发现曲线偏离过大的，及时的做出风险提示，并尽快找到原因，作出修正。每天团队有短暂的会议来相互沟通，跟踪进度。测试能够尽快进入。实现产品需求的快速迭代。

这些技术应该說还是不难使用的，最关键的地方还是一开始的功能拆分，需要完全理解产品的需求，不明确的尽快沟通。任务需要拆分的足够细致，并分配到具体的人，才能做好开发的时间评估。这个工作要一整天甚至更多的时间。之后需要每天通过短暂的会议沟通，坚持绘制曲线和移动小纸条。需要注意的是任务的完成需要以能够提交给QA测试为标准，而不是差不多完成了。說差不多完成了的时候，往往还需要一半的时间来做到真正的完成。

至于单元测试的东西，改天我再写一写当初我们的经历。
最后感兴趣的朋友我推荐一本书
硝烟中的Scrum和xp 网上可以免费下载。

Tags: 任务条, 燃尽图, scrum, xp, 敏捷开发