二维码之所以能大面积快速普及，除了支付平台的大力推广外，更重要的是极低成本部署，只需要印一个二维码放在那或者找个屏幕显示个二维码就可以了。

央行对于支付方式的监管是极其严格的，有很多硬性规定，很多方法看起来很简单但未必合规，得研究一下相关规定才知道是否可行。

如果不想有任何动作的话完全可以用人脸识别等被动识别技术，但问题可能并不主要是因为其技术可靠性还达不到要求，很可能就是政策要求消费者必须做出动作以证明授权支付行为，如果政策真的是这样的，那么不做任何动作直接完成支付从根本上来讲就是不合规的。

当然，要是以后有比二维码更方便、更可靠的支付方式，也是很期待的。

@tsui
@dj9399

树莓派的付费解码器是 MPEG-2 和 VC-1，这两个目前来说不是主流媒体格式，之所以树莓派没有白送估计也是觉得没必要，因为只有很特殊需求的用户才需要这两种解码器。主流的 H.264/MPEG-4 树莓派硬解码器是免费的，但是官方论坛上说这个设计的时候预期最高只支持 1080p30fps 的情况，所以也比较鸡肋；现在在普及 H.265 和 AV1 （特别是你有一个 HDR 的电视的时候，这两个格式能剩下不少空间和性能），到时候没法硬解码只能软解码性能就差得更远了。

用了 j4105 的 CPU 之后觉得，Intel 的核显确实很不错，4K 分辨率，视频音频解码没有兼容问题，性能也特别好，热功耗才 10W，做个 NAS+家庭媒体中心非常合适（不过现在好像没货了，可以关注 Intel 下一代 10W 工控 CPU ）。

树莓派还有另外两个使用场景我忘了说：
轻服务器，问题在于数据存 SD 卡的话可靠性不好，SD 卡坏了数据就丢了，不存数据只跑程序的话还可以。
RetroPie，这个是极少数觉得树莓派不鸡肋的应用场景，前提是能找到兼容性特别好的手柄，以及愿意折腾。

个人总结来说，树莓派还是更适合教育场景或 GPIO 应用场景，我的反正吃灰了。

要是只是想写博客的话，Github Pages 或者 Github Issues 完全足够了。

不过写高质量的文章通常需要大量的时间，对于平时本来休息时间不够多的人来说是一种奢求。

我个人招聘通常是在简历上看不出来任何有用信息的时候才会去看看 Github 或者博客，所以建议多花些心思在简历和面试上，仅以求职为目的的话，比写博客 ROI 更高一些。

@bzj 搜索“老板椅 拍马屁”

看需求吧，我有个 3B，之前的情况是这样的：

一开始希望搞个掌机，用来玩 Minecraft，由于想跑收费版的 Minecraft （不是教育版），需要性能比较好的板子，3B+出之前，3B 当时来说性能算最好的了，于是折腾了一番，在最低画质下跑起来了 Minecraft，但是发现了几个问题：
1. 供电难以达到它的要求，官方说是需要 5V 的电源，一般的电源适配器和移动电源应该是可以用的，但是实际上 5V 是最低额定电压，我用普通的 5V 电源适配器通常因为线材损耗会出现闪电标志，用 5.2V 的就没问题，所以对移动电源的要求也比较高。
2. 尺寸小分辨率高的屏幕不好找，要么是尺寸较大的（比如官方的 7 吋），要么是分辨率很低的（ 480p ）。
3. 手柄不好配，按键映射、尺寸、连接稳定性达到天时地利人和才行。
最终放弃了，感觉玩 Switch 或手机版的（这两个都是基岩版）体验好得多，而且现在基岩版比 Java 版东西多一些。

然后想搞个 NAS，不过还是有问题：
1. 网络速度不行，我是想用来存电影，所以……不过第 4 代有可能解决这个问题。
2. 连接硬盘的方案不够高效，目前最简单的是 USB，但是 3B 是 USB2，我是想用来存电影，所以……不过第 4 代有可能解决这个问题。
最终放弃了，自己买了 j4105 的板子搭了个 OMV 的 NAS。

之后想用来当电视盒子，现在的电视和电视盒子的广告都太不像话了，还是有问题：
1. 解码效率很差，虽然可以买硬解码许可证，但是支持的解码格式有限，且种类少；软解吗看 720P 勉强，但现在电视大多是 1080P 起步，而且尺寸都比较大肉眼确实能看出较大差别的，所以……不过第 4 代有可能解决这个问题。
最终放弃了，直接把 NAS 用 HDMI 连上了电视，跑了 KODI （ Plex 一直都跑步起来）。

最后想，要不拿来写代码吧，写写 JS 啥的总可以吧，还是不尽人意：
1. 性能不够，功能比较多的 IDE 都比较吃性能，比如 IDEA 家的都是基于 Java 做的，再加上跑 Node 和 Chrome 内存完全不够 V8 塞牙缝的。
最终放弃了，老老实实用 MBP。

