锂电池满电亏电都特么损耗，容量小的锂电池，能撑到过保就很了不起了，过保了就只能当废物处理。现在这种电池情况，无限耳机都是一年期消耗品，哪怕它很贵。

3D 电影回归 2D ，Kinect 这类的体感游戏在 VR 游戏接棒之前就消失，Hololens 贵得要命还只提供给开发者。有这些前车之鉴在，别说办公领域，就是游戏领域和娱乐消费领域，VR/AR 离真正能用，还远着呢。

FCM 的机制就是推送消息拉起应用然后交给应用处理，应用可以不常驻后台，但必须能被后台唤醒和后台执行。Android 通知中心对接的是本地应用不是 FCM ,不要妄想 IOS 那样可以抛开应用直接对接推送服务的通知中心。

找个轻量级的 ERP ，或者整理好需求找外包做软件。虽然都不便宜，但是人数越来越多的情况下这钱得花。

@DinnyXu #4 那就没辙了。跳板机那个做不了的，因为 VPN 客户端不一定支持你让它当跳板，更别提还有深信服这种带监控的 VPN 。

单独弄一个电脑做 VPN 客户端即可，用得时候装，用完即卸载，或者干脆跟网吧一样上还原卡。也可以用虚拟机代替单独电脑，但有些 VPN 在虚拟机上可能没法装。

要是钱够的话，可以每个项目都配上一到几个电脑专门当 VPN 访问用。

这个跟之前那个互助是一样的，是商业行为，不是保险。但是保监会要是想禁止就有权限禁止，因为是不是保险是保监会说了算。不过这种小玩意金额不大，没闹大保监会也不没心思去管。可以试着向保监会举报一下，说不定就碰到那个热心肠的愣头青会管一下。

@ysc3839 #12
Android 的应用权限管理，也就是个应用权限管理，有那么点安全，但整体安全性是个屎。本主题讨论的是跨应用文件保护问题，这点上 Android 连它基于的 Linux 的用户文件隔离都没有，根本没法保护。而就算 Android 官方系统把应用沙盒特性给做好了，OEM 可以不上这个特性，各种国产 APP 有各种方式可以绕过这个特性，在 Android 这种非封闭生态下，安全性需要多方协作才能保证，光靠操作系统一方根本不可能保证。

第二段，说了那么多没说到点上。第一，UWP 可以不适配移动端，只适配桌面端的 UWP 多的很。第二，Win32 API 从来没有被砍，它的限制只是不能上架商店，以及不能使用 Win10 新增的相机、位置这些移动端才需要用的 API 。第三，UWP 的失败，主因是它能被自家的 Win32 应用或 Web 应用随意替代，换句话说，是因为 Windows 生态太开放。

虽然苹果在硬件指标上确实溢价高还扣，但是 6G 内存还狂杀后台，也真是不怕闪了舌头。

@ysc3839 #9 苹果的生态都是靠封闭来控制安全的，Windows 跟 Linux 系压根不可能用那种方式。纯 UWP win10 商店前车之鉴。而 Win10 mobile 前车之鉴也决定了微软短期内不会抛弃现有的 windows 生态去另行搞一份类似 macOS 的生态。

“谁编码谁负责”可不是让你这样搞的，结对编程或者相互代码评审才是保证代码风格的途径。你这样搞是 5 个独立的人在开发，不是 5 人团队在开发。

master 出的分支、dev 分支自身的修改、online 分支这几个来源，对于 dev 分支都是一样的合并来源（直接修改相当于合并本地 dve 分支到远程 dev 分支），所以你就别要想单纯靠 git 来区分这些来源了。

其实按照你们这种开发过程，dev 分支 跟 master 分支当中必有一个是没用的分支。

我能想到的一个方案是，给令牌设计一个特定的字段，比如授权时间。服务器通过 Redis 等缓存，设计一份全服务可用的“用户 ID—允许的最早授权时间”的键值对数据。 鉴权服务器（ auth.mycompany.work ）每次令牌发放，都以当前时间设置令牌的授权时间。 业务服务器（ nextcloud.mycompany.work ），每次令牌验证，额外验证令牌的授权时间是否大于缓存中获取的“允许的最早授权时间”。任意一个服务登出时，以当前时间更新缓存中的“允许的最早授权时间”。

@edis0n0 #5 这个就是 OAuth2 或者类似的过程。

这里面有两次重定向。

第一次重定向，访问 nextcloud.mycompany.work 发现没有登录，它给你重定向到 auth.mycompany.work 。重定向之后的过程就是本地浏览器根 auth.mycompany.work 的通信过程了，如果是标准的 OAuth2 , 每个来源网站的首次登录都会蹦出一个界面让用户同意授权，这里大概率会略去或者隐藏这个过程。

第二次重定向，当浏览器跟 auth.mycompany.work 完成认证授权过程之后，auth.mycompany.work 指示浏览器重定向回之前的 nextcloud.mycompany.work ，并附上 token 。然后，nextcloud.mycompany.work 再指示浏览器通过 LocalStorage 或者 Cookie 保存令牌。令牌保存之后，后面的过程就跟常规的令牌认证过程没区别了。

如果是标准的 OAuth2 且不使用简单模式，在两次重定向之间，会有一个授权代码换访问令牌的过程，不过单点登录过程可以不要这个步骤。



一退全退这个，光凭 OAuth2 就办不到了，上面有人说的“一个应用退出会通知其他已登录应用”的方案也不可行，因为令牌认证模式不是会话认证模式，服务器没法单方面登出。服务器需要借助一些其他手段，能够让令牌集中失效才行。

ISO9001 或 CMMI 规范，是要求文档记录全过程的，这过程就包含代码量，这些将作为项目开发成本估量的指标点。这只是其中一个指标，并且还是考核项目不是考核人的。

不管是对人还是对项目的考核，任何以固定公式计算的考核，就是这公式有上百个考核点，那都是不靠谱的。就更别说代码量、BUG 数量这种单指标考核了。

字符串可以用空字符串代替 NULL ，只要全局约定好即可。但是还是不如不区分 null 或 empty ，统一使用 StrUtil.isEmpty/isNotEmpty 来判断更好。因为有些数据库，比如 Oracle ，它本身是不区分 char/varchar 类型列的 null 和 空白的（这些列 column is null 跟 column = '' 总是返回相同结果）。null 字符串的显示，确实不好处理，但这是纯 UI 层次的问题，ORM 层不应该考虑。

非字符串类型，那就不用说了，如果没有默认值，那就必须提供 NULL 。

如果业务上应该有默认值，最好还是以默认值代替 NULL 。但是记住，这是业务逻辑的要求，不是性能的要求。现行数据库（ Mysql 除外），基本都不会因为 NULL 值影响性能。

利用 Redis 搞延时任务，要用 zset ,不能用 timeout 。具体的我就不说了，因为我也是看别人的，以关键词“分布式之延时任务方案解析”来自行搜索吧。

插电正常，不插电卡，应该跟 Windows 的电源管理有关。“更好的性能”模式这是 OEM 的功能，随着操作系统的升级随时都有可能失效，要开高性能模式你最好还是直接去 Windows 电源管理上面控制。此外，如果是老旧机器，随着散热系统的老化，CPU 频率会被限制的。

但是，即使接电源的情况下，横向情况下，i7 U ，不一定能打台式机的 i3 。如果再纵向比较的话，8 代 i7 U ，可能不如 11 代 i3 U 。Intel 的 U 系列 CPU ，是超级拉跨的。

TrafficMonitor 试了下，不太好用。这是个仪表盘，如果仅仅是用天气预报的时候，干扰性太大了。