关于ISO27001:

ISO27001认证，由英国标准协会（BSI）于1995年2月提出，中文全称《信息安全管理实施细则》（BS7799-1:1995）。它提供了一套综合性的、由信息安全最佳惯例构成的实施细则，目的是为确定各类信息系统通用控制提供唯一的参考基准。1998，提出了第二个部分，中文全称《信息安全管理体系规范》，它规定了信息安全管理体系的要求和对信息安全控制的要求。2005年被ISO国际标准化组织采纳，形成了ISO/IEC 27001:2005。完整的ISO27001包括了11个方面、39个控制目标和133项控制措施。是一个不折不扣让一个互联网人晕到吐血的管理制度。主要11个方向包括：
1. 安全方针
2. 信息安全组织
3. 资产管理
4. 人力资源安全
5. 物理和环境安全
6. 通信和操作管理
7. 访问控制
8. 信息系统获取、开发和维护
9. 信息安全事故管理
10. 业务连续性管理
11. 符合性
通过对整个ISO27001这11个方面的落地，实现一个ISMS(信息安全管理系统)。这里特别说明，这个系统不是互联网概念上的系统，指的是一个体系化的东西，包括了上面所属管理、行政、人事、信息技术等各个方面。详细的就不在这里说了，实在是好多。目前这个工作已经在做了，这里给大家看一下我们的列表，这里面大概60%是技术团队要做的。
ISO27001与HIPAA

之前有不少人问HIPAA的事情，现在估计也会有不少人问ISO27991和HIPAA的区别。所以这里简单说明一下。从概念上说，ISO是一个标准，可以由相关评级机构进行评级，办法符合标准的认证证书。这个证书可以用来和企业进行合作，以表明我司在信息安全方面的准备和能力是充分的。而HIPAA是一个法案（也可以说是一个法律），就是每个医疗相关企业遵守是必须的，不遵守如果被举报就要吃官司。哦，对了，这里还要特别说明，ISO和医疗无关，HIPAA是专门为医疗信息保护准备。所以ISO主要讲的是信息保护这个系统工程要做哪些和怎么做；而HIPAA虽然原则上提供了一些强制性的标准和工作方法，但是其核心内容更加强掉哪些信息是禁止泄露的。

所以说，本次公司的ISO27001认证，我们也是请了相关具有评估资质的公司来进行评审。
ISO27001我们所做的和下一步需要做的事情

下一步主要要做的事情就是完善文档和制度了。这里我想特别说明，之所以我会很重视这件事情，不是为了完善文档和制度，反而是从一个专业技术的角度，想想怎么从里面尽可能找些方法，避免繁琐的文档和制度。在我心里，过于完善的制度和方法，对研发和快速迭代，快速试错本事是有害的。所以，尽最大程度的减少ISO27001对互联网团队的伤害，是我最近想研究的一个话题。有了结果的话，可以再写一篇博文了，呵呵。看一下一片标准的ISO27001文档的样子，像下面这种文档理论上是每次都要写的。做过企业软件的人，应该知道。

总之，ISO27001确实是一个挺麻烦的东西。但是，从企业合作的角度，又不得不去做，并且也可以成为公司系统安全方面比较好的一个PR背书，从这一点上看，质量体系的工作比HIPAA的工作实际上在中国更有公信力。所以吧，对于我来讲对于这东西属于虽然很反感，不屑，但是又知道很有用，不得不去做的东西。希望看到文章的技术兄弟，也是对此表示一种尊敬吧。我自己承认，了解还是有必要的，只是要做多少，大家根据实际情况做到心中有数就好。

Jul 3 2016

Technology

无UI系统设计之实现

上一个

Jul 2 2016

Technology

无UI系统设计之再建图灵

在过去的十年时间里，从微软到ThoughtWorks，再到后来做了杏树林，历经了Symbian，Windows Mobile，然后的Blackberry和Android，直到后来的iOS，WP，设计了一个又一个从前到后的系统架构，差不多经历了大半个移动时代的发展。还算完整的工程师生涯让我对用户体验和人机交互有着格外的感情。直到有一天，一场争论让我陷入了沉思。

事情缘起于对后台运维系统的设计。在最开始季度初的时候，我雄心勃勃给DevOps团队定义了一个目标，让运维同学学会使用Axure作出产品设计原型，推演操作路径。这在我们这种搞移动产品设计起家的人眼里是顺理成章的事情。然而，技术专家的反对，却给了我一闷棍。后来想来，UI设计对于运维系统而言简直是极大的浪费。原因如下：

