leaflet

我就不爱用 redux ， 好多时候只要 pub 一个数据到目标组件，不需要进 store 的也要进去绕一圈。而且 redux 把组件功能的显示部分(viewer)和数据操作部分(reducer)拆开了。反而不利于组件化。

用 React 和 jquery 等一起用，各取所长用起来比较爽。 toastr,alertify 这种全局组件之类的用传统的就很方便，反而是用 react 硬凹的 toast 很难用。

jQuery 组件因为常常会绑定到全局 dom,所以常见的用法是 Page(A 组件， B 组件, C 组件)
React 组件的因为没有全局绑定，所以比较容易干出 Page(A 组件（ B 组件（ C 组件， D 组件)）），复杂的组件可以不断分解为简单的组件。各个击破。

组件化，组件化，组件化！
有点像当年从面向过程编程到面向对象编程。
@ziki 说"我用镰刀也能干完活，你整什么收割机啊" 我也同意，就像有的程序用面向过程的方法能轻松解决那是完全不需要面向对象，过度 OO 的。
然而，有人用镰刀，也有人需要要用收割机不是么？

React 真心很好用。第一个项目写组件的时候有些痛苦。第二第三个项目就可以大规模复用。效率提高很多。不过我不用 flux ， redux ， rxjs 。基本 react+pubsub+underscroe 搞定大多数场景， jQuery 的工具也可以混用。

@wuhx 随机的
@vpncup 目前是随机的. 日后可能加个点赞功能来给句子打分.

用类似原理做了个读小说的应用 http://one.treenote.net/

@monk 2 句一起用嘛

谢谢大家. 先做了个原型
http://one.treenote.net/

其实随机的要求没有很高. 所以差不多的办法都可以. 考虑的重点是作为 web 应用,不希望每次请求都要读硬盘. 我初步考虑的方案是做 2 重随机. 一个慢随机,是每累积多少次访问就去磁盘随机 load 一些大内容块到内存中. 一个快随机,每次请求都从内存中随机的取出小内容块.

@Andiry redis 对 value 的大小有限制么?

@Andiry 谢谢.我也刚刚想到. 以前有 redis 只存储小的键值对. 有点思维定势了. redis 好像有个 diskstore?

演示下如何掺沙子。 为了方便理解。不用英文了。中文请脑补为拼音。
伪随机母密码：『两个黄鹂鸣翠柳』
=>
黄鹂鸣翠柳
2 个黄鹂鸣翠柳
两个黄鹂鸣:翠柳
两个 /黄鹂 /鸣翠柳
2 个 /黄鹂 /鸣:翠柳
2 个 /y 鹂:鸣翠柳 (注： y 是 yellow 的意思）
2 个 /y 鹂,鸣:gt (注： gt 是 green tree 的意思）
2bmgt (注： two birds 鸣 green tree )
两个黄鹂在 V2EX 鸣翠柳

采用唐诗的意义在于，由于母密码是有语言含义的，用户可以做很多变幻，又不丧失可记忆性。
为了避免母密码过于集中，唐诗密码本采用的是全唐诗，字数是唐诗 300 首的 140 倍。
加上类似上面的 特殊符号断句，数字化，英文化，减字, 增字 等多种变幻手法排列组合,一个母密码可以变幻几百倍。

从另一个角度说，一般用户用的密码强度就比密码本生成的高？很多都还不如。为什么不用复杂的随机密码呢？因为没法记。所以不实用。 密码本的目的是让有一定强度的密码能够真正用起来。还是那句话，不要求跑过狮子，跑过慢的就行。不要求密码无懈可击，比原来的强度好就行。 密码本的目的，是寻找一个『好记』和『强度』的平衡。

人类密码=好记+随机性
密码本解决的是=好记+伪随机

我同意 @lonelygo 说的要加个人转码逻辑。设计上就是这么考虑的。但是这个转码逻辑不加在程序里，留给用户自己。不是作者偷懒，而是这样才安全。

无论程序如何加规则，出来的都是大字典。
最终使用的时候建议是用户根据自己的个性掺沙子（用户个性规则）。
最终密码 = 程序建议密码（好记+伪随机）+ 用户个性规则（用户个人方便记忆+更强的随机）

比如密码本生成全的是大写的『 MJZWWXY ， XZ3ZBYR 』 这是个种子密码。
用户在这个基础上有无数中排列组合
『 MJZWWXY ， XZ3ZBYR 』 ->

简单无标点： MJZWWXYXZ3ZBYR
替换标点： MJZWWXY#XZ3ZBYR
每句取首 2 个大写，其余小写： MJzwxy,XZ3zbyr
每句只取前四个字： MJZWXZ3Z
加上用户偏好的固定数字： MJZWXZ3Z1314

还有类似『飞流直下三千尺』，程序给的建议是 FLZX3QC. 用户完全可以用 flzx3000 ，或者 flzx3kc

这样的排列组合对原字典扩大很多种可能，同时，因为『沙子』不在程序里，所以更加安全。

沙子用户自己掺有 2 个好处：
1. 自己想出来的沙子好记
2. 沙子在用户脑子里：安全

如果既然要用户费脑子想沙子还要密码本有什么用？

沙子本身可以安全性很差，可能只有 1~2 位，可能用户长期都用一样的沙子。
real_password= pesdo_password (机器生成的)+simple_password （用户生成的）

沙子本身可能只是一个变幻规则，要作用到一个字符串上才能成为实体密码
real_password=userTransfer (pesdo_password )

沙子对用户本人是好记的。有较弱的安全度。

伪密码对知道明文的所有人是好记的。有一般的安全度。

伪密码+沙子=只对用户本人是好记的。有较强的安全度。

自己搜了下『唐诗密码本』，发现下文，不是我写的。想法很相似。
http://www.360doc.com/content/10/0520/16/114824_28577582.shtml