构建我们的离线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, 敏捷开发

别做正常的傻瓜

最近跟同事们吃饭的时候，经常问他们一些有意思的问题,当然得到的答案有时候也很有意思。
这里列一些问题。

1.假如你患有一种病，除了在5年之内有1/1000的可能突然死亡之外，没有其他症状。
如果有一家公司开发出了一种能够治愈你并且没有其他副作用的药，你愿意花钱买么，最多愿意出多少钱？
又比如这家公司开发出了一种药物，这种药物有1/1000的可能导致5年内突然死亡，并无其他毒副作用。现在他们
要花钱找人试验这种新药，公司最少给你多少钱你才愿意尝试么？

2. 阿Q之前听到了内幕消息说，一只股票行情看好。于是阿Q10块钱买了这支股票10000股.今天一看，现在跌到了5块钱。假如股票交易不用支付任何成本。阿Q很生气，打开电脑准备抛掉，鼠标悬在售出的按钮上的时候，阿Q很犹豫，因为内幕消息大多比较准确。是你的话你选择抛售还是持有？
正在犹豫的时候,一个电话打过来了，阿Q去接了个电话。他们家里的猫不小心踩到了鼠标上。按下了抛出按钮。阿Q发现之后，你觉得他是应该在买回来还是不买回来？

3.假如你期待一场音乐会很久了，虽然门票比较贵，1000块钱。但是你还是狠心买了一张门票，晚上正准备出门的时候,发现门票丢了。你会去再买一张么?
假如你白天并没有买这张门票，晚上要出门的时候，发现丢掉了一张1000块钱的电话卡，你还会去买音乐会的门票么？

4.假如你现在在一家商场，想买一辆摩托车，价格5000块钱。正打算买的时候，你的朋友告诉你，一公里外的另一家商场,同样的摩托车只卖4950元。你会到另一家商场去买么。假如你买的不是摩托车。而是自行车，价格300块钱，同样的你朋友告诉你，一公里外的另一家商场，同样的自行车只卖250元，你会到另一家商场买么？

5. 假如你要从巴黎飞往上海，你很想要在飞机上睡一觉，但是你平常都要吃一种药物才睡的着。你在巴黎找到这种药后发现,巴黎的这种药需要200元一片，而在上海要卖500元. 你会买一片么？
同样的情况，如果在上海这种药只卖2块钱，巴黎卖200块钱，你还会买么？

6. 假如你是一家公司的总裁，你们正在做一个项目，已经忙碌了9个月投入了,500万元，再有一个月投入50万元就完成了。这个时候一份比较准确的调查报告显示，你们的产品投放到市场上面，不考虑已有投入的情况下，有10%的可能盈利2500万元，有90%的可能亏损500万元。那么你会选择坚持这个项目么？

这些问题都来自一本书《别做正常的傻瓜》,作者奚恺元. 书中还有很多其他的有趣问题。虽然有些问题仔细想想，也其实存在一些漏洞。向大家强烈推荐这本书。书中通过这些生活化的例子展示, 很多人在生活中的所作出的选择和决定，虽然符合在大多数人的正常思维，但其实不是理性的,他们是“正常的傻瓜”。书里面具体分析为何人们会作出不理性的选择，原因包括心理账户，交易偏见，沉没成本误区，过于自信，和适应性偏见,损失规避,忽视未得收益等方面。 同时也在教我们如何才能做出理智的选择,脱离正常的傻瓜行列。

Tags: 交易, 行为决策学, 选择

yield的简单理解

python中的yield关键字，之前没有仔细看。今天看了一下。我的理解是这样的, yield将一个函数打断成了多段,形成了一个迭代器(简单的理解成一个数组，数组中的每个元素是一段代码)。每次调用该迭代器的next()或者send()方法的时候，执行这个函数的下一段，然后保存函数执行中的各个变量的值和当前的控制流程，等待下次执行next()或者send()的时候恢复。

例如 下面定义的add函数

调用add函数的时候，并不执行add函数中的代码。而是返回一个迭代器 . （ c=add(10) ）c就是一个迭代器。调用c.next()方法的时候，才开始执行add函数的内容。第一次调用的时候执行到yield这一行中止了，输出a的值10。下一次调用c.next()才输出11。

yield 后面还可以跟一个参数，当调用next()方法的时候，就会返回这个值，外界也可以得到。如果用send(msg)方法，那么yield就直接返回msg值。

上面的这个例子。
第二次执行的时候，如果用c.next(), 那么b=1,c.next()的返回值也是1，输出内容是11。
如果使用c.send(5), 那么b=5,输出内容将是15。

yield这种使用方式，改变的通常的编写程序的思路，在循环递归中的用法就比较复杂了，还需要慢慢体会。

Tags: interator, python, yield

git 的企业级授权工具 gitolite

git和hg等分布式代码管理工具相比较SVN的一个重要缺陷是权限控制问题。不过今天发现了一个工具gitolite(https://github.com/sitaramc/gitolite/blob/master/doc/3-faq-tips-etc.mkd#_security_access_control_and_auditing), 提供了很精细的权限控制。能够控制代码的读写，目录、分支的创建，读写，删除。通过用户分组，正则匹配等方式提供多个代码仓库的批量授权等。工具是用perl写的，实现方式基本上是通过SSH公钥和Git的hook来做的。虽然配置比较复杂，但是作为企业代码管理控制的话还是很不错的。

这里还有一份中文文档，讲解的非常详尽。http://www.ossxp.com/doc/git/gitolite.html

Tags: git, gitolite, 授权, 权限管理