背景 最近经常会有人找我问一些非常有趣，但是又非常玄学的问题。这类玄学问题我指的是正常情况下明明能工作，现在却不知为何无法工作的情况。 这些问题往往和非常多的难以预料的因素（例如环境）有关。例如：为什么我无法将一个文件签入到git？ 解决大部分玄学问题，往往需要我主动在他的电脑上进行大量操作、环境分析，才能知道到底是哪里对程序产生了影响。或往往需要我反复沟通数十条消息才能真正判断问题所在。而且这类问题，由于正常情况下是能工作的，所以非常难以通过Google和Stack Overflow解决。 后来我想，与其每次都花费大量时间帮别人解决问题，不如抽象出一套能够解决上述问题的通用方法，来让大部分人能够自行解决这些问题。 夹逼调试法由此诞生。 夹逼调试法 夹逼调试法，指的是通过两个方向共同限制作用，使得问题根源的可能范围集中在最小化的条件变化中。 夹逼调试法适用于解决： 平时或 …
How to set rules for an employee in a large company that uses outlook? As I work at Microsoft, I receive thousands of emails every day. Usually including: Advertisement and news. Daily updates. Topics about the project I'm working on. My crew working discussion Robots notification (like GitHub notification) Incident alerts. Oncall requests from other teams. Updates from my organization. Questions …
在过去的二十年间，我们目睹了中美关系的长足发展带来了在技术领域非常多元的交流。其中典型的代表，就是微软和苹果在中国的市场发展。李永乐老师的视频中曾经指出：两个国家在贸易的过程中，一定是对国家双方都有利益的。 在这样的思想的指导下，我们始终认为构建的应用，也应该是越来越“全球化”的。所谓全球化，指的也正是在应用能够全球布局，全球服务。而面向这种全球布局的应用，我们完全可以在已有的基础设施、服务和运维经验的基础上，来大幅度的降低我们的维护成本。因为我们始终只需要一份专业的运维团队来维持全球的数据和服务。 我们曾经在思考一个问题的时候，也随着技术的背景发展，我们思考“分布式”的方式也逐渐改变。其中，最典型的代表就是在思考CAP定理时，我们更多的考虑的是实现分区容忍性和可用性，而弱化最终一致性。这类使用场景，在例如Email、微信等通信App的构建上时非常典型。也就是说，我们可以考虑中美两个大型数 …
When we are using Azure DevOps to review PR, it's simple and easy to use. Usually, we only run tests and build tasks, like this: In my previous blog, I mentioned how to run test and generate code coverage for CI pipelines: Display code coverage information for .NET Core project using Azure DevOps. - Anduin Xue (aiursoft.com) -------------- JetBrains ReSharper and Rider are impressive C# grammar …
凡是涉及到事业单位的项目，涉及到知识产权外包的，通俗来说，就是自己写完就卖出去的代码，普遍软件的质量都相当差劲，漏洞百出，功能欠缺。开发商（乙方）在验收完成后，等付款方（甲方）完成验收，安装完成后，往往拿钱走人就去拓展下一个项目。这种低质量的软件严重影响企业的扩展和用户体验，甚至能够影响整个行业的健康度和。对于我们普通人的认知，就是非互联网企业的线上服务体验往往都很遭。 表面来看可能是因为构建软件的程序员水平较弱。但是如果它形成了一个现象，那么问题一定是在规则上。在于软件本身质量而引发的责任在多次承包后足够弱化，导致真正构建软件的人根本不在乎代码的质量。这是由于现在普遍的商业采购模式导致的。而要想解决这个问题，发展软件订阅制是个非常不错的方案。 对于甲方来说，采用订阅制来采购软件，就是按时间和用量付费，而不购买整个软件源码的知识产权。换句话说，就是买软件的使用权和一种服务，这个服务就是 …
脑筋急转弯：为了防止运维人员能够直接去数据库里查看密码，Web应用普遍采用将密码哈希一趟后再存入数据库。需要校验时，由前端提供密码值，服务器将密码哈希后再比对，从而判断密码是否正确。这样运维人员即使接触的到数据库，也最多只能重置密码，无法登录一个特定的账号。那么，既然最终需要比对的是密码的哈希，为何不直接在前端哈希完，再直接把哈希后的结果发给服务器，来鉴定密码是否正确呢？答案其实挺简单的。当初我们加一次哈希是为了阻止运维登录。而如果哈希在前端完成，那么对于服务器而言，它其实只是做了一次明文的比较。数据库里的哈希值就相当于密码了。运维完全可以直接拿着哈希去调登录的API来获取一个账号的权限。 这个脑筋急转弯挺有趣的，乍一看仿佛还挺有道理的。但是换句话说，虽然看起来前端加哈希蠢蠢的，其实历史上有很多公司和项目都做过类似的事情。其中比较典型的就是腾讯公司的QQ了。 在十几年前的时候， …