写了一个textarea，用js去提取内容。
开始的demo里面是用getElementById().innerHTML去拿，发现是OK的，后来改写页面，textarea里面的内容由用户自己修改，然后点某个href去触发js函数再去取，就不行了。
而换IE是好的。
查查了一个小时左右，才定位到innerHTML的不足。Chrome里面，这个textarea的innerHTML如果没有触发浏览器的刷新事件，那么不会更新，反复取只得上一个值。
这个刷新发生在什么时候？我估计可以是js内部修改，也可以是浏览器其他事件发生，比如submit等。
回到这个问题本身，如何让js在chrome中及时取到正确的内容，搜了一下，改成用value去取就OK了。
今天翻CSDI的PPT，看到有产品经理相关的内容，其中一页列举了在对待新技术层面上的五种用户类型。
其中有 技术狂热者，他们一般是创新者，开创一些新的技术并可能产品化，但另一方面，对市场需求并不是那么敏锐，因为注意力集中在技术创新上了。
第二类是有远见者，他们一般是技术的早期采用者。
第三类是实用主义者，他们一般是新技术起来后的早期使用大众。
第四类是保守主义者，他们一般是等新技术已经广泛铺开后的后期使用大众。
最后一类是怀疑者，他们是落后于技术趋势的。
如果一个公司的核心管理层，完全处在保守主义者和怀疑者掌控之中，那么基本上，已经与创新没有多大关系了。此类型公司的策略，更多的是利用后发优势以及平台优势，在市场上陆续消灭那些根基不牢的竞争对手。
从业务闭环的角度思考，需要有CA (Root)的存在，然而使用商业的CA服务，按证书收费，这不是普通体量的公司能承担的，而IoT设备的数量远超网站需要，因此物联网公司直接去买海量的证书也不划算。
因此，必须是自有的CA服务，然而，到底是托管型合适还是自建合适呢？
就目前国内的情况来说，各种托管型的CA产品也有，只是不清楚其质量，以及面向全球访问的能力是否足够？因此自建其实也是合理的。
自建的需要考虑一些规格上的问题，比如：
CA软件系统：自己开发还是OpenCA或其他？
操作系统
服务器配置
数据库的选择，或是否支持多种数据库
目录访问，LDAP？AD?
热备方案
日志方案及多级规格，签名访问
审计的需求
支持何种HSM?
CA业务系统的技术方案
支持的证书量规模。。。。。。这个取决于业务的规模，如果使用可扩展的方案，则技术难度会稍大。
—————-
CA系统的物理环境（机房等）
—————-
CA系统的管理制度，运维规则
指纹器/模块其实一般是输出一个512×512的点阵图像的，可能是二值的也可能是灰度的。
对于输出的要求一般有认证的标准。目前看到的，FBI PIV IQS(Image Quality Standard)，关于图像质量的认证，BSI(British Standards Institution)认证，Indian STQC认证。
从兼容性考虑，也有FIDO方面的规范。
中国国内的是GB/T 26237.8-2014，但估计并不强烈进行推动。
指纹器收集指纹图像后，后台需进行压缩保存，一般是JPEG/WSQ/EZW等格式，WSQ为FBI所用，EZW是中国公安部所用。WSQ这个算法的使用也是需要认证的。
这么看下来，如果是基于二值/灰度图像的格式，指纹模块应该是比较通用的技术才对。
终于有这些强度不大的出差了。是因为杭州办公室开年会，因而获邀过去参加。是不是已经落到可以刷脸当工作的地步了？慢慢想开了就好了。
杭州办公室，自从我09年参与其技术架构设计以来，已经7年多了。现在的技术还是沿用当年的基础，一方面是当年做得好，另一方面市场日趋成熟，因为对技术革新的要求反而不高，反过来，也对创新人才的需求不足，团队慢下来，也就难以承载革新的任务了。
还是一个技术和市场上不错的范本。
这两年接触各种行业的软件供应商，有的是零售，有的是餐饮，有的是美容美发，有的的烟酒供应，各有特点。
总的来说，功能点的分类如下：
总的来说，各行各业的适配系统虽然各有各坑，总是可以分解并实现的，一个通杀的系统并不存在也不可能存在，但也不必被行业前辈所吓倒。因为过去所做的很多系统是不合理的，总有被取代的可能。
突然想起十多年前的事，那时候流氓软件横行，有一次不小心中了中搜出的插件，反反复复都删不掉。很生气很生气，足足花了一天半才弄干净系统。那时候开始就对陈沛这个人有非常大的反感，我记得当时在互联网周刊工作的song姐姐也去采访过陈沛。他也尝试为他自己辩护说，其实中搜出的插件是没有问题的，那就是别人做的事情栽赃了。
不过我不相信这种说辞，因为毕竟我是被伤害了。那时候我也很无聊，于是拿了20年都没用的一个诅咒落在陈沛和中搜上。
今天想起这个事情于是我再去搜一下中搜的情况。希望他们已经销声匿迹了吧。
结果是他们居然还没死。不过也过得不怎么样。这条新闻标题是：中搜网络被踢出创新层内幕109条诉讼记录的恨意。
再看一下内容，也确实差不多该死了。因为所有的故事都是看着有热点才去做的，就是无能力了。也许也就是这种流氓不大可能再有成功的机会了。
作为线下店，首先是要做到顾客上门，然后是提升顾客浏览商品时的体验，再然后就是增强顾客购买的意欲，最后是支付以及支付后的反馈。
在第一点增强到店率上，线上线下店进行同步，让顾客在网上、app上浏览货物的同时，也能知道线下店有什么优惠，有什么好处，百闻不如一见，这样就有了想法，然后再提供最近的到店选择，为他们推荐最近的店。而对于那些随意游荡的顾客，也许就是比较传统的招牌、广告牌去吸引了，另外，免费的wifi连接、以及免费的充电服务，也能一定程度上提高这类人群的到店比率。
第二点时提升顾客浏览商品的体验，最近荷马鲜生的实践还是让人耳目一新的。你在浏览货品的同时，可以看到它的源地、过程等信息，就是一个个商品的故事。
但顾客对于一个从来没有买过的商品还是不放心，他习惯于看看网上的评价，以及看看网店上的价格，假如他看的是淘宝，十有八九会有更低价的。。。
所以如何吸引他决定购买，就更难了。首先是评价，店家可以提供app或者在显示屏上列出常用的购物网站、社交媒体上对商品的评价。当然了，如果好评是来源于顾客的微信好友，那么对成交就更有推动了。这里涉及到一个稍为复杂一点的社交媒体的开放平台，才能允许更多的渗透。
对于一些周期性的购物或者订阅来说，比如订鲜奶、蔬菜等，由于是持续性的消费，那么决定购买，更依赖于互联网和社交平台的评价和反馈。
然后就是比价，比价这个事情是让商家最难受的了，之前有几家做过比价的app，最后都消亡了，断人财路不好啊。目前没有想到商家更好利用比价模式提升成交的策略，也许意味着让利了。
最后就是支付。
除了现场选购现场支付之外，还有就是线上下单，下线支付和提货的，这也是实体店存在的一大理由：作为小型提货点而存在。
而现场支付+提货，又可以产生一些购物回馈、积分、优惠券的活动。线下购物本身也应该为线下再增加吸引力。
总结一下：购物体验、购物回馈增强顾客到店的意欲，省却物流成本，也可以在不用折扣太多的情况下消耗库存。
比较典型的例子是QSR，Quick Service Retailer，包括快餐店在内的。
Cartes改名Trustech了，地点从巴黎换成戛纳。这次我没去，但按照Trustech Sesames的名单分析了一下一些参展商的技术和产品。
看上图，实际上就是在账单夹上嵌入一台带EMV，NFC支付的支付平板，之前的流程均可以在支付平板上进行操作。当然了，一些智能应用也可以在该平板上面实现，比如顾客激励、会员积分计划、问卷调查等等。这个星期把google0304年发布的几个技术论文的翻译看了一下，算是补一下课，后面还需要持续补课。
首先是Google File System，简称就是GFS，原本设计用于一个机器集群的低一致性的网络文件系统。用一个master调度和记录内容存储的chunk server，文件系统的访问端就是client，先询问master，得到相关的index，就去和chunk server进行读写访问。当然细节有很多了，包括文件的块大小，一般是什么样的文件。
GFS基于的文件假设是顺序写比较多，很多append的操作，随机写的比例低且实时要求也低。因此在GFS之上，又有了BigTable的文件，其实是一个key-value的数据库，适合使用GFS。
对于www产生的文本内容，BigTable的三维结构是合适的。但GFS和BigTable只管保存和查看，如何高效地对内容进行计算，则引出了第三个技术：MapReduce。
MapReduce分成Map和reduce，类似于函数式编程的模型了，写好map和reduce之后，MapReduce的框架就把分布运算、负载均衡等等工作做完了，等着取结果。
GFS + BigTable + MapReduce在目前看来也许不是最优的，但Google当时规划出这样的体系结构无疑是对互联网的超大贡献，自此之后，Amazon、Facebook、Tencent、Alibaba、Baidu等等都有了参考的模板。
今天只是起一个头，后面再补上其他云计算+大数据技术的心得。
……
改公开了，因为术的发展速度太快，而我由于跟不上只好跟着道走了。