php 的 grpc 扩展在八月十八日已经到了 1.0.0 stable。很高兴的，终于到了一个 stable 版本。这意味着，在 php 中将 grpc 应用到生产环境会安心许多。一些不太稳定的特性或功能，会被排除在发布版本之外，用起来顺很多。 可惜的是，这个 stable 版本貌似在安装环节并不稳定，安装过程中分别会在 configure 和 make 环节报如下的警告与错误。 在 configure 环节的警告： ... checking whether to enable grpc support... yes, shared ./configure: line 4107: cd: ../../grpc: No such file or directory ./configure: line 4138: cd: ../../grpc/src/php/ext: No such file or directory ./configure: line 4169: cd: ../../grpc/third_party/boringssl: No such file or directory checking for ld used by cc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld ... 在 make 环节就直接报错退出：……

(UPDATED) 2017-08-17: ssserver 提供服务器端的支持；sslocal 转本地 socks5 服务；再用 privoxy 提供 http/https proxy。 经过试验，这样的解决方案是最全面的了。 至于梯子哪家强，你问我，我不会不告诉你。O(∩_∩)O哈哈~ 对于功夫网不问青红皂白直接予以封杀的行为，程序猿的一贯态度是问候方校长。有些的确敏感的都不说了，facebook 旗下的工具网站 Nuclide 也被封，之前还有 Python 因为一个特定版本号被封的往事…… 各种搞笑和不能理解的规则，生活在兲朝的程序猿这种生物天生比国外的低矮一截——纯粹因为生存环境的关系，导致看世界不完整。 前两天做 grpc 的调研，为了简洁，安装 php-grpc 时准备就直接用 homebrew 搞定。brew install homebrew/php/php56-grpc，一句命令安装，升级维护也省心。 可是安装 php-grpc 的依赖却出了问题。protobuf 在 homebrew 中是从源码开始安装，用的是 protobuf 自带的 autogen.sh 脚本，脚本中正好从 googlemock.googlecode.com 域下载 googlemock 一个特定版本的发布包，因为 shell 默认不会走系统代理（我用 shadowsocks 科学上网，这是我的梯子，这是下面所列方法的前提。如果你连梯子都没有，可以不用往下看，没戏），会导致下载失败。 英雄汉不能被一泡尿憋死。折腾一会儿，终于找到办法。 后来想想，自动化脚本里面其实挺多这种应用场景的，没谁写个脚本还要兼顾其它国家特色网络，那技术宅成天别干别的事儿，光跟堂吉诃德战斗好了。因此，记一下吧，以后用得着。 下面提供两种办法供选用。两种都简洁，改动都不大，主要看应用场景和个人的习惯吧。 方法一：修改下载程序配置 protobuf 安装脚本中的下载程序使用的是 curl，因此先得配置它。新增或修改 ~/.curlrc 这个文件，加入 socks5 这个选项（因为 shadowsocks 是用的 socks5）。 # 我用的是影梭，所以设置 socks5 选项 socks5 = 127.0.0.1:1080 # 如果用的是 http，设置 proxy 选项 proxy = 127.……

今天在网上看到一个方子，是治疗疖肿（肛周脓肿）的，还申请了国家专利。按照药物专利的申请流程，会要求药理实验。专利文末也确实提供了实验数据及数据来源。效果看起来非常不错（90 个案例，81 例痊愈，9 例好转），值得推荐。PS：拿来做商业用途的别忘了给人缴纳专利费用。 另外，肿节风胶囊治疗疖肿效果很明显，性价比非常不错，也很推荐哦。……

