人体工学座椅这个概念在这几年迅速风靡起来，如果没用过这个椅子都感觉有点不好意思跟别人说自己跟电脑打交道的。尤其是互联大厂纷纷以其为“福利”吸引各种打工人，从国外的FLAG到国内的BAT，人体工学椅似乎被打了一个“高端”的标签。而椅子的品牌则从高端的Herman Miller、冈村到国内的保友、Ergomax。甚至出现了很多ODM的产品，严选、京东。人体工学座椅的产品完成了从高、中、低的全层面覆盖。但问题是，我们真的需要一张人体工学椅吗？ 诚然，一张椅子对一个长期伏案或者电脑工作者是非常重要的。但是我们真的需要一张1万块左右的Aeron2？Embody和严选的又有什么不一样呢？要解答这个问题，首先要考虑我们到底想要的是什么？是健康的颈、腰、臀。那怎样才能得到健康的颈腰臀呢？答案是科学的座姿+适当的辅助。关于科学坐姿的解释，可以参考知乎这个答案，我这里贴个图： 从上面的图可以看出来，其实坐姿是一个比较系统的内容。如果你能按照这些参数，从脚底开始测量，量好坐高、桌子高度、显示器高度，就算是完全固定的椅子和桌子也能得到一个合理的坐姿，再加上自身的肌肉锻炼，就完全可以了，根本不用所谓的人体工学座椅。张大妈这篇文章就非常好的说明问题。 如果你是新选购桌子+椅子，完全可以参考上述文章。 对于桌子，首先定制一个略低于常规的桌子。75CM的桌面真的太高了，我现在就是76CM的桌面高度，手需要抬得比较高才能使用鼠标，导致使用鼠标时的支撑点在手掌，手非常累。对于180的男生，68CM左右是比较合适的台面高度（记住是包括台面板材厚度） 我用的是永艺的这张椅子： 目前的椅子高度其实是合适的，不过这张椅子除了太窄（因为太胖了T_T），在我坐满后，基本无法打开大腿。对男生来说有点难受，懂得都懂。所以椅子除了高度外，宽度也是一个比较重要考量的因素。 所以回到刚才的问题，我们到底需要一个1万多的人体工学座椅吗？我认为是不需要的，除非： 你无法决定桌子或者椅子的高度，来适应自身的坐姿。例如你在公司、桌子的高度固定，这时你可以考虑用人体工学椅子去适应桌子的高度。但是需要注意这个调整只能在一个比较小的范围，并且你能得到只是一个次优解。 长时间*不能离开座位*的，我相信除了除了一些特殊岗位外，并不存在这种情况。所有的人体工学座椅所谓的支撑，还不如你每一个小时走动1-2分钟。而且有一些所谓的支撑，反而是反人类的错误设计。例如友保的金豪E+，我在公司就有用，顶得我的腰难受。 需要底部透气的，目前人体工学椅大部分都是网布设计的。但是要注意，用网布带来一个问题就是如果网布的弹力太弱，可能会导致凹陷，压迫大腿。尽可能用好面料的座椅，就我目前的体验，网布确实会带来一定的不正确大腿受力。

本文作为我个人尝试使用Notion作为PKM的核心软件这一段时间（大概6个月左右）碰到的困惑、疑问和总结。通过下面阐述的几点思考，最终得出标题中的结论，并且在文末简述后续尝试的方向。 官方定位 从今年开始迁移到notion后，虽然基本能保持周更新。但更新的内容基本跟团队协作相关。除Synced block外基本都没有对PKM这块做增强；依然没有整合Diagram。由这些更新内容可以看出来官方团队对其的定位更偏向一个团队协作的工具。 Database很难实现复杂的查询关系 Database是Notion是其核心并具有特色的功能。只需要简单的点击就可以对数据进行过滤、分组和统计。这个功能确实很有用，但是在应用到复杂的场景上，总会有这样那样的限制。而且呈现的视图也基本是固定的几个模板。 虽然Notion支持文档的双向引用，但是引用仅仅作为一个普通属性显示在文档上，并且无法做任何的自定义。这样引用的可读性基本为0。类似这种信息应该有一个单独的试图并做优化，而不应该这样统一处理。 文档编写能力比较弱 对于Notion编辑器本身编辑的能力比较弱。而且偏离标准Markdown，譬如可以拖动Block，在一行内嵌多个Block，在导出到其他软件时必定会丢失该信息。不支持StarUML、Mermaid等Code-Based diagram。不过公平的说，Notion编辑器的Embed支持确实多，但是嵌入的质量不好评价。而且对于这种嵌入，也不太具有可移植性，用起来也是小心翼翼。 无法离线 这个恐怕是许多人诟病的点。虽然官方一直说在改进中，但是由于其实现机制，我对后面离线笔记的功能存疑。从程序的角度去考虑，就算出来了也有可能会有功能残缺。假如离线后不能用Database，那离线的意义在哪？而且对于Notion本身有分享功能、并且服务器在海外的网站，在国内无法访问也是迟早的事情。届时如果只有一个残缺的离线模式，想想也觉得痛苦。 内容安全性 这也是许多人诟病的一点。官方明确表态不会支持端到端的加密，文档内容会以明文保存在服务器。就算我们忽略掉内部员工、AWS可以直接访问文档内容的风险。也很难避免以后出现漏洞导致文档被错误分享到公网。按照目前的观察，Notion的分享和内部文档并没有物理隔离，公网有可能会访问到私有的内容。其实对于端到端加密实现起来也不困难，大部分的需求也只是存文本的加密。不知道为什么官方一直在忽略这个需求。 总结 虽然说了Notion这么多的问题，但这些仅仅是它作为PKM时的一些我认为的缺陷。一方面，Notion在处理大量同质的内容管理和多人协作上确实有它的优势。譬如，我想做一个简单CRM、HumanResources的管理，确实相当好用。又例如作为的一个简易的GTD、敏捷开发工具+Wiki、OKR追踪等，基本能满足中小型团队的需求。另一方面，如果要作为自己的PKM数据使用，I think,I will pass。