运维系统的核心任务，是提升运维人员的工作效率，提升运维质量（降低运维差错率）
运维系统的面向对象，熟练的操作人员（研发、运维）
运维系统的研发目的，以最快速度，解决现有问题

第一个很重要的原因就是，正是因为如上所述，要快、要高效的面对熟练人员。如果是工作效率在运维系统中可以使用机器来尽量多的完成任务的话。那么“快”在运维系统的研发中就显得格外的重要。其实，当今世界上最简单的，也是最早出现的交互见面便是Terminal。在Terminal的情况下，大量的UI工作和交互工作都转化成了基本的命令，不再需要写表单，调整在不同窗口大小情况下的适配，也不用做繁琐的IE，Chrome等浏览器适配工作。这让DevOps研发更多的关注于“核心任务”，就是用机器方法提升工作效率本身，让出了核心功能外的代码降低到最大程度。

第二个原因，其实，随着后移动时代的到来，越来越多的人已经开始从2007年手机触屏所带来的一股极大的UI交互体验旋风中走了出来。渐渐的，一种更加方便简易的形式在兴起。Cortana, Google Now和Siri，人机对话。其实，早在Symbian时代，就有一家著名的公司Nuance公司，从事语音识别，而且效果已经很高了。不过微软、Google和苹果在识别的背后加入了更加强大的语音分析引擎，让识别结果更加语意化，可以基于场景来从事更多的工作。因此，如果说过去我们在交互这个领域，还在苦苦追求更加简单、易于理解和上手的人机交互的时候。新的机遇自然语言或者简易自然语言的交互，很可能会在不远的未来改变我们的生活，而这一切，一定会从技术本身开始。

Github去年发布了非常有意思的办公自动化软件Hubot，他通过添加adaptor的方法，想Hubot注入更多语言交互指令，让Hubot可以通过一系列在Chat过程中的指令模式完成操作。其实本质上说Hubot和Terminal的工作原理并没有多大不同，但是这一次，对话不再仅仅限制在Terminal上，更加无需了解很复杂的ip地址和命令。如今的交互在IM软件上，通过一些预先设定的语言类指令来完成。

前段时间，Google发布了他们的语言搜索系统，WWDC在新版的macOS上面加入了语义搜索功能。可以想见，ChatOps，ChatOffice，ChatXXX为代表的一系列人工语音交互模式，将会实现。那么如今，我们要做的，就是把业务内核准备好，剩下的就是不断探索更新的技术所带来的便捷。

最后，写到这里的时候，我忽然想到了一个事情－－图灵实验。1950年，图灵发表了具有里程碑意义的论文《电脑能思考吗？》，在里面第一次提到了人工智能的概念。图灵对人工智能的描述就是，有一堵墙，墙上有一个小窗口，窗口的两侧，一边是人，一边是具有人工智能的机器。如果两方都认为对方是人的话，则实验成功。现在看起来，这样的日子真的不远了。:)

Jun 4 2016

Technology

关于文字集与编码

写Python2的人，很多人都见过下面这行Error

Traceback (most recent call last):
  File "/Users/Jack/Documents/ApricotForestDoc/2_product_rnd/redspiderlily/mailfetcher.py", line 35, in <module>
    if is_reply_mail(subject):
  File "/Users/Jack/Documents/ApricotForestDoc/2_product_rnd/redspiderlily/module/mailutil.py", line 46, in is_reply_mail
    return ("回复" in subject_.lower()) or ("re:" in subject_.lower())
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 0: ordinal not in range(128)

上一次聊到Python3升级的一个重头就是unicode编码。所以这次想重点就聊两句字符编码。说实话就是在此之前自己也有些算不清楚。所以还是深入的跑到wiki上研究了一番，分享供参考。

ASCII，全称American Standard Code for Information Interchange，是一个字符编码标准。使用0-127（2^7)的数字代表不同的英文字符，这里包括大小写字母，空格，特殊字符等。这是一个大家都比较熟悉的字符集标准，可以看看下面图中的内容。这里不做赘述。

