俺的小程序名叫「微群日历」， 1 月 8 日正式开始开发，1 月 20 日提交审核，1 月 22 日被拒，再提，1 月 24 日通过审核正式上线。立即使用「微群日历」：
https://minapp.com/miniapp/1451/
上线三天，并没有什么太多推广。目前接近 500 位用户使用，其中 50 位左右身边朋友，其余多半是知晓程序的小程序商店过来的，比我预期的好不少。身在海外的我，踩过很多第一次踩的坑。好记性不如烂笔头，我把这些经历写下来，也希望能帮助到其他在海外想要做小程序的小伙伴。我很清晰的记得 2 年前，遇到过一个六七十岁白发苍苍的老美程序员。他虽然退休了，他说今天是他的生日，收到了一个很特别的礼物Punch Card。看起来是不是像答题卡？这就是他们那个年代编程用的，拿着一厚沓这个纸给电脑读，运行程序。老大爷拿着问我说你知道上面写的啥么？我心想这是什么鬼，然后他得意地说：「这上面写着 Happy Birthday，我一眼就认出来了，哼哼。」听到这话，我心里默默地骂了一句。不是我觉得自己是新青年而看轻老大爷，而是我觉得很悲哀，因为 20 年后的我，大概也会这样。一种被时代淘汰的既视感扑面而来。多年以后，当伟哥和孙子在葡萄架下乘凉的时候，他一定会想起无数个吭哧吭哧搬砖的那个遥远的冬季的夜晚。技术的潮流跟时尚异曲同工，一波一波，不断改变。然而，这其中又有些不一样，复古的时尚偶尔会还魂，但古老的技术基本会死硬在了沙滩上。微信小程序的开发过程让开发者很爽。依赖完全原生的体验，小程序的开发效率提高了不少。
有关于小程序的开发优势，网上很多文章都说了，我就附和几句：
开发快。小程序开放内测没几天，就有破解的开发工具在 GitHub 上放出来，也有许多人开源自己做的小程序。一个可能你要雇 3 个人开发半年的东西，在小程序平台上，2 礼拜就出来了。真是快！加载快。微信为小程序的代码增加了 1MB 的体积上限，那是什么概念？Google 主页打开，啥也不做，就是 527KB 的下载。我的小程序还一共不到 300KB 呢，比 Google 主页还小。所以微信打开一个小程序，就跟打开 Google 一样简单，一样快。而且事实证明，1MB 已经能做很多事情了！体验好。很多人拿着 HTML5 冒充小程序，很多人不明白，其实小程序 UI 就是原生 app，不是 HTML5，更不是拿 HTML5 来做得像原生的。HTML5 和 native app 之争由来已久，诸多试图把 HTML5 做得像原生应用的体验其实都差，比如Cordova，Ionic。这些做的像 native app 的 HTML5 小众范围内使用还行，给 mass consumer 的，总是会有卡顿的情况。后来 Facebook 出了 React 和 React Native，为 HTML5 带来一线曙光，但它跟小程序原理其实也很类似。React Native 也有些跟小程序类似理念的 startup 出来，只是东家 Facebook 又有技术又有流量却不去做这个，这里就不得不佩服国人的速度。再过两年以后，绝大部分人都不会再开发底层 app，基本都会往类 React Native 走，因为体验上其实并没有这么多差别。再过五年，那时候 AI 的 converstaion based application 应该会占主导地位。除了游戏等重度依赖硬件的需求，用户不再需要手机完成很多 task 了。在这种情况下，你更不需要 app，就像现在的 Alexa Skills。就像现在，谁还在写 MFC？估计很多人都没听过……那么有人说微信有诸多限制，很封闭。的确是有很多限制，比如游戏不能做，否则做个麻将棋牌类，往群里一扔，分分钟秒杀皮皮麻将啊。还有代码不能超 1 MB，不能外链跳转，不能分享朋友圈，小程序入口只有群分享、搜索只能搜全名、只能使用摄像头扫描二维码……看到这儿，是不是觉得限制太大了呢？但是呢，大家退一步看：这些是人为加的限制。微信现在的有着巨大优势敢制定规则，要是他发现小程序没有达到想要的效果，会不会某些地方能稍微开放一些？说个简单的吧，比如带参数二维码，最开始是 1 万个，现在上调至每天 10 万个。微信也是在摸着石头过河。并且在这个过程中不断调整游戏的平衡。这是给小创业者的机会。你没有那么快被吃掉。因为大鱼们也没有摸到该怎么玩儿。
不少按自己公司主营业务原始的照搬过来，还有罗胖这种利益冲突太大直接不玩了的。
大公司玩儿不动了，各位 startup 还不赶紧八仙过海各显神通。
微信玩儿的是阳谋，摆明了就是想补他欠缺的地方，比如群协作，比如线下 线上，不想让你来微信打发时间（玩游戏）。这让我想起了最近亚马逊停掉免费 review 的项目。以前亚马逊正儿八经的允许有给样品然后 review 的项目，后来据说是中国卖家太多，国人出海卖货也不知道怎么办，简简单单就是花钱冲 review。亚马逊停掉这个 program，就是想让大家回归到做好产品的初心。你看得出张小龙是有初心的人，希望大家去做 make the world a better place 的事情，而不是简简单单抓住用户注意力不放。如果我所做的，能让世界变得美好一点点，那我也就满足了。学习小程序，已经有不少教程了。不过网上资料有些多，看着就乱了，在此推荐几个放出来讲讲，就不再多罗嗦了。
官方教程非常不错，我有很多不明白的东西是在这上面看的。入门教程可以多看几次整明白了，API 和组件等到用的时候再看吧； 首页上的小程序示例源代码可以下载下来，很不错的参考； WeUI 样式是微信设计团队自己推出的设计样式，非常有用，很多时候不知道该怎么设计，或者自己布局很丑，我都会先看这上面的； 还有快速开发样板，很轻量级的样板，帮你快速上手。
关于框架，有些码工们喜欢一上来找 framework，现在也有好几个出来了，但我强烈建议是先不使用框架进行开发。一来，这些框架还不算成熟，用开源的最怕就是选错 dependency。二来，1 MB 的上限一不注意很容易就到了，交给不可控的 framework 还是不放心。有人还支持了用 NPM 的库，那就更要小心了。一个平时网页常用的 lodash 都要 500k，NPM 库很容易一下子超标。刚开始的时候，还是先手写吧。熟悉并进阶之后，你就可以自行决定了。做完这几点，可以开工捣鼓小程序了。我开发小程序的时候，基本上就是用这些。首先一个问题是为什么要在海外做小程序？其实没啥别的，就是想做个自己和周围朋友能用的。出了国的才知道，老美的各种东西，比起国内便捷服务遍地开花，美国差得真是太远了！比如我做的这个微群日历小程序，一开始就是想让聚会大家约时间更方便，还能记录到底带什么菜，省的每次去翻记录。另外我们每周会组织沙龙活动，每次都是通过公众号发布，让大家在 meetup 报名，但是每次去点的人总不多，过几天大家忘了有什么活动又会来问。还有比如约开会时间也要磨合半天，一般都用 Doodle，但是使用体验很差。所以我才做了这个「微群日历」小程序，能帮助大家提升协作的 productivity。好了，说说干货。在开始之前一定要做好心理准备，因为有些坑，对海外党太难绕过了。
某种意义上说，我们基本就是外星人。
基本要求
国内要有公司，各种证件要全。国内得有人帮你做认证，需要接电话什么的。海外的服务器虽然不需要备案，但中国政府规定，备案过的域名必须指向具有相应备案的服务器，并且会定期扫描。发现不对，可能会撤销你的备案。我在网上搜攻略，不少人说只要一个二级域名挂在国内就可以了。这点我还特地问过阿里云的客服，答复是可以的，二级域名挂在国内并且有不少流量就行。我的做法还要简单一点，用了全局路由管理工具，根据访问地域不同指向不同服务器。这点我后面还会提到。解决了这些，你就可以开始开发了。但是如果你决定做一些特殊类目，那么你还得赶紧开始申请特殊资质。这些特殊类目包括教育、医疗、金融、出行、富媒体等方面。搞之前，还是要仔细了解清楚！
微信小程序所建立的连接，都要求使用 HTTPS 协议。
关于 SSL 证书，以前我也没弄过，原本想直接买个证书了事吧，一年花个几百刀。
不过后来一想，这证书每年都还要 renew 也挺麻烦，而且不少公司都因为证书过期出过大事情。于是找了一圈，发现了一个好东西：Let's Encrypt。Let's Encrypt 是个非盈利组织，由他们签发的证书有两个最大特点：
免费证书！seriously！完全免费的证书啊； 自动更新！他们签发的证书的有效期只有三个月，因为 Let's Encrypt 的理念是证书应该有自动 renew 机制。
我在美国用的 Azure Webapp，也有好心人做了 Let's Encrypt 的插件，配置证书也很轻松。上面提到需要国内服务器备案的事情。如果直接用国内服务器的话，海外访问速度会慢得离谱你随便打开一个小程序，加载都要很长时间。
怎么办？自然是在海外再开一个服务器啦！
如果用户来自东亚，我让他访问国内服务器；如果人在美国，则让他访问美国服务器。如果 ICP 扫描的时候，自然会扫到我国内的服务器，备案也就没有问题啦。这么做的后果是，你需要维护两台服务器，对于用户数较少的小 startup 而言，这样完全是徒增烦恼。一个做法是在国内直接代理到美国，这样最终还是访问的美国的服务器。当然后果是国内访问会巨慢，如果你不在乎国内用户的话倒也无所谓。不过在微信审核的时候，要确保他们加载什么没有问题。小心审核不过噢。还有一点，要注意证书问题。如果你跟我一样用 Let's Encrypt 的证书，申请的时候需要 DNS 指向当前机器的 IP，否则会失败。但是 Let's Encrypt 的机器肯定在国外，怎么办呢？很简单，我就先在 GTM disable 了美国的指向就行了。不过这里其实有个问题，就是多台机器共用证书。如果机器在附近也倒是罢了，直接 Nginx 做个反向代理。但是现在是跨国呢怎么办？一个做法是单独开一个证书服务器，把 Nginx 的 /.well-known 路径指向证书服务器。这样的坏处是这个证书服务器是你的一个 bottle neck。我在美国的服务器本来就有很多限制，所以我目前的做法比较偷懒，两边各自刷新证书。
这样做的后果是：过几个月中国那边的服务器的证书，可能没法自动 renew 了，得手动再做一次。
我对证书不是很了解，如果哪位比较精通，请跟我联系。我完全清楚功能页面的作用，估计以后搜索小程序，直达你的功能页面，而不是主页。不过现在完全是看不到用处在哪里。比如我的微群日历，有类似 Doodle 的功能。我第一次审核的时候填的日历，被审核人员指出应该是投票，第二次才顺利过关。这个说了大家都懂，只是你可能会忘记。这个坑绝大部分人都踩过，幸好我在群里问了老司机，才给了我一条明路。好了，一些海外常见的坑就差不多就这些了。在国内，这些也算是常规的东西，就是事先一定要做好调查，看看缺什么东西，尽早补上。虽然我标题说 16 天，其实前后加起来只有 12 天开发，但实际上因为还有上班时间，满打满算加起来可能 5-6 天工作时间吧。因为只有我一个人，所以也做包括产品设计，UX Design，Logo 设计等等。我个人对这个速度还是挺满意的，本来就是想练练手。一方面归结于有这么好的小程序一个平台，否则，做这个很容易就会花掉几个月时间。另一方面，当然事先还做过一些调研才动手，包括备案等等。这期间断断续续的，就没有仔细统计。这是最困难的。一般的 app、网站可能还好点。但是小程序有这样那样的限制，想好要做什么花了我很长时间。这也导致我错失一月九号第一波小程序的推广，那一次的 PR 起码值上千万啊，能迅速获得一批早期种子用户。原本想要写这样那样的酷炫的东西，加各种功能，但是每次都会不断的想怎样才能简化。我强烈认同简单的才是好用的，尽量不要有多余的东西的观点，所以除了日期选择器，其它很多设计我是直接参照 WeUI 的样式。或许你早就听到过这个话了，但是自己做的时候才能体会到。还是希望第一波出去，能尽量多的收集用户反馈，静静的看用户使用习惯，未来再往里加功能。上面提到 web hosting 我选择 Azure Webapp，一来是因为相对熟悉些，二来是因为 continuous deployment 做得比较好。基本上，我在 GitHub check in 了，Azure 这边就开始更新，自动部署，完全不用我来操心。也不需要我登陆服务器什么的，真是业界良心。国内的阿里云服务器就没有这么方便了，每次部署还挺麻烦的。从去年初开始接触 Node.js，感觉开发效率一下子提升了不少，可用的选择很多了，以至于有点太多无从选择。这次我就简单的用了 Express 和 Mongoose。MEAN stack 去掉了 Angular，变成了 MEN stack。我目前唯一用的 PaaS 就是有 MongoDB 接口支持的 Azure DocumentDB。这个简直太棒了，以前自己搭 MongoDB cluster 老费劲了，还得维护，DocumentDB 又没有好的 lib。它一开始推出的时候我就建议支持 Mongo 的protocal，这下总算是实现了！不过要注意一点的就是，每一个 collection 都是单独计费，小心点多了，就多开了几个 collection。比如 LOGO 就是自己弄的，基础的 Photoshop 技能还是需要学习一点。做了一个贱萌的 LOGO，还不错吧，自我感觉还挺良好的，哈哈哈。 | 
注册
登录
