曾经 Win7 按 Win 键-输入程序名称-回车启动，一气呵成。Win10 这破开始菜单+渣索引，根本没法正常操作。

从第一版 Win10 就这样了，不只是慢，有时根本弹不出。1809 好一些，1903 又恶化了。

感觉现在开始菜单只是个 UWP 应用，UWP 普遍加载都慢。
以前开始菜单是 Explorer 一部分，除非系统卡死否则不会有延迟。

@loading
记得十年前就有学生用这方法把校园卡集成到手机里，实现刷手机付款😂

@well666
NFC 主要就是因为利益链太复杂，所以推广很缓慢。你看银联云闪付现在也改搞二维码了；交通卡支付也是各手机厂商与一个一个城市的交通公司去谈的。

NFC 的标准化就是把几种不同技术揉在一起，之前的兼容性很差。
技术提供商有利益：专利技术的生命周期变短，可能面临提前淘汰；技术漏洞被发现概率增大。
设备制造商有利益：虚拟卡抢掉卡片收入；新技术导致设备提前更新，减少售后服务收入、加速淘汰老设备和技术；新设备重新招投标，有丢失项目风险。
发卡公司有利益：本来预存款有资金池收入，虚拟卡没了。
运营公司有利益：本来交通运营数据只有自己能统计，用虚拟卡之后手机厂商、软件商都能拿这些数据玩了。

@titanium98118
@dremy
普通扫码支付没有可比性。
大部分二维码支付场景都至少一方在线，就算你手机不联网，店家的收款端也会实时将数据发到服务器。见过好几次店家网络故障导致收银大排长龙。

但交通场景是双离线，交易时双方只会记账，不会回传和同步数据。NFC 双方之间有通讯，但二维码没有直接通讯，只能靠其他路径回写交易信息。

上面一群人真是，你们就不能搜索一下吗？
www.fmsh.com/f4debf45-f44a-a17d-dcad-8e82db4cc6f4/f04f9b7c-2555-3d9b-9cf7-eea27c3e22e2.shtml

“与传统的“网络在线扫码支付”不同的是，在国际国内移动支付乘坐地铁技术领域中，上海地铁首次实现了手机端和设备端在“无网络状态”下同样可以进出闸机的创新应用技术——“二维码双脱机 BLE 蓝牙回写”技术。技术核心实现了乘客扫描二维码过程中可不依赖公共网络，因此在响应时间和通行速度上不受互联网环境及限时的影响，更为迅捷高效。既不影响用户刷码体验，又防止二维码截屏转发出现盗刷、多扣款等支付消费安全风险。”

@dinjufen
菌和菌差别很大，人与人的状况也差别很大，大部分感染者没有症状，但如果有症状就及早就医治疗。
毕竟是第一种被发现可能致癌的病菌。

微信备份功能（以及其他大部分功能）就是垃圾。

官方备份渠道只有备份到电脑版。限制同一内网备份，却根本没技术准确判断同一内网：同一路由器的有线和无线判断非同一内网；存在 Hyper V 虚拟适配器也判断非同一内网。

导出的备份还 TM 是加密的。安卓还禁止调试，不 root 无法通过任何第三方工具导出备份。

不要说什么密码规则早就破解了，网上的各种规则都试了一遍，没有一个正确。

刚发现 Chip Pearson 去年去世了，他网站上有非常详细的教程。
www.cpearson.com/Excel/MainPage.aspx

@2oTp
VBA 基本上都现学现会现用的，VB 真的是超级简单易懂的语言。

VBA 处理简单问题真的太适合不过，无需另外安装任何软件，按 Alt+F11 编辑，按 F5 运行，基本的 debug 功能都有，与文档交互的效率很高，代码本身执行效率也不差。若干年来微软造了几个轮子试图替代它，然并卵。

当然作为一种古董语言 VBA 当然会有坑，比如 object 的 GC 时间复杂度是 O(n^2)，所以很难处理大量数据（几万对象冇问题）。

Word 是非专业通用文本编辑器中最好用的，功能很全。

但一旦你想做些专业的事情就会发现 Word 真是 bug 一大堆，样式、字体、表格、修订等等，经常莫名其妙就崩坏。

欧洲的 GDPR 就是最高按集团前一收入的 4%来罚款。然而即使这样也未必公平，比如工业企业利润率可能只有 10%左右，互联网企业利润率在 20%以上都正常（偶尔甚至能达到 50%以上），所以同样顶格罚 4%的震慑力是完全不同的。

自带输入法哪里丑哪里难用了？简直莫名其妙。
搜狗输入法光弹广告这一点就可以直接毙了。

如果是节点 2 到节点 3 呢？如果直接遍历相加的话是不是会重复计算？

这个直接去猪八戒就行了吧，这里太贵了😎

绑个自己的域名吧。
违规网址大概是上一个 MJJ 留下的。

如果实在没时间写好的代码，至少在关键地方写两句注释。

因为大部分公司都不够“大”——无论是公司本身的规模还是业务项目的规模、周期、要求。因为不够大，所以体现不出可重用、可维护、可扩展的好处。

比方说写一段糟糕的代码要 4 小时开发+4 小时测试。假如每次维护需要花 2 小时修改+测试+到处粘贴，那么项目生命周期中，开发+维护 12 次也就 32 小时。
你写一段“优美”的代码可能光是开发就要 12 小时，测试 debug 要 36 小时，每次维护半小时，那么维护 12 次就要 54 小时。
对公司来说 32<54，自然选糟糕的代码。

但如果同样功能在一个大项目中，糟糕代码由于复制的地方变多导致每次维护要 4 小时，优美代码每次维护变成 45 分钟，生命周期中维护次数变为 48 次，那么糟糕代码耗费 200 小时，优美代码耗费 84 小时。显然优美代码就有优势。

另外别忘了，即使是看似长期的产品（比如某电商网站），也有推倒重构的可能，所以烂代码适用的场合还是很多。
只有那些维护期限超长（比如 ERP 系统）、可用性要求极高（比如金融行业）、安全要求严格的项目，才能体现好代码的优势。然而这类系统现在似乎也通过降低客户期望来降低要求了。