这几年推进光进铜推，实际上现在家庭的固话都是VoIP的。家里的光猫被封印在弱电箱，电话线拉不出来，固话就一直荒废了，趁着这两天有点时间，折腾了一下想尝试将固话用起来。最终成功实现了，自动外呼、IVR菜单、呼叫转移等功能。不得不说，Asterisk的确很强大，很多PBX系统都是在这个基础上做起来的。不过似乎局端的设备都Asterisk的认证支持有点问题，过一段时间就会掉线，所以目前是打住了。先将步骤和碰到的问题总结下来吧，方便后续其他同学折腾。 首先光猫要获得超级管理员权限，然后设置一个新的Vlan，Vlan ID用46，记得业务类型选择其他，不要选择语音。选择语音之后就不能用桥接类型，导致接口本身获得IP而不是对应连接的设备获得IP。 桥接配置后需要获得SIP的鉴权信息。我的光猫型号是HN8145V，可以将配置备份导出之后，用ctce_cfg.exe解密，然后再用这个工具huawei-win解密鉴权的$2加密内容。 在获得鉴权和网络接通以后，可以在Win下用MicroSIP测试一下能不能直接拨号，具体的参数填写请参照这个截图： 测试的时候必须注意SIP对应的网络信息和接口是独立的内网网段，所以必须收到设置路由，包括SIP服务器、SIP代理、DNS服务器等相关的地址。这个也是我觉得比较麻烦而且不靠谱的地方，因为你不知道SIP代理、DNS地址什么时候会变。而且你不知道中间过程中会不会涉及到其他地址。所以如果想长期搞的同学还是建议单独弄个设备，默认网关走SIP的内网，这样设备就会上不了网，但是会省却很多麻烦。 如果测试拨号过程中出现能呼叫、接听。但是接听之后，没法说话或者其他情况。建议还是检查一下网络和Asterisk的NAT设置。我这里就卡了一段时间，出现了能听，但是不能说的情况。主要是由于说和听分别由两条单工的RTP负责的。其中一个方向的RTP网络出现了问题，就会导致这种情况。 MicroSIP拨号成功后，就可以配置Asterisk服务器，具体可以参考这篇文章。这个配置还是挺好懂的，就是配了两个内网SIP用户和一个外线。 7.Astersik关于IVR菜单，可以参考篇文章。自动外呼的话，可以参考这篇。这两个我觉得挺有意思的，前者可以做一个很酷家庭语音菜单网关+留言信箱。后者可以结合家里的设备做报警外呼。 参考： https://wiki.asterisk.org/wiki/display/AST/Creating+a+Simple+IVR+Menu https://www.voip-info.org/asterisk-auto-dial-out/ http://zhmail.com/2016/09/24/configuring-epon-e8-c-gateway-to-access-ctc-voip-network/ http://lsjtt.asuscomm.com:88/?post=1099