当然上面都是 3B 的情况，3B+可能好一点，4 据说改进不少可以考察一下。
不过最后我认真反思了一下，感觉我们日常想到的很多电子都有更合适的替代方案，不一定强行用树莓派来实现，实际上树莓派最突出的特点应该是 GPIO，可以用 Python、JS 之类的写硬件程序，所以可以做些机器人、简陋的智能家居什么的。

如果初创公司，氛围比较开放自由的话，可以和领导商量一下。

不过一般公司都是批量采购，不好为你单独采购一个型号。
为了效率和健康可以不和公司计较，只要公司允许使用私人设备，就可以放弃公司的，用自己的。

当然要小心叫 Trace 的 HR。

一定要提前看好哪些设施开放，哪些不开放，最好赶开放设施多的时候去。

可以提前下他们的 App，有地图，也有一些互动的功能（比如购买自己游玩的时候被自动拍下来的照片）。

前一天可以住在附近几个地铁站的 AirBnb （或者有钱住迪士尼的四星级和五星级也行），如果怕赶地铁人多可以提前买好日票，第一次刷才开始计时。
早晨开门前早点去，占个好位置，到点开放马上跑（对，一定要研究好路线死命跑）去领 FastPass，领 FP 是在各个项目的入口附近，地图上有。

提前规划好 FastPass，比如一开门马上跑去领热门项目的 FastPass，首推飞跃地平线和 Tron。
领完 FastPass 马上去不是最热门但也不错的项目直接排队进，比如加勒比海盗。
这样可以差不多保证一天不需要排多长时间的队就可以玩到尽可能多的项目。

网红大鸡腿有营业时间，可能也限量，最好尽早去排队买。

花车游街上午一次，下午一次，算好时间，入门拿的地图上有游街路线，提前去沿线找个好位置等着。

玩 Tron 需要寄存包，但是有 FP 没法寄存，所以可以在门口附近找个寄存点先寄存包，再去。

晚上的烟火表演，要提前看好有没有，平安夜有特殊节目。

里面有接饮用水的地方，可以带杯子去，零食不是完全不能带，我记得是必须是包装完好的品牌零食。

项目特别多，有游乐项目，也有表演，一天肯定不够。

请问社保方面是怎么处理的呢？

JavaEE 的时代有很多单实例大型系统，但是五年前就开始兴起的微服务让“大型系统”式的设计没那么必要了，每一个微服务只需要考虑自己专注的这一小块就可以了，所以，服务端用什么语言真的没啥大关系，而且选什么技术栈完全看各个技术栈在当前需求场景下的综合 ROI，不是说觉得某一门语言好就从头到脚全用这一门语言。

不过现在 The hype cycle 的峰值被舆论大幅拉升，以及很多人面向简历编程，Java 最终没落肯定不是因为自己不够好，而是因为无力逆转潮流。

树莓派官方已经发布 Buster 的 Raspbian 了。

公司机器上跑的东西不依赖机器环境，所以这么多年也没所谓用什么发行版，偶尔想用用新版的 OpenSSL 会编译一个。

个人还是在用 Arch ……

https://micro-frontends.org/
你要的前端微服务来了，这货在 GitHub Trending 上还挺靠前的。

系统架构思想其实是独立于和语言、技术栈、框架的，所以只要脑洞够大，没准一些“后端思想”也是可以直接在前端项目中使用的。

数据模型大部分为关系模型就用关系型数据库，数据模型大部分为文档型就用文档型数据库，现在大型业务都不是在一个服务上独立做的，涉及到事务也是平台级别的事务，所以按照数据操作的最小粒度来将不同模式的数据模型拆开，可能是比较好的方式。

像学校、老师、班级、学生这种模型就是典型的关系模型，最好使用关系型数据库；学生学习记录会包含学生、课程等当时的状态快照，所以适合使用文档型数据库；然后在平台级别学生和学生学习记录之间又是关系模型。

又比如正常的业务逻辑使用常用的关系型数据库，涉及到搜索的部分用特殊的数据库（数据存储、搜索引擎方案） Elasticsearch。有的公司是同一份数据同时存在多种数据库里，增加了保障一致性的复杂度，获得了最佳综合性能。

听说过一句话：“柠檬羡慕猕猴桃的甜，猕猴桃羡慕柠檬的酸。”

后端大多数也都是 CRUD 操作，很多人做了 5 年开发架构问题都是靠框架解决的，有机会且有能力解决高难技术问题的毕竟还是一小部分人。

个人觉得这个和自己的眼界与职业规划是有关系的，前端虽然不大会涉及到分布式、微服务等技术，但也有前端自己特有的同样看起来很“高端”的技术，比如 Webassembly、Web Components、Web Workers、Web GPU
、响应式布局、SPA、PWA 等等，而且前端工作的成果通常是肉眼可见，而且能直接对用户产生影响的，前端还会涉及到一部分 UE 的技能，比如 Contrast Ratio。

作为技术人员如果能了解到不同技术栈的知识，对于提升解决问题的能力是非常有帮助的，所以对后端好奇的话不如学一学后端知识，Native 开发、大数据、AI 都可以看一看。

自己学一学，花不了多长时间，然后就能对 Node.js 有一个大概的了解了。