但是，ASCII因为标准内含有的有限，带有音标的字符‘é’就无法很好的表述，更别提汉字了。到了1980年代，计算机技术发展，那时候大家已经开始使用字节（byte）来作为计算机基本计数单位。1byte＝8bit（2^8=256）,所以可以表述的字符变多了。那个时候开始出现了实用128-255这些数字表示发音单词。所以直到今天，你去看word里面的字符表，Latin依然可以看到这个顺序关系，大体就是这个原因。

再之后，当世界各地的语言发展出了各自不同的字符集体系，比如中国简体（GBK，GB18030），中文繁体（Big5，以前有个特别扯的名字叫做大五码），法语（Latin1），日语等等。本来各种语言字符集各自写互不干扰，倒也相安无事。但是，世界大融合嘛，于是问题来了。有人需要在中文里写上一段日语，就像这样 ++“日本語にほんご”++ 。于是问题就来了，怎么才能在同一个文件里现实不同的字符集的字符内容呢？1980年，人来开始尝试解决这个问题，并制定了一个新的计算机工业标准用以规范的处理、表示和编码全世界主要文字。这个标准叫做Unicode（全称是The Unicode Standard）。目前，Unicode标准是8.0，已经包含了全世界已经有超过12万个字符，覆盖129种现代和历史上的语言种类。在这里面需要说明一个额外的概念叫做Universal Coded Character Set (UCS，也叫做ISO 10646)。按照Wiki对于Unicode和UCS的说法，目前两套字符集应该是完全相同的。同一个数字在两个字符集里所代表的字符应该是相同的。但是Unicode的外延要多一些。USC仅仅是一个字符集，而对应的Unicode同时还规范了校对、标准化、表示顺序的算法等。就如同本文提及对Unicode的定义一样，Unicode出来包括了字符集，还有表现和处理方法的部分。因此Unicode应该说是一个更加广泛含义上的标准。

理论上说，Unicode字符集或者UCS有110万字符点数可以被分配，目前时机分配成16个Plane，其中Plane0，被叫做BMP（Basic Multilingual Plane），一共65536个，其中绝大部分是中文（Chinese），日文（Japanese）和韩文（Korean），三者合称CJK。

这里需要特别提一下Chinese Simplified（GBK，GB18030），自从2000年以后，中国政府规定，所有在中国售卖的软件产品必须支持Chinese Simplified（GB18030）字符集。因此在我国，就出现了一个神奇的事情，就是Unicode和Chinese Simplified双字符集并行的问题。

有趣的是，笔者大概调研了几大中文网站的编码如下：

URI	字符编码
https://www.taobao.com/	Unicode(UTF-8)
http://www.jd.com/	Chinese Simplified (GBK)
http://bj.meituan.com/	Unicode(UTF-8)
https://www.baidu.com/	Unicode(UTF-8)
http://cn.bing.com/	Unicode(UTF-8)
http://www.sohu.com/	Chinese Simplified (GBK)
http://www.qq.com/	Chinese Simplified (GBK)
http://www.sina.com.cn/	Unicode(UTF-8)

感觉上各个大厂也是自说自话，不是不是很一致要遵守政府规定或者不遵守规定。这么说来，国家对这块儿在申请xxx备案的管理也不是很严格。

话有点扯远了，咱们再回来。目前Unicode字符集共设定16个Plane（数字从0x000000-0x10FFFF）对应(2^16+2^20)对应（1,114,112）。刚刚说的Plane0，基础语言集定义是从0x000000-0x00FFFF(2^16)。其他的大家可以查，Plane1和2用了一些，其他基本上用的很少。因此总共来说目前分配的字符大约是12万。

但是这样庞大的数字和计算机的比特（byte）之间并不统一，把一个Unicode字符串转换成Byte的过程，这里引入了一个叫做Encoding，编码的概念。1992年，为了兼容不同处理器和C语言，人们引入了一个编码标准，这就是大家广泛知道的UTF-8。截至2016年5月份，在WWW上的统计，UTF-8的使用率已经达到86.9%，对比GB2312（0.8%）。同时W3C也把UTF-8作为XML和HTML的推荐编码。

下面我们来阐述一下UTF-8的实现原理（同时可以结合下图来看）：