从鹅厂出来之后的这几年，在创业公司做了很多产品技术方面的实践工作，得到一些关于产品技术管理方面的心得，这部分比实际完成一些什么样的系统设计和开发更加宝贵，这是有钱都买不来的。后面一段时间，我尽量将这些心得以博客文章的形式写出来。 之前尝试过大而全和分章节的描述手法，在废弃了十版左右的草稿之后，决定还是用随笔的手法吧，划定一个小范围，想到哪儿写到哪儿，不拘一格。大而全格局太大，自己荒废了很长时间没写文章，把控不住；章节形式专业性太强，没做好写论文的准备，就不拿一些带主观心得的东西贻笑大方了。 相较于我刚开始学互联网编程的那段时间，也就是二十一世纪初的那几年，现在的互联网盈利模式更加清晰，业务和产品趋于红海竞争，值得去尝试的蓝海领域越来越少。带来的一个好处是：产品技术方面能够复用的东西越来越多。 举个现实中的例子。因为花椒、映客等等关系，最近遇到一些朋友想要做直播平台，要我给他们建议。我大致估了一下，质量上以产品原型计，大约有百分之八十以上的组件，包括比较难的 P2P、DHT、CDN、视频实时压缩等都有成熟的第三方解决方案，只有涉及到所谓『痛点』的大约百分之十几的那部分逻辑需要自己去做。这些成熟的第三方解决方案不管是开源软件也好，还是云服务的方式也罢，都能避免创业者重复造轮子，大幅降低开发维护成本，还能提高用户体验。 然而更厉害，就算是差异化的那百分之十几的逻辑，我们现在也可以利用工程化的手段让它们的产出更加高效更加顺畅。 最近一年我在创业公司积极推进一件事情，就是把初级工程师的成果有效化。出发点是帮助公司降低对工程师水平的依赖，用技术手段提高工程师的工作效率，提高输出成果的有效性。这事儿说透了也很好理解：既然创业公司的项目需求更多是原型实现，并且还有那么多可靠的第三方资源可用，技术团队也就更像是在做集成，而不是技术创新，对工程师的初始能力要求不应该特别高。当然，公司肯定也会同意，因为省钱嘛。o(╯□╰)o 创业公司对初级工程师倒不一定有什么特别的偏好，不过创业公司的 boss 们大多对技术人才无法做到『准确识人』，这是事实。有时候哪怕他们自己想找一些大牛合作，也苦于无法辨别。就算找到真正的牛人，在工作方式方法上通常也会出问题，至少是让其能量发挥不出来。所以干脆的，很多创业公司 boss 与其花冤枉钱碰运气找大牛，不如直接找初级工程师先实现原型好了。很无奈，也是事实。既然是事实，我们首先得尊重它，而不是抱怨，然后才能往后考虑，怎么样改进。 当然，先解释下：依靠初级工程师实现的原型在技术上是不是能够拥有可扩展性，今后是不是可以生长和健壮起来，是个问题。考虑到这是架构师在开工之前需要完成的设计工作来决定的，不可能指望初级工程师去完成，所以这点不在我们今天的讨论范围之内。所以首先，假设我们有一位有能力有担当并且对项目理解深刻的架构师吧。 话说初级工程师的工作一般都不可靠，特别在他们工作拥有自由度的时候，自由度越高则可靠性越差。要提高初级工程师的工作有效性，首先考虑的是怎么『约束』他们，降低他们可以自由发挥的空间。这个思路跟现在流行的互联网『颠覆』的观点可能会有点相冲——你把空间限定死了再做事，还谈什么互联网颠覆呢。不过我认为，就现实中的中小公司创业环境，技术上的创新总是局部的，否则研发成本太高，就是作死，运营和产品上的创新才是具有颠覆性的关键。 通常我给初级工程师『画地为牢』限定他们工作空间的办法有下面几种。 **必须全程参与需求评审，独立完成功能设计文档。**会议和文档化是让很多工程师头痛的两件事情，但是在任何团队中，首先要保证的大家目标一致，花点精力在统一目标上，经验告诉我们，绝对值。 **统一的代码风格和注释要求。**每种语言都有好多种代码书写风格，团队统一采用一种就好，这没什么可争辩。至于注释，最好也要统一一下要求，以便工程师可以在代码中合理添加注释。代码风格可以通过 lint 来检验，而注释则只能通过代码审核的过程，人工指正。 **代码审核后才能合并到开发分支。**一方面是代码的质量控制，确保代码仓库里面的代码都是有效代码；另外一方面，代码审核恐怕是帮助这些初级工程师成长最快的方式。一个好的 reviewer 胜过任何职业培训学校里面的任何授课老师。 **一个严厉的非黑即白的框架。**我不会浪费时间跟初级工程师在技术方案的可行性上做探讨——你当然这样做也能实现功能那样做也能实现功能，但你就是得按照我说的做。整个团队都是这样。没得商量。而保证这一点的最佳手段，就是用一个非常严厉、越雷池半步就报错的框架。 **统一的开发环境和部署环境。**同样，我也不会在这方面跟工程师们有太多商量的余地，必须统一。部署环境由于涉及到运维的配合，与用框架不同一样，从一开始就必须大家都统一。不同的是，开发环境这方面我通常会给工程师们一个过渡期，过渡期内我会推荐我认为效率最高的系统、IDE 甚至 IDE 配置文件，并且提供支持。通常来说，一到三个月的过渡期之内，就能把这事儿统一下来。 **保持一致的沟通腔调。**技术上，各种专有名词和特定的描述方式很多，沟通中大量使用专有名词虽然有时候看起来很装逼，但这样的确可以大大提高沟通效率。对初级工程师，以及我们的产品经理同学，通过在文档、会议中不断加以引导的方式，来强化他们对一些常用名词和描述方式的概念，让他们既能懂也能用，从而提高整个团队的沟通效率。 这样执行之后，做执行的工程师基本上不再可能有什么自助发挥的余地，就像谷歌技术团队的风格：一千人写的代码，读起来就好像是一个人写的。无论是代码和注释的书写风格，功能实现的方式，都是一致的。这样的代码就算放个两三年换个人来维护，也没有障碍。 另外一方面，想要提高工程师效率通常意味着激发个人的积极性，释放他们的工作热情，同时帮助他们扫清工作之外的障碍。从字面上理解，这和上面限定他们的空间相左。说细了，不矛盾。 **统一的开发环境、沟通腔调，降低沟通中的障碍。**在拥抱变化的场景下，沟通随时随地都在发生，如果不能把沟通过程做顺畅，尽力消除沟通中的阻碍，工作效率自然没法儿提高。初级工程师最容易遇到的问题就是遇到问题表达不清晰，想帮助他也无从下手。统一开发环境、沟通腔调，团队成员基于一个场景在沟通，效率自然就提高了。 **把开发流程中重复的步骤工具化。**例如：分情况 pull 代码；根据事件和关键词创建新分支；检测代码风格；部署代码到线上之前跑单元测试；部署代码到线上服务器；排查应用日志…… 如果每次手动做这些事情，势必影响编码的连贯性，把它们做成工具，每次运行一两条命令就可以完成一件事情，不仅可以提升工作效率，还可以提高试错的次数，小步快跑、敏捷迭代。 **研发生命周期的管理从头到尾要做好，对工程师尽量友好。**工程师只有一个工作是有效的，就是编码，其余的工作都是辅助，不能直接产出价值。所以，工程师越能专注地编码，生产效率越高。除需求评审和写文档之外的必要开销，确保工程师大部分工作能够在两到三个界面完成，是最优的结果。这就需要团队能有一套很好的研发管理系统，不是松散的几个第三方工具，而是一个有机的整体，涵盖整个研发生命周期。听起来很高大上，可喜的是，对创业公司也有第三方的选择，只不过需要自己做集成。 **生产环境要有带检索的日志系统和调试工具。**这个就不说了，也可以看做是从第二点中延伸出来的。单独提是因为，线上排错不知道坑了多少工程师的时间，熬夜加班，专门等午夜人少时重现错误，说多了都是泪。浪费的时间不是一点半点。 能帮工程师把编码之外的工作梳理清楚，减少他们被干扰的次数和时长，对于提高生产效率，规避编码中的 bug 效果很好。虽然上面几点在创业公司里面实施起来有些难度，但做总好过不做。况且，其中一部分已经有第三方成熟的解决方案，具体实施的时候只需要做集成即可。 在是给与工程师一个明确的施为空间，帮他们扫清编码障碍之后，技术团队在执行阶段的高效率，维护阶段的清爽，都是可以预料到的。这些准备工作虽然表面看不到有什么明显收益，但是对于公司在中期对外连续作战帮助非常之大。 附录一：推荐的几个第三方工具和服务 代码仓库：gitlab。同时基于 gitlab 的 web service hook，还可以扩展出涵盖大半段研发生命周期的系统，以此完成工具化的搭建。 需求管理：tower。这个纯粹是个人习惯，其实 worktile、trello、teambition 等等都不错。tower 虽然也有 api，可以做信息流集成，但貌似只限于收费的 Pro 版。 OS + IDE：Linux + vim。作为后端码农，这是不二选择。在这个前端要会用 linux 的时代，不会 linux 不能作为理由，只能是工程师自己的耻辱。前端码农根据项目不同，酌情选择更优的 IDE，例如 xcode（iOS APP）、atom（React）、Android Studio（Android APP）等。 后端开发框架：Laravel（PHP）。作为一款大量应用现代语言特性的开发框架，laravel 的缺点也是它的优点：太多的新特性，让初级工程师困在它规划好的地盘里，只能照做。 ……