前端用 JS，服务端 Node.js 用 JS，用 MongoDB 的话数据库也是用 JS，手机端可以用 React Native 是用 JS，PC 端可以用 Election 也是 JS。然后在创业公司爆炸增长的时代，业务量没那么大，每一个岗位雇佣专人成本较高，所以出现了“全栈”岗位，一人 JS 一门语言搞定所有岗位。

浏览器前端开发人员是一个非常大的群体，这个群体所有人都能熟练使用 JS，所以学习 Node.js 很快，Node.js 是靠着 JS 技术栈爆炸式增长起来的，TS 也是靠着 JS 增长的。

现代的前端开发都是使用各种复杂框架，很多都有独立的语言特性、文件结构，需要使用基于 Node.js 的大量工具进行编译和处理，即便不在后端技术使用 Node.js ，Node.js 已经是 Web 开发必不可少的工具平台了。

技术方面有一个“ The Hype Cycle ”的概念，不用盲从舆论，亲身了解和体验，在适当的地方使用最适合的技术栈就可以了。

国产应用流氓，所以中国市场上的所有安卓系统全部都自带杀后台功能，这个不是说系统本身就这样，而是被中国的应用生态逼出来的，以前用 Google 亲儿子的时候没有杀后台功能，所以用国产应用掉电特别严重，用全海外应用续航可以到一天半，装个淘宝啥的续航就只有 4 个小时了。

我用三星国行，有一个只有大陆行货特有的功能叫“智能管理器”，可以调节杀后台杀哪些应用、放过哪些应用，然后 Android P 如果各大厂商能把 AI 电源管理利用起来的话效果应该可以更好。

返回状态按照数据层分级，HTTP 层的状态用 HTTP 层状态码来表示，业务层的状态用业务状态码来表示，比如客户端 abc 参数传错了，这在 HTTP 层看来是“客户端错误”，所以应该返回 400 的 HTTP 状态吗，但同时在业务上来说是 abc 参数错误，所以同时返回 Body 应该用业务状态码或者错误信息告诉客户端究竟是哪里错了。

REST 风格是以资源为中心的，简化接口复杂度，将部分功能降级交由 HTTP 层来表示，对于资源找不到的情况，应该按照 HTTP 的 Not found 状态来表示，即 404 状态码。

REST 设计风格不是说客户端和服务器一方使用的，而是双方都使用的，客户端不管使用什么语言，都应该选用 REST 友好的请求框架来与服务器的 REST 接口通信，否则就不要使用 REST 风格了，不完全按照 REST 的思想来设计不能享受 REST 带来的好处，甚至可能会适得其反。

然后从系统可靠性上来看，不管服务端用的到底是不是 REST 设计风格，客户端都应该对所有 HTTP 层的异常做妥善处理，不是抛错误了事，而是应该处理所有错误情况；而在应用 REST 设计风格的时候，要习惯将 404、403、401 等作为“正常”状态来妥善处理，提升系统高可靠性以及用户友好程度。

最后建议整个开发团队科普一下 HTTP Status Code 标准： https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
表示“成功”的状态是整个 2 段，不只有 200。

没做过，但可以提供一个大概思路：

看一下 MacOS 的屏幕镜像开关支持什么语言开发，用相应的语言开发屏幕镜像开关的接口，然后用 N-API 之类的绑定 JS 接口，再用 Node.js 调用。

大学时候的老师说过一句话对我影响特别深：“一个技术人员的优秀不在于会多少语言、库、框架，在于是否可以解决问题。”
工作几年的感受是，用到的大学课程里学的知识基本上就只有计算机组成原理、计算机网络、离散数学、数据结构与算法、操作系统、C 语言（了解程序较底层原理，又不像汇编那样无人性），我的意思是说，大学的时候也学了几种高级编程语言以及一些框架和库，但工作后发现学校里学的很多都被新技术取代了。为什么前面几种基础课程反而用到一些了呢？个人认为那几种基础课程教的更多的是思想，而思想是跨语言、框架、库的，且永不会完全过时的。

所以大学里可以教框架，但是除非是定向培养的情况（如外包公司合作），建议侧重教框架思想，工程上出现了什么问题，以及框架是如何解决问题的，这样学生们掌握的就不是框架的用法了，而是解决问题的思想了。

网络协议的层位不是固定死的，而是相对相邻层的，一般说 HTTP 协议可以基于 TCP 协议运行，但如果有能力在 UDP 协议上模拟出一个 TCP 协议，那么这个模拟的 TCP 协议上理论上也是可以跑 HTTP 协议的。

用 UDP 跑 TCP 的案例已经出现过很多个了，比如科-学#上%网用的一些如 unʇdɔʞ(倒着看)，还有ʎɐɹՇꓥ(倒着看)等工具都比较成熟地利用了 UDP 协议。

QUIC 可能比 UDP 模拟 TCP 再跑 HTTP 的方式更加直接，以后的发展潜力也是挺高的。

QUIC 啥时候普及可以参考 HTTP2 的普及情况如何，估计得很多年。