中秋节

中秋节快到了，但是你知道中秋节是几号吗？不能查日历，凭记忆说。电视新闻、周围的人、手机App，多少会提到中秋节吧，但是你能记得中秋节的日期吗？

我不知道，我是真的没听说中秋节，要不是看到上班族拿个中秋礼盒，我都不知道中秋节要来了。在便利店买东西时问店员中秋节几号，人家小伙也不知道，他跟我说“新年快乐”。

中秋节几号估计那些没什么生活压力的人才知道，没什么压力才能安心过节嘛。我觉得中秋节就别讲“中秋节快乐”了，介绍点赚钱的事情，有钱赚才快乐啊。

Notification(s)

英语里的个数表达真是太麻烦了，一个的时候要用单数形式，多个的时候要用复数形式，一般要加个“s”。去年还是前年看到一个英文网页，里头的代码涉及到数量时候这么写 xxx(s)，不管单数复数都通吃，看来老外也嫌麻烦。

我一看，感觉这家伙真是个天才啊，不用写代码直接提升性能。如果区分显示单数和复数的话，代码就要处理数量是否大于 1，这就有性能损失，虽然这丢丢性能损失人类根本感知不到，但是程序员的执念有时候就在这些不起眼的地方。这哥们不但解决了性能问题，还提升了开发效率。

一开始我也照搬，可是搬着搬着就发现问题，发现没，xxx(s) 不耐看，多看几次就是影响“市容市貌”的存在。后来就不搞了，还是区分一下单复数，谁要是说这样影响性能，我告诉他：这点性能影响，就相当于你放个屁对全球变暖的影响。

抽奖

本想学着互联网公司那样搞个“新人抽奖，最高可得 300 元”，我大方一点，不搞 300，也不搞 3000，直接给你一个亿吧，新用户注册弹个对话框这么写：“新人抽奖，最高得一亿”。

然后，抽到 0.00-0.09 概率搞到 99.99%，剩下的可能性放到 0.10-0.90，更高就没了。想抽一个亿？做梦去吧，抽到一块钱算我输。

这套路成本极低还不用承担什么，真是性价比极高的玩法啊。为了真实一点，搞点小号抽到 168、888、8888 什么的，也不折腾什么概率了，直接在后台制造一些数据，简单、大方又安全，反正左手倒右手，不损失什么。

但是问题来了，0.1 元我怎么付给人家呢，没连支付服务我连 0.01 元都没法付。于是，算了，搞这么个界面就行了吧。

有微实例吗？

前不久我在微软云的 12 个月试用到期，免费的服务器就没了，我的加密通讯工具也就吃灰，常用的网站和服务也连不了。现在没有人工智能的辅助效率真是差太多了，没服务器还是不行。

而各大云服务商的服务器里，最便宜的（折合人民币大概 30 块一个月）机器跑我的通讯服务都搓搓有余，CPU 占用顶多就 10%，买最便宜的都浪费了。

除了网络流量之外没什么要求，CPU 几乎没要求，内存没要求，存储没要求，不用显卡，有没有面向我这种应用的微实例啊。

不赚钱

说好的赚钱的，但是搞来搞去还是搞了不赚钱的事。

基于那个云，计划：搞个账号系统，把部分内容移到注册用户区；把内容更新放到后端；评论系统可以自己实现；三天可见等奇奇怪怪的功能给实现了。

现在没支付功能，就算接入了支付估计都不赚钱。我站的规模就和地摊差不多，地摊上云，高端点说叫：基于微服务架构的云上地摊。从赚钱层面来说那是各种不确定，别说第三方支付 API 了，连搞个营业执照的理由都没有。

账号功能草稿

虚假同感偏差

上次讲那个后端功能服务化的云，他们家把最常用的功能都抽象成了独立服务并且提供（客户端）SDK 和 REST API，App 通过这些服务来开发一些功能，比如用身份验证服务和数据库搞个 App 账号登录和授权，这云看着不就是大家都在讲的“微服务”么。

不过我在他们家主页上没看到“Micro service”，在其 GitHub 页面上也只提到 2 次，我也觉得没必要多提，这么做不是应该的于么，还是说国内觉得微服务新鲜，默认都是一台服务器全包（LNMP + 后端代码）的那种。

有人觉得先进，有人起步就这么做；有人觉得咖啡很好，有人喝过一次再也不喝；有人觉得“突发”这标题很好，有人看到“突发”标题就拉黑（内容必然垃圾）。。。真是同感偏差无处不在啊。