如果是7位以内表述的字符表数字，就只占用一个自己，表现为（0xxxxxxx），这样刚好和ASCII码的描述相一致，这样就不会造成原有ASCII的识别错乱，特别是针对C语言的strlen()和strcopy()。从第8位，也就是十位数的256开始，采用两字节表述模式（110xxxxx 10xxxxxx),最多可以表示11个bit位，也就是2^8(256)到2^12-1(4095)。以此类推。是不是一种很有趣的编码模式 :)

下面看一个栗子。以杏树林的“杏”字为题。

所以总结一下，Unicode和ASCII是一个字符集的概念，他们是随着电信发展而产生的编码本。只不过Unicode有多包涵了表示和处理部分，范围会更广泛。为了让计算机能读懂编码，适应计算机的计算，我们有了诸如UTF-8类的编码方法。

值得参考的一系列词条出处
https://docs.python.org/3/howto/unicode.html
https://en.wikipedia.org/wiki/Character_encoding
https://en.wikipedia.org/wiki/Unicode
https://en.wikipedia.org/wiki/Universal_Coded_Character_Set
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane
https://en.wikipedia.org/wiki/UTF-8

May 22 2016

Technology

升级Python3几个小总结

最近，主要是想集中把这次的改造写完，早日上线。这次主要干了两件事情。第一是升级Python3，这里面顺带写一点学习总结。算是个misc文章吧。下一篇主要是想聊聊没有后台的系统到底是如何搭建以及为什么要做这个实验。

OK，先说这次Python3升级吧。想了很久了，受制于各种阻力，总是担心升级会出问题。但是Python3既然已经嚷嚷了这么多年。而且还是有越来越多的系统在往Python3上迁移，所以还是用用看。至少知道坑在哪里，以后会遇到哪些问题。

总结一下本次修改较多的几个部分：

Print语法：Python3最有名的一个表征就是print的括号问题。在Python2里面是没有的，在3里加上了（）这个语法。所以导致从2向3升级的过程中print，成了修改最多的语法之一。
Pip2（Python2）和Pip3（Python3），一般来讲，如果之前装的是2的，升级到3时候Python和Pip两个命令依然表示的是2，如果要是使用3.x的话，需要加入pip3或者python3，来作为命令开头。为了简单期间，或者用env来定义。还有一种就是在bash_profile里面增加python的alias
1
2
alias python='python3'
alias pip='pip3'
MySQL-python包的使用。这个很讨厌，因为目前这个包还不支持Python3。不过也没什么着急的，换一个呗。PyMySQL这个是Python官方对于MySQL的支持包。对于基本的增删改查操作，用法基本上是一样的。只不过要特别注意的是连接时要加入“charset=”utf8””来实现对中文的支持。这个在MySQLdb里面好像是默认，至少我当时没有设置。
1
db = pymysql.connect(host=host, port=int(port), user=username, passwd=password, db=database, charset="utf8")
关于unicode，这里说道大头了哈。因为绝大多数人对于Python2中文支持都是一个噩梦。文字，被在--之间转换。但在Python3里面，很重要的一点是对中文做了很好的支持。消除了unicode这一层环节。所以现在就可以比较明确的说“中文.encode(‘utf-8’)”就是解码环节，无需再顾忌其他。
也正是因为这个unicode的转变，其实造成了Python2里面很多原始代码都要进行一系列的和字符集相关的变化。比如一个buildin的函数open，在以前2的时代，是不需要对字符集进行指定的（话说，其实也是因为那个时代就没有什么字符集）。现在要特别说明打开字符集类型才可以进行有效的读写操作。
1
open(filename, 'w', newline='', encoding='utf-8')
另外很赞的一点是，Unittest对Python的支持非常好。我自己实际用了unittest2和mock两个库。基本上都没有出现什么相关的修改。非常赞！所以说测试还是要加哦，很不错滴。

这次升级，确实花了些时间，处理问题。但确实得到了不少有益的实践。总结下来是两点吧

单元测试很重要。整个过程中，升级后的第一件事情就是运行单元测试，其中大量的错误，但是不可怕，一个一个的改就好了。因为我的程序设计web、邮件、数据库等多方通讯，没有单元测试，效率会大打折扣，而且还有可能遇到因为网络问题而导致的联调失败
Python2到3的升级并不可怕，主要问题恰恰是来自于unicode这块儿的改变。只要记好了字符集utf-8这件事情。你会发现大量问题，都和这个有直接关系。

Apr 25 2016

Technology

IT背景的人想做移动医疗应该怎么做准备？