不知道什么原因，最近家里的宽带居然能双拨叠加带宽了，并且两次拨号都能拿到公网IP。考虑到不要就是浪费的原则，在OpenWRT配好了双WAN负载均衡后，就剩下双公网IP没有处理。 之前一直用QNAP的DDNS，比较遗憾的是，我在QNAP插件里面没有找到双IP注册的方式。并且考虑到QNAP自身拿wan口的IP也不容易，所以就想在路由上打主意。 刚开始确实找到DNSPOD在OpenWRT的DDNS插件，安装以后发现依旧是不支持多WAN口的。简单测试了一下，DNSPod本身的DDNS是支持多IP的（免费的解析好像支持两个IP，刚好）。还好插件本身是开源的，改起来还算简单。 先改一下插件的页面，将interface改成列表形式，打开文件:/usr/lib/lua/luci/model/cbi/tencentddns.lua，将interface改成DynamicList，删掉第一个iface:value，增加你自己的wan口。注意保留internet，这个是用于请求公网来获取IP地址的。 然后修改：/usr/sbin/tencentddns，改的内容比较多，可以直接从这个gist上面复制，或者从这里下载。 最后不得不说，bash的语法依然像一坨糊糊，而它的子集ash，更是糊中之王。真的是为难了那些做openwrt插件的朋友。本来这个修改预计用1个小时左右，没想花了3天，前后总共用了3个小时左右。反正社区都有强大的luci，为什么不用lua做一个默认的shell呢？而且lua虚拟机本身占用也极低，在嵌入式设备也不用担心。 PS：国内托管WP无法直接嵌入gist，而国内gitee，coding.net根本无法发布公开的gist，原因大家都懂。国内目前能自由对外发布言论的渠道基本都被堵死。博客托管、评论系统几乎都要接受备案和审查，否者一律不能对公众发布。就连gitee-gist这种也不能幸免。我能理解为什么这么做，却很难从心里认同这件事儿。

离开105已经有一个月，没想到时间会过得这么快，明天就是我在新项目组第一次参加的三方。每次去到一个新的项目组，都需要一段时间去熟悉各种人/事/物。这且这次还是只有我自己一个，基本没有熟悉的人，估计要花不少精力。幸亏项目组也属于刚扩张阶段，大部分同学都是新招进来的，这对我来说应该是个好事吧。 这端时间接触了很多新的东西：Perforce，UE4，端游的开发；也用回了熟悉的Python，还有服务端引擎。老实说，这一个月的进度远比应该要的进度慢，总觉得自己不太专心。直到B组解散以后我才知道自己不专心的原因是什么。虽然人已经过来这边，但对原有项目组依然没有“了结”，一直再跟大家做各种的八卦，“缅怀”这两年的事情。直到听到解散的消息后，自己突然有了一种释然的感觉。应该要继续往前走了，要提醒自己为什么要转过来新的项目组，有些东西该止则止吧。 另外，之前注册的域名也备我抢回来了，估计菠菜觉得没什么价值了。我打算用来搭个简单的英文站，锻炼一下自己的英文写作技巧。在这里SEO一波吧：https://shaneyao.com

My first blog pages This is my first blog pages base on github pages and using my custom domain.I had been told about how github pages can be used for blogging long times ago(maybe 4 or 5 years?), but I nerver try this seriously. Since now I got two domains for my own, I decided one domain for github pages blog using english(this site) to partice my english writting.Another domain for my chinese blogging....

认真的看完这个DEMO两次，结合当前自己的状态，感触很深。PS：游戏终于能进入高分辨率时代（伪）。PSS：为什么两个总监都这么年轻啊？

还记得在大学城读书时，和同学一起去大排档吃潮汕菜。那种对我固有味觉的冲击感到现在依然深刻。甚至连那家大排档的名字叫”学友大排档”，我都依然还记得（也有可能是因为它的名字跟张学友比较像？哈哈。）。我对当时好几道菜都印象深刻，尤其是有一道甜品“反沙芋头”。 在前段时间刚好是芋头的季节，就买了几次芋头尝试制作。在经历过一两次失败后，后面基本没出什么意外了。B站上有不少教制作这道菜的教程，如果想看实操的话，可以点这里。操作上的东西就不赘述了，可以去看视频。这里主要想补充一下很多视频都没说明白的点。 先说重点：这道菜的成败关键在于含水量。反沙的形成原因，我们初中化学基本都学过，其实就是：糖的过饱和溶液在温度和含水量变化后析出的晶体 首先是材料芋头的挑选含水量低，粉口的芋头。广西荔浦芋为上选，含水量低，够粉，而且芋头的香味较浓。如果没有的话，越南芋头也可以，关键要够粉，香味对成菜最多只能作为点缀。如果芋头不够粉，则含水量较高，一则影响成菜口感，二则影响反沙形成。 其次炸芋头的主要作用是收干芋头的水分。前面必须用慢火炸干炸到哐当响，后面30秒猛火逼出油脂。**芋头要尽量放凉才用，这样后面加入炒沙时，才能迅速降低糖浆温度，快速结晶。**这点也是很多视频教程里面没有提到的。 接着是煮糖浆，水不用太多，因为我们主要的目的是糖的过饱和溶液，水太多，还要费时间蒸发水分，提高浓度。如果有喜欢下香葱的同学，建议将香葱炒干后再加入，避免关火后渗出水分。泡泡的大小是判断糖浆浓度的标准，这点看视频基本就能掌握。 最后是炒沙，在浓度足够后关火。其实这时候可以根据煮糖浆容器的厚度适当延迟加入芋头的时机。因为容器越厚，温度降低越慢，在糖没开始结晶的时候，翻炒几乎没有意义，过度翻炒还会弄烂一些芋头。当然加芋头进去的时候还是要简单翻炒一下，让糖浆分布均匀。随着温度降低，糖浆开始重新结晶时（糖浆会变粘稠，翻动会变困难），必须加快翻炒速度，让糖浆在结晶中混入空气，这样才能形成完美的反沙。完成结晶后，就可以出锅。如果这时候翻动不及时，就会变成拔丝芋头或者糖脆芋头了（我第一次就是这样失败的T_T）。 至此，技术总结完毕。