很早以前听到过一个小故事，大意是说，一群人兴高采烈去登高山。爬山的过程中慢慢开始疲惫起来，这种疲惫和累不一样，是无论怎么休息都无法缓过劲来的。大家一步一捱往前挪着，一点儿没有了刚开始的高兴劲儿。后来在一处岩石边休息的时候，遇到另外一个有经验的登山人，告诉他们：脱下鞋子，抖掉鞋子里面的砂石。他们按照登山人的提示，再出发果然舒服多了，感觉整个人清爽起来，疲惫也散去很多。原来这座山留在山路上的砂石较多，很容易溅到鞋子里，溜到鞋底去。砂石小，虽然硌脚但是不太严重，总去抖鞋子砂石麻烦，一般人也就忽略了。小砂石硌脚时间长了，人就容易疲惫，爬山也不得劲。虽然都是一群爱好爬山的人，爬起山来却觉得没有什么意思似的。 这个故事最后告诉我们：真正让人止步的，其实不是险峰，而是脚底的砂石。 机械键盘 家里有黑轴和青轴两个机械键盘，因为是刚用机械键盘的新手，爱好青轴，噼哩吧啦，感觉挺带劲。但不知道为什么，用青轴的时候思维一旦出现停顿，很容易就分神。开始也没特别注意到这个问题，直到昨天晚上换了黑轴做事。忽然感觉思维的停顿在用黑轴的过程当中，是一件挺享受的过程，键盘就像不存在一样，你需要动手指头的时候，它在那里，你需要思考的时候，它也不吵你。不像青轴，连续打字的时候它的响应很及时很带劲，中间一旦有停顿，它的这种响应就成了吵吵。 换了黑轴之后，明显感觉写东西的效率高了很多，尽管还是感觉黑轴偏硬，而且国产黑轴有粘滞感。 看似差不多的键轴，区别大了。 饮水机 公司只有一台饮水机，坏了还没修，没热水，就先买了电烧水壶顶着。发现这两天时间里，喝水少了好多。 电水壶的水烧开不用很快就凉，泡茶不能用凉水，每次续水之前都烧一次又嫌麻烦。之前是口渴就喝，喝完直接从饮水机续水。现在是口渴了喝，喝完烧水，烧完水之后有大约一半的概率会忘掉，电水壶的水接着又凉掉，等到又要喝水时发现，现烧已经来不及。 常坐着的职业，喝水少了容易得肾结石，明明懂的道理、已经养成的习惯，却因为小小的饮水机坏掉而丢掉。 今天带了家里的保温壶来，电水壶烧开水之后灌壶里待用。感觉世界又和平了。 有时候我们想尽量想避免这些烦人的情况，像登山人抖掉鞋底的砂石。费神费力不说，如果团队的搭档没有意识到砂石的威力，他们总会觉得多此一举，不理解你的行为，谈不上支持甚至会阻挠你。这种不理解和阻挠也是一种砂石，时间长了，不找到办法沟通协调，也会让你望险峰而止步。……