刚好在回答一个知乎话题，但是觉得挺值的分享一下的，供有兴趣的童靴，尤其是开始关心业务的童靴参考

IT背景的人想做移动医疗应该怎么做准备？我觉得其实最重要的就是同理心。IT技术是一个用作所有行业皆可的东西，但是正因为他的“干什么都行”，也就决定了如果不是爱自己所做的产品或者方向的话，也很难把一个行业做好做好。前几天，碰到一个做女性社区的CTO，聊起来说自己的团队不喜欢和产品一次思考，不喜欢往前跨一步去为用户考虑。当然我们也交流了许多执行层面的方法，但我问他了一个我很看重的话题，就是“作为一个男人来讲，你对帮助身边的女性解决她们（比如化妆、美甲等）的问题是否有兴趣”。他沉默，没有给我一个明确的答案，其实我大概也能猜的出来，至少我自己不是很有兴趣吧。那我说，如果作为技术的最高负责人，你对所做的业务没有力图改变的兴趣，那很难说你的技术团队能真正感兴趣于为用户提供服务。不如做点技术的事情，让团队先对技术产生兴趣吧，虽然这件事的投入产出比相对比于前者有点低，但也算是一种选择。

就我而言，对医生的同理心感受从很小就有了，各种因素不多说了。总是医生和技术人员一样，是工匠文化的典型代表，说深一点是Geek文化的典型代表。为啥？因为技术人员可以自己写各种好玩的应用，做Demo，但是脱离了业务，其实技术本身什么也不是。同理，医生也一样，你看医生自己可以做实验，研究片子，研究药理等等吧，但是本身医生离开了病人，其实也什么都不是。无论医生宣称自己有再高的成就，如果他没治好一个病人，恐怕没人相信。同理，一个技术人员无论宣称自己有在高的技能，做出fancy的页面，通过高压力的测试，外人也很难确信他所做的工作有多牛。说“医生是把患者背过河”，其实技术也一样“是把一个个严峻痛苦中的业务背过河”。说的好像有点高尚，但这就是医生，这就是技术。技术领域有活跃的Geek，也有混口饭吃的，甚至被迫从事这个行业的普通人。同理，医生领域也一样，只不过他们有两个更加对应的名字“神医”和“庸医”。

所以，我深信医生和技术在工匠文化的表现上是如此的一致。也是因为此，我相信，既然Github，Stack Overflow，Heroku，Amazon Cloud成就了一批又一批技术，让技术迈向新的台阶，那么我相信医生也可以有属于自己的医疗自动化存储、研究、交流、服务平台。所以，我做了病历夹，就像Github一样让医生存储自己的“代码”，让感兴趣的人互相交流，做了诊疗圈，让医生可以互相提问实现能力提升。我还会做更多，做更多让医生这群工匠变得更加方便的事情，成就更多医疗领域的Geek。我解决不了每个医生的工作问题，但我相信通过我的努力，能够让更多人知道、辨别什么人是好医生，是爱医疗这门学科的医生。这就好像我们现在招聘必看面试者的Github和博客账号一样。

如果这个问题是在问要不要投身于医疗这个行业，那么请准备好同理心，和真的想要颠覆一个行业去解脱那些痛苦中的医生们，让好医生获得人们更广泛的尊重，得到本来就应该属于他们的名誉和利益，让庸医无地自容。因为帮助了他们，也就帮助了作为患者的我们自己。这里多举一个身边的例子，我的一个同事，好兄弟，家里姨妈因为胃痛去了一家医院，医生针对胃炎给了些药打发回家了。偶然的机会，姨妈陪兄弟的妈妈检查癌症，于是在子女的要求下，自己也做了个检查，结果发现是早起胃癌，好在发现的早，应该无大碍。我们每个人，不可能每天去医院挂专家。但是如果这类庸医变得越来越少，我想至少他能想到让这位姨妈去做个检查；如果这类庸医变得越来越少，也许我们的兄弟姐妹父母子女会多一分生存的机会。

说回到话题，如果关注点不在医疗这件事情，也没什么对错的；那就关注在技术本身，医疗领域里面好玩有趣的技术也很多，比如和很多其他行业类似的用户体验方面，数据处理方面等等，可以做出很多不错的方面事情。但至于具体是不是要投入移动医疗，或者什么其他行业，那就没有什么特别的了。