我怎么这一年啥博客都没写呢？技术的没有，非技术的也是瞎聊。
以至于九月份的时候，小姐姐跑过来问我，孙悟空在取经路上有几个女朋友你二月份在朋友圈说好的「展开讲讲」呢？结论是当时就逼逼了一下，没空记下来，后来逼逼的内容忘了，就不想再写。其实那天是我 24 岁的生日，就是比较伤感自己老了，年龄大了。真不是矫情，习惯了「二十出头的小伙子」定位好几年，突然来个 24 岁，一下子适应不了。本来想着 2018 年会在生活上做一些新的尝试，可惜没有，主要原因是工作太忙，尤其是后半年开始新的项目后，从零到一的确很累，踩不完的坑，接不完的需求。以至于我还有 3 天年假都没有时间用掉，马上要过期了。预计是下个月去趟南京溜达溜达，去趟医院复查牙齿，年假应该花得完。
只要认真工作，一年很快就过去了。
这一年应该是过去几年里最平淡的一年，没什么新的变化，没太多新的想法，也没有什么喜悦和悲伤。在深刻地理解了「人类的悲观并不相通」后，我甚至对探索新的朋友都降低了兴趣。
事件背景：知乎问题《如何看待 Ant Design 圣诞节彩蛋事件？》
简单地说，这个拥有接近 40000 个 Star、被国内外前端同学广泛使用的 UI 库，在 9 月份的时候悄摸摸地在代码里加了一个功能：系统日期是 12 月 25 日时，所有这个库里的按钮组件都默认有一个积雪效果。而这个 feature 被设计成不写入产品文档、无控制开关、默认开启，于是圣诞节当天突然出现的「彩蛋」让很多前端工程师措手不及。有网友吐槽这种自动跳出来的彩蛋是「跳蛋」，或者更直接点认为这玩意是「地雷」。
拿这事出来讲主要是因为我也是这次被地雷波及到的「受害者」。25 日早上我正好有任务在客户那边驻场，有同事在群里说到测试环境出现了这个彩蛋，我一开始没多想，还悠闲地吃着早餐，完事抹了一把大油嘴，突然觉得哪里不对劲：测试环境有彩蛋，而这个彩蛋又是通过自身代码逻辑触发的，那我们在客户这边的线上环境也应该会出现。
当时就倒吸一口凉气。
2017 年第一天的时候我在朋友圈立了个小目标：今年不脱单。
完成得非常好。
另一个微小的愿望是创造价值，不管为自己还是为别人。这个也还行，虽然没做出什么很厉害的东西但总归是为其他人提供了些帮助。
春节时没有回家，一个人在公司的别墅里住了十天，顺带给公司的猫和狗铲屎。对于我这样的人来说能一个人安静待十天可以说是过年最佳实践了。回家所耗费的精力和时间，以及在家里产生的一连串非常难受的体验让我认定这事对我有害，我的家人们并不珍惜我对他们的善良、耐心和忍让，我对此毫无办法。为了不继续伤害自己，我必须扔掉一些东西，这和经历久了中国教育后需要在恰当的时机接受观念冲击洗一次脑一样，广泛地接受莫名其妙的恶意，想明白自己为谁而活，弄清楚怎么和世界相处，然后事情就非常简单了。
大约在两年前，我认真思考了一个问题，如果我哪天走在路上被醉驾的傻逼撞死了怎么办？
这个问题当然是无解的，错不在我，真要轮到我倒霉我毫无办法。在中国，尤其是北京上海深圳，社会治安非常好，走在路上被人故意伤害的几率极低，自己不去作死就行。更何况我这种喜欢宅家里又善于预测可能的安全风险的人，如果生命真的受到威胁，那大概率是发生了不可控意外。飞来横祸这种事无法预判无法躲避，完全看命，基于「事事有着落」原则，我必须要为这种低概率的坏事情做好准备。所以，两年前这样想了一通后，我认为我有必要提前写一份遗嘱，来安排一下我意外死亡后的事情。
昨天下午，我终于把酝酿了两年的遗嘱写好了，内容其实非常简单，告诉我的朋友和家人需要帮我做些什么事情。主要是两件事：把这个博客续上费多维持几年；在我常去的几个社交平台上发布我的死讯，让我的那些近的远的朋友们知道这件事，告个别。
遗嘱里没有提到钱，因为我现在没有什么财富和资产，不存在分钱的问题。唯一提了一点是我身上的意外保险，可以赔到点钱，受益人是我父母。但你懂的，那其实已经不重要了。
看 WWDC 2017 直播的时候，Keynote 上有一页讲 iOS 11 专门为中国用户新增了一些功能，那页只是提了一句很快就切走，但上面有一句让我眼前一亮：SMS fraud extension. 看起来是在 iOS 11 上开放短信过滤功能了？
坦率地讲，对我个人而言目前 iOS 的使用体验已经比较满意，但短信过滤的缺失是我最大的困扰，我经常被这几种短信烦到不行：
iOS 目前只能对特定号码开启「勿扰模式」，这样短信进来后就没有铃声和振动，只在短信图标上 +1 个未读。很显然这解决不了多大问题，一方面经常会有新的短信通道号码（以 106 开头的那些）过来，第一次肯定没法避免，另一方面像银行信用卡消费提醒、账单提醒这种有用的短信和营销短信多数是同一个号码发过来的，为了避免错过那些用得上的短信，你可能不会把此类号码设成勿扰。
聊一聊近日更新的 App Store 审核指南的几个重要变化。关于微信小程序，关于公众号打赏，都有了答案。
禁止 App 自己引导用户打开 App Store 给 App 评分，因为现在有系统 API 支持这一行为了，在 App 内就能直接完成 review。
Use the provided API to prompt users to review your app; this functionality allows customers to provide an App Store rating and review without the inconvenience of leaving your app, and we will disallow custom review prompts.
App 的名字长度限制从原来的 50 个字符缩短到 30 个字符，且名字不应该包含价格。App 的副标题更适合用来介绍 App，但副标题不应该有指向其他 App 的内容。
这个可能是出于打击关键词排名刷榜的考虑。
App 只能使用当前最新系统版本的 Public API，保持 App 的更新确保废弃的 API 被移除。
更严格了，以前没有对代码里 deprecated api 的使用作规定。这条更像是建议而非强制规定，因为不使用某些旧的 API 的话老系统可能无法正常运行 App 了。
2.5.1 Apps may only use public APIs and must run on the currently shipping OS. Learn more about public APIs. Keep your apps up-to-date and make sure you phase out any deprecated features, frameworks or technologies that will no longer be supported in future versions of an OS.
敲黑板，划重点了：
In-App Purchase 的规则里新加入了一句话，App 应该使用 IAP 购买的货币让用户给数字内容的提供者给小费。
这一句话结束了关于微信公众号打赏问题的争论。
群众：审核规则只说解锁功能，打赏不属于解锁功能，强制走 IAP 不合理。
Apple：嗯，有道理，那我现在加上了。
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may use in-app purchase currencies to enable customers to “tip” digital content providers in the app. Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
如果是使用商业模板创建的 App 或者是由自动生成服务生成的 App，会被拒绝。
4.2.6 Apps created from a commercialized template or app generation service will be rejected.
又要划重点了：
新加入了一条关于 App 内运行第三方程序的规则，看起来是官宣微信小程序的合规性。
有几个地方需要注意的：App 必须使用 WebKit 和 JavaScript Core 来运行第三方程序，那么就意味着只可能是 Web 程序，同时容器 App 不能把系统的原生接口暴露给第三方程序；第三方程序的开发者也必须是 Apple Developer。
`4.7 Third-Party Software
Apps may contain or run code provided by third party developers (e.g. HTML5-based games), as long as the code is not offered in a store or store-like interface, and provided that the software (1) is free or purchased using in-app purchase; (2) only uses capabilities available in a standard WebKit view; your app must use WebKit and JavaScript Core to run third party software and should not attempt to extend or expose native platform APIs to third party software; (3) is offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement; and (4) adheres to the terms of these App Review Guidelines (e.g. does not include objectionable content; uses IAP to unlock features and functionality). You must provide an index of third party software and metadata available in your app upon request.`
App 必须向用户说清楚申请了哪些权限（位置、联系人、日历等），以及用户不给予权限的情况下什么功能无法工作。
这条规定有可能解决大家经常骂的某些 App 不给权限就直接闪退的问题。
Your app description should let people know what types of access (e.g. location, contacts, calendar, etc.) are requested by your app, and what aspects of the app won’t work if the user doesn’t grant permission.
App 和 Extension（包括第三方键盘），不应该包含 Apple emoji.
没理解错的话，第三方键盘里不能直接输入系统的 emoji 表情了。我觉得这条略不合理，难道我想发表情时还必须得专门切换到系统的 emoji 键盘？
Apps and extensions, including third party keyboards and Sticker packs, may not include Apple emoji.
过去一年我在网上常逛的社区有：微博、Twitter、V2EX、知乎。V2EX 里互联网从业者居多，偏小众，而 Twitter 中文圈因为自带门槛，活跃度不高，偏私人，特点非常明显。微博和知乎则很杂。
我玩社区的目的有两个：一些话题带来的见识和新鲜感；它们是体验、观察人性的好地方。一个社区一旦受众变广，一定趋向于成为小社会，在社会里就必然能感受到人性。从我个人经验上说，人们在网络上的公开言行要么带有目的，要么出于人性。网络环境越来越开放（只要不涉及敏感话题），受众越来越广，但现在能在网络上好好说话的人比例极低。这篇博客用来总结我过去几年所看所想，涉及以下几个话题：什么样的言论是不恰当的？为什么存在这么多不恰当发言？怎么理解和承受住网络暴力？什么是优质、正向的说话方式？
我对网络舆论的接触最早来自贴吧，刚开始和很多人一样，对于各种自己无法认同的发言很排斥，难以理解，为什么这样瞎说话的人也可以上网？作为活跃成员和管理者又不能正面怼，只能憋着，或者忍不住了上去试图讲两句道理。这种经历多了之后，我发现大多数「我无法认同」的言论都可以找到不复杂的原因解释：可能是信息不对称，比如我在这里已经待了3年而对方是一个新人很多信息和规矩不知道；可能是单纯的无聊，对方随便扯扯淡想吸引注意力；当然也有可能是我自己的问题，我没有跟上对方的思路，我的无知和短见蒙蔽了自己。我开始注意和总结这些现象，一方面能让自己积攒经验更容易了解到一个陌生人想传达的意图，另一方面是，如果不在逻辑上分析出原因让我知道问题不在我这里，我其实很难抵抗地住受众变广带来的压力。如果你有点粉丝，或者你管理过什么社区的话，你知道我在说什么，即使你在持续做正确的事，来自这个世界的恶意也是你难以想象的。后来不带社区，就只当一个普通的吃瓜群众到处逛，这样的思维习惯一直保留了下来，很庆幸培养了自己这样的习惯。即使现在到处都有撕逼、争吵、讽刺、打脸、反转，我看到后内心都毫无波动了。