刚在写点东西，整理关于创业这一年的收获和感悟。朋友圈里面忽然看到龙哥转发的消息《“在大陆互联网走得最远的台湾人”——胡同台妹去世》。 讲真的，很惊讶。胡同台妹的称谓我是离职后很久才从网上知道，『哦，原来胡同台妹就是宫铃啊！』倒是她的本名我更熟悉一些。但也就是熟悉名字而已。 零八年那会儿，我在凤凰网供职，农科院信息楼，工位在四楼格子间，封闭开发时经常占据二楼会议室。二楼的办公位因为不是凤凰网租用的，我们只在二楼有两间会议室和一间小小的编辑办公室。得因于此，二楼阳台是开放状态，直接与楼道连通，会议室和编辑办公室都直接与楼道相连。记得那会儿经常有抽烟的同事会在二楼的阳台上认识、聊天。 经常看到宫铃女士也是在那种场合。我不抽烟，也闻不得烟味，就是进出会议室和楼道之间的时候经常碰到。他们那会儿好像经常因为选题开会，当然也是在二楼的会议室。开会久了，有烟瘾的同事就会三三两两出去阳台透气、抽烟，宫铃女士经常出现在他们之间。我印象中她是更喜欢独自一人去阳台的，很少招呼别人陪她去抽烟。若是在阳台上碰到同事也会交流两句，说的多是工作。除却工作的交流很少。有一次，她跟我们做技术的同事在阳台闲聊，讲些家长里短被我看到，那是我印象中绝无仅有的一次。 我在凤凰网供职期间，跟宫铃女士可能总共说过不超过十句话。听别的同事说起，才知道这位『小个子，很礼貌很有修养，说话做事干练，有点时髦（指抽烟）』的女士是在帝都的台湾人，而且是在两岸话题上有些知名度的媒体人。严格说那时我算初入职场，对处在这样高度的同事，自然是敬佩有加。这种敬佩之情在我得到她『胡同台妹』的网名后更加一筹。 认识宫铃女士那会儿，马英九还没当选。今天她离开，蔡英文已经完成就职演说快两个月。整八年有余。 祝愿一路走好！天堂里面自有祥和。……

