查看详情
GDPR,是指通用数据保护条例（General Data Protection Regulation）的缩写，是欧盟（EU）的一项法规，旨在保护欧盟公民的个人数据并赋予他们对其数据的更多控制权。它于2018年5月25日生效，取代了1998年数据保护指令。你可以前往的官方网站阅读具体的内容，里面罗列了非常详实的条款。 https://gdpr-info.eu/ 如果你的网络服务需要登录欧洲，这个协议是你必须了解的。GDPR 适用于在欧盟运营或处理个人数据的任何组织，无论其总部位于何处。这意味着即使您是一家美国公司，但您收集或处理来自欧盟公民的个人数据，则您也必须遵守 GDPR。你是懂欧洲的违法罚款的，尤其涉及数据隐私。 GDPR 带来的影响有： APP 必须获得个人的同意才能处理他们的个人数据 个人有权访问其个人数据并要求更正或删除不准确的数据 个人有权要求组织停止处理他们的个人数据或限制其处理 APP服务商必须任命数据保护官 (DPO)，负责监督其遵守 GDPR 的情况 为了遵守GDPR，应用程序必须采取一些措施，例如： 获得用户的同意才能收集和处理他们的个人数据。 这意味着应用程序必须有一个明确的隐私政策，解释应用程序如何收集、使用和共享数据，以及用户如何控制他们的数据。用户必须能够轻松地同意或拒绝处理他们的数据的请求。 仅收集必要的个人数据。 应用程序只能收集为提供服务或履行合同所需的数据。他们不应该收集不必要或无关的数据。 以安全的方式保护个人数据。 应用程序必须采取适当的技术和组织措施来保护个人数据免遭未经授权的访问、使用、披露、 详情 »
查看详情
随着代码集成越来越多，尤其大家对单测质量和覆盖率, 大家在 CI 里寻找错误的测试用例似乎非常麻烦。 其实有网友也有同样的需求： Print list of failed tests at the end of test run 这里面有个非常天才的小伙子，直接来了一个 npx jest 2>&1 | grep '●' Jest 失败的测试用例有个 ● 前缀！！！ 为什么我比较喜欢这种，因为不需要更改配置，而且直接可以在网页浏览器搜索 '●' 详情 »
查看详情
在公司工作，普遍采用了AB实验去验证某个 Feature 的效果，但是客户端或者前端工作而言，我们在做实验分析的时候还需要做更多的事情。 去年自己遇到一个 Case 便是如此。这里不太会透露很多业务的细则。 比如自己再做的的一个实验 A, 它在前端整体跑下来的结果是 显著 positive 的。比如它从设计的出发，会带来某个指标的增长。从假设出发，到最后的结果，我们发现符合预期的。因此我们计划将它应用到全量用户。 总的来说这里没什么问题，但是我们都知道前端其实面临非常多设备型号， 有可能存在某种型号在这个 feature 上的失效，带来负面的影响。虽然我们看到了总体的增长，但是部分用户我们其实并没有看到预期增长，这个是我们工作需要去重视的。 因此后来我们也提议，在做实验结果 Review 的时候，可以 Review Top5 的机型指标增长情况。 很多人提出为什么不再测试阶段去针对多个机型的测试呢？ 这里引入另外一个自己的 Case。前端工作的多重性，会让我们的工作总会有所疏漏。 自己在做的某个实验 B，它的假设是可以降低某种错误。然后我们开始进行多个平台的实验，发现普遍都取得了一些效果，然后我们准备去进行全量铺开。然后全量铺开的过程，发现它带来了某一项别的指标的异常上升。然后我们 Review 发现，它在某种机型某种条件下才会失效。 详情 »
查看详情
很多公司都是企业组织在 Github 上进行代码的管理，因此大家可能需要一个工作的账户和个人的账户区分。其实这个非常好弄，只需要两部即可： Step1 配置多份配置 你可以在你的根目录，创建下面的的结构 ~ ├── .gitconfig <-- global └── Developer/ ├── personal/ │ ├── project_1/ │ ├── project_2/ │ ├── project_#/ │ └── .gitconfig <-- personal └── company/ ├── project_1/ ├── project_2/ ├── project_#/ └── .gitconfig <-- company 然后更新两份配置 # ~/Developer/personal/.gitconfig [credential] username = <github-user> [user] name = <github-user> email = <github-user>@users.noreply.github. 详情 »