时隔两年，重新注册了新的域名，开始了新的写作计划。这次再开博客，会有更大想法。先埋藏在脑子里，一步一步的实现吧。 可惜了之前的域名:shaneyao.com，在搜索引擎还是有一定的权重的，以至于停止续费后，马上被菠菜盯上，网站变成了澳门顶级肚肠。也罢，换了这个域名也算凑合，还是先关注内容吧。 PS：现在搭建网站可真容易，从注册域名主机，到搭建完成，总共2个小时不到，而且还是配置好SSL和HTTP2的情况下。

今晚在整理以前的笔记，发现一篇关于cocos2dx renderer的设计摘录。cocos2dx可以说是我客户端之路的启蒙引擎，对我有很大的启发，也跟随着我经历过一段神奇的工作经历。好奇心驱使下，去搜了一下目前的状况。发现2018年基本已经停止更新，最新的版本也停留在v4.0(2019年)。后来的替代者是cocos-engine。简单的浏览了一下文档，虽然增加了不少新的特性，绑定语言也变成了TS，从代码树来看似乎也继承了cocos2dx部分代码。但是整体的功能和设计不要说跟双U比，就算跟目前的后起之秀GODOT也差了不少，论坛也比较冷清。 这不禁使我思考，为什么当时如日中天的coco，为什么后来会掉队呢？ 崛起 cocos2dx其实是从coco2d的’翻译’过来的（我记得后面甚至原作者也跳到cocos2d）。coco2d是一个基于ios objc的2D引擎，一开始定位就是做2D小游戏的。在这样的背景下，再加上钓鱼达人在手游的爆火，作为幕后功臣的cocos2dx自然得到更多人的关注，而当时正处于手游崛起时代，国内（国外）游戏引擎近乎空白。cocos2dx自然顺利成章的’补位’。 转折 对于cocos2d-x v2.2之前的历史我所知不多，但对于v2.2以后甚至v3.0的版本，可以说这个引擎的巅峰，时间大概是2012-2015年。伴随着各大传统厂商入局手游，市场迅速扩大。cocos2d-x可以当时游戏研发的唯一选择，当时的触控科技可以说是当红炸子鸡。触控当时也看到移动设备的性能不断攀升，推出了重构了渲染层、’支持’3D的v3版本。在我看来，正是这个风向的转变，让cocos2d-x从第一梯队掉队。我认为主要原因： 兼容性。V3当时的定位是V2的迭代，迭代了渲染队列和增加能显示3D的节点Node3D（如果我没记错的话？）这就导致花了大量时间的V3实际只是一个能显示3D模型的准2.5D引擎。从现在我个人的角度来看，如果要做3D的话，原有的引擎API根本不适合，单说场景管理这块就已经很头疼。另外3D引擎的工作流需要有很强的定义和整合能力，当时cocos2d-x也是一个渲染引擎，根本达不到这样的高度。与其从V2兼容迭代，不如另开炉灶，做一个领先时代的新的产品。事实上触控后面也开了Cocos Creator，UE3->UE4也是完全重写（虽然用了不少UE3的代码）。 稳定性。对当时cocos ui 编辑器的稳定性印象深刻。每天都会crash不少次，还会有一些性能问题。即便是后面的版本也基本没有太多改善。对于inhouse的工具，可以忍；作为一个产品几乎无法接受。 技术滞后性。cocos2dx很长一段时间都是以一个单独的渲染引擎+UI编辑器存在。直到后面Unity出来，才发现可以将所有东西整合在一起作为一个编辑器。这时候Unity已经以技术领先态势抢占市场份额。回头Unity在3D引擎的基础上开发出2D引擎的内容把cocos2d-x仅有的2D市场也吃掉。 总结 其实，无论你之前处于什么样的领导地位，只要一次没跟上时代的步伐、看清楚形势就会被时代抛弃。无论是对于个人或公司，触控如是，诺基亚如是。反观同样是有自己产品和引擎的E宝，在Unity已经抢占手游市场的大半江山，依然能通过开源占领市场，并利用自己技术优势和不断迭代，重夺引擎市场桂冠。可惜，触控始终不是Epic，时代总要翻篇。