前段时间重装系统 Windows7 之后，在其上安装 VirtualBox 却总是无法启动虚拟机。最初是根据经验对 VirtualBox 版本进行降级，但是没有效果。后来问谷子哥问到了答案，修复之。 因为网上的各种答案均需要重启进安全系统或者 PE 系统，还需要自行搜原版的系统文件覆盖系统中现有的，一个不小心用了不恰当版本的文件替换，导致无法进入系统才是杯具。大家都知道 windows 各种 SP 众多，各 SP 之间的文件不一定是通用的，这个问题还是需要小心的。 而我的办法很简单，一句命令，一次重启，搞定（前提，你的系统没有被『优化 C 盘空间』，否则你还是折腾替换文件去吧）。 先说错误的提示。关键是下面这一句 Unable to load R3 Module 原因是：某些 Windows 的改良版本为了解决 Win7 第三方主题装不上的问题，把 uxtheme.dll 进行了『破解』，这种破解导致 VirtualBox 调用 WinAPI 失败。 解决思路：将 uxtheme.dll 恢复成原版的即可。网上的思路是利用重启到安全模式或者 PE 系统中进行文件替换，我的办法是用 windows 自身的 system file scan 工具来完成（只需正常重启一次）。 解决办法： 1、打开『命令提示符』，执行下面的命令： 2、sfc /scanfile=%systemroot%\system32\uxtheme.dll 3、正常重启，启动虚拟机，搞定。 当然，第三方主题应该是用不了。这个得失你得自己权衡。按说能玩儿虚拟机的主，对个把不产生生产力的主题，应该是可以放弃的。哈哈~~~……

前段时间在朋友圈里面看到一篇文章，确切说是一篇鸡汤文，他介绍了『最速曲线』的概念。 最速曲线也叫『最速降线』是用来描述物体怎样最快从一个高位点运动到低位点的。在最速曲线上的物体，其运动有一些特殊的特点，这些特点也给我们很大的启发。 生活中的事情，直线前进往往都不是最快的。太理想化。 从表象看，沿着最速曲线前进的过程，是一个不断调整目标的过程。 冷启动的时候要注意势能转化，顺大势而动，会省很多力。 但在冷启动的时候，太急于将势能转化为动能，反而会欲速不达。 无论从最速曲线上哪一个点启动，运动轨迹都是重合的（最省力的路径都是一定的）； 无论从曲线上哪一点出发，达到终点的时间都是一样的。但后出发的一方势能要更大才行。 下面是原文 送给大家，共勉之。……

