双币卡是磁条卡，现在已经不让申请新卡了（老卡想用可以继续用）。国内的信用卡是单用户审核，你在一家银行只要激活了任何一张卡，那么所有非特殊卡都能任意申请。随便申请一张银联卡，激活后再要一张全币种卡就可以了，现在 VISA/MASTER 单通道全币种卡基本都是全免费的。

国内的信用卡卡种起始不重要，同一家银行的不同卡，基本上就实体卡长得不一样，后台是一摸一样的。信用卡是长期使用的，国内还是典型的老用户不如狗，所以各种申请优惠，要当成锦上添花的东西去看，不要作为比较指标。

下载文件时的消耗的网络流量，受网络协议、压缩协议、文件大小等多方面因素影响。

不公开的实践项目会很多，但是公开并且规模还足够到可以学习的案例项目，不可能有，别找了。

另一方面，DDD 不只是编程思想，它是涉及需求、交付、开发、测试等全方面的开发思想，如果不能在客户、产品、开发之间形成通用语言的话，那也是用不了的。你可以拿公司的非紧急项目给自己练手用，不要想用 DDD 单方面去解决公司的项目开发困境。

并不是不安全，而是做不了。可以把手机关机都能刷的那个卡人为是普通的公交卡 /门禁卡，把电子钱包看成写卡工具。卡在你手上，读卡的东西还在公交公司 /门禁那里，但是写卡工具控制在手机开发商那里。各种卡想接入手机钱包，都是要给手机开发商上贡的，而 Apple 索要的上贡量，是连二三线城市的公交公司都承受不起的。

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

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 数量这种单指标考核了。