使用 EasyWeChat 库调用微信服务的时候，在 laravel tinker 里面调试，发现每次进入 tinker 之后，第一次调用接口没有问题，第二次之后，就会报一个很诡异的错误。 $app = app('wechat'); // EasyWeChat\Foundation\Application {#628} $users = $app->user->lists(); // EasyWeChat\Support\Collection {#756} $user = $app->user->get('o7qrUviv1tkcDFMJ5wdXrpng9NNQ'); // GuzzleHttp\Exception\ConnectException with message 'cURL error 35: A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has occurred with the token or slot. (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)' PKCS #11 返回的错误，好高端啊。 中间的曲折就不说了。答案在一篇歪果仁的博客上找到，在 github 的评论上得到印证及解决问题的思路。 NSS error -8023 using AWS SDK for PHP Consecutive API calls return curl error code 35 on CentOS 6.……

最近和朋友聊天，发现大家普遍遇到比较多下面一些情况。 『这个功能不是已经实现「差不多」了吗，再加个功能很快吧』； 『以前做过「类似的」功能，这次项目可以复用以前的模块咯』； 『怎么要这么长时间，这个功能以前不是做过的吗』； 『都快 deadline 了还没做完啊。再加个人，一定要按时发布』； 『我们团队已经这么多人了，怎么还完不成这么简单的功能』； …… 遇到上述情况之一，不仅管理者无奈，作为工程师其实也很无奈的。有些事情真的不容易解释清楚，比如：动态需求和动态需求管理。 如果定义我们看到的产品需求是静态需求，那么从一个静态需求向另外一个静态需求迁移的过程，就会产生对应的动态需求。过去工程师们一般会将这种需求称为需求变更，不过这种说法容易导致产品经理的抵触，因为一个产品实际中总是充满各种变化的，不能很好执行需求变更的技术团队不是好的技术团队。为了避免这种误解，我们称呼其为动态需求更好一些。 解释一下为什么通常动态需求会让工程师抓狂，这事儿就好理解了。 一般来讲，完整的项目需求给到工程师，架构师会首先根据项目的需求进行系统架构设计，一方面尽量实现项目的需求，以满足各相关方的利益表达，另外一方面还需要结合项目的发展规划、团队实际情况、现有技术架构等情况，尽可能多地实现非功能性的目标，包括可维护、可扩展、安全性、稳定性、易用性、质量控制、灾备方案，甚至团队构成、成本核算。有句话叫『没有最好的解决方案，只有最适合的』。针对每个具体的场景和需求，一定会有一个相对合适的方案，而这个方案也就是具体到这个场景和需求的，如果简单地把方案挪用到其它场合，就配不上『最优』这个形容词了。 所以，当一个适合某场景的方案产出了成果，我们要直接复用它，拿它为另外一个场景服务，这就是一次从『最优』到『次优』甚至『不优』的迁移。也许这两个场景中一些需求是存在一定程度的重复，因为各个因素的关联性，为了保证迁移之后的方案能相对『较优』，一定是需要额外付出劳动的，而且往往，这种付出对应的工作量还不小，很多迁移本身就是一次大工程。 这也解释了为什么很多工程师往往愿意选择自己重新造轮子，也不愿意使用别人的代码，因为使用别人的代码需要读代码、抠细节、做迁移，当然也包括承担和消化前人遗留下来的谬误。 对于很多创业公司来说，忽视动态需求的危害已经到了能够影响公司自身发展的地步，却很少有人能意识到。最近几年大家对非功能性需求普遍比较重视，因为有人通过技术债的概念将它抽象出来。可惜需求到需求的迁移产生的代价，还在水面之下，不为众人所见。 后面有时间再讲关于如何处理动态需求带来的问题，以及动态需求的管理。……