尝试在ebay 手机web端实现条码扫描。目前尚未实际应用。 使用WebAssembly，用三种方式三个worker竞争识别条码，规定时间内识别率从单线程的80%提升到接近100%，效果非常不错。

vue-devtools

errorHandler

Vue.config.errorHandler = function(err, vm, info) {
  console.log(`Error: ${err.toString()}\nInfo: ${info}`);
}

warnHandler

Vue.config.warnHandler = function(msg, vm, trace) {
  console.log(`Warn: ${msg}\nTrace: ${trace}`);
}

renderError

const app = new Vue({
  el:'#app',
  renderError (h, err) {
    return h('pre', { style: { color: 'red' }}, err.stack)
  }
})

errorCaptured

Vue.component('cat', {
  template:`
<div><h1>Cat: </h1>
  <slot></slot>
</div>`,
  props:{
    name:{
      required:true,
      type:String
    }
  },
   errorCaptured(err,vm,info) {
    console.log(`cat EC: ${err.toString()}\ninfo: ${info}`); 
     return false;
  }

});

window.onerror

window.onerror = function(message, source, line, column, error) {

}

大部分 npm 操作是流量密集型的，Node.js 正是针对这种场景设计的。但是，npm 工程师们发现，确保只有授权用户可以发布包的授权服务显示出令人担心的计算密集型负载

因此，npm 工程师开始寻找最适合该任务的编程语言。因为缺乏内存安全性，C 和 C++ 很快就被排除在外，而 Java 因为依赖虚拟机，也出局了。剩下的语言有两种，分别是 Go 和 Rust。为了更好地评估最终解决方案，npm 团队决定用这两种语言以及 Node.js 分别重写他们的身份验证服务，以便进行比较。

Node.js 重写只花了一个小时。另一方面，Go 需要 2 天，但以 Rust 重写花了整整一个星期，主要是因为 Rust 的学习曲线更加陡峭以及该语言的内在复杂性， Chris Dickinson 这样解释说。

与当时 Go 能提供的包管理器相比，Rust 包管理器 Cargo 具有优势。

对 npm 团队来说，好消息是 Rust 服务已经在生产环境中运行一年有余，没有任何告警。这与在 npm 部署 Node.js 服务的常规经验形成鲜明对比。

本次发布加入了实验特性WASM模块。WASM加入nodejs正式支持指日期待，javascript如虎天翼️。

新特性包括

• express.raw 将请求体解析为Buffer。
• express.text 将请求体解析为文本string.

• 可生成web compoment（自定义元素）。
• 支持双向绑定
• 支持模板
• 支持事件
• 不支持嵌套子组件
• 没有依赖
• 需要浏览器支持ES6

<script type="module">
  import reLiftHTML from '//unpkg.com/relift-html';
  reLiftHTML({
    template: `
      Counting: {this.count}
    `,
    tagName: 'my-counter', // custom tag
    data: {
      count: 0
    },
    created(){
      this.data.count = this.prop.start || 0;
      setInterval(_=> {
        this.data.count++;
      }, 1000)
    }
  })
</script>


<!-- the count will start at 5 for this custom element -->
<my-counter start=5></my-counter>

<!-- the count will start at 21 for this custom element -->
<my-counter start=21></my-counter>

https://github.com/mardix/relift-html

如图所示，实际上仍然需要服务器生成 (AWS 预签名 URL)(https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/PresignedUrlUploadObject.html)。 然后才可以使用此 URL 直接上传。 上传组件使用的是 react-dropzone。

此功能有助于快速生成用于学习，分析，使用mongo。

NewSQL 是一种新方式关系数据库，意在整合 RDBMS 所提供的ACID事务特性（即原子性、一致性、隔离性和可持久性），以及 NoSQL 提供的横向可扩展性

NewSQL 更重视一致性，即侧重 CAP 中的 C 和 P，很多NewSQL 数据库为提供强一致性而牺牲了部分可用性。

一些项目希望实现统一支持事务处理和工作负载分析的数据库。HTAP（混合事务 / 分析处理，Hybrid Transactional/Analytical Processing）一词由 Gartner 提出。支持 HTAP 功能的数据库提供对高级实时分析，进而支持实时业务决策和智能事务处理。

大型国有银行，整体核心的系统都是大机 +DB2 这样的传统架构；

大型主机运营成本非常贵，买个机器帮你搞两下就几千万上亿的支出，再加上商业产品的 License 比较高，银行议价能力又比较低；

在原型阶段，当时主流是 MySQL5.6，5.7 才刚出来；对于高可用要求，行里的应用是要做到同城切换，上海两个园区要做到 RPO（恢复点目标） 是 0，RTO(恢复时间目标) 非常小，同时异地北京有一个灾备中心，就是两地三中心。

在原型设计阶段，我们基于 MySQL 的半同步复制，来做这样的一个切换，实现 RPO=0，解决主库故障自动切换到备库，同城为了保障 RPO=0，在原型阶段进行了应用的双写。来进行数据的核对和补充；

在整体上面基于 MySQL 的复制技术，我们有半同步复制和多数派共识机制实现冗余备份。基于 MySQL binlog 日志自动数据补全，保障数据的一致性。

在应对一些高并发场景的时候，因为 IO 性能不足，这方面我们就改进了，直接引入了 SSD 盘，基本上把 MySQL、IO 的瓶颈给解决了。在现在的场景下，IO 一般不会成为瓶颈了。同时通过 SSD 的引入，交易的响应时间在相同条件下降低 50%。

Oracle 的转型。工行应该把 Oracle 这样的一些特性用的非常极致；基本上都是存储过程，当开发框架一确定，大家存储过程都是用笔勾几下或者拉几下就可以产生很多的流程，但它同时和具体的数据库绑定了，后面的维护、扩展都面临比较大的挑战。

我们实施了至少 120 多个应用，2000 多个服务器节点，超过 2500 个 MySQL 节点。实施的应用涉及很多核心业务，包括个人账户、对公账户、基金以及很多 A 类、B 类的应用，大多都是主机上迁移过来的。其中还有少量应用是从 Oracle 迁移过来的，应用层也因此需要重构。

需要一个AWS账户，基于AWS Stack一键创建相关资源。

自动创建的项目：

• 两个s3 桶。一个用于www域名一个用于根域名跳转.
• 两个CloudFront CDN
• 一个https证书。
• Route 53配置.

与 Kafka 不一样的是，Pulsar 具备传统消息队列（如 RabbitMQ）那样的功能，因此，只需要运行一个 Pulsar 系统就可以同时处理实时流和消息队列。

Pulsar 就可以做到。如果你只需要一个主题，而不需要分区，那使用一个主题就好了。如果你需要使用多个消费者实例来提升处理速率，其实也不需要使用分区，因为 Pulsar 的共享订阅可以达到你的目的。

如果你确实需要分区来进一步提升性能，你也可以使用分区。

Pulsar 对日志进行分段，从而避免了拷贝大块的日志。它通过 BookKeeper 将日志分段分散到多台不同的服务器上。也就是说，日志并不是保存在单台服务器上，所以任何一台服务器都不会成为整个系统的瓶颈。

因为 Pulsar 的 broker 是无状态的，所以如果工作负载很高，就可以直接添加新的 broker。

跨域复制是 Pulsar 的拿手好戏。Pulsar 在设计之初就考虑到了这个特性，配置也很容易。

一些基准测试表明，Pulsar 可以在提供较高吞吐量的同时保持较低的延迟。

Pulsar 提供了很多与 Kafka 相似的特性，比如跨域复制、流式消息处理（Pulsar Function）、连接器（Pulsar IO）、基于 SQL 的主题查询（Pulsar SQL）、schema registry，还有一些 Kafka 没有的特性，比如分层存储和多租户，所有这些特性都是开源的。

当女性患有抑郁症时，她们体验到的症状通常和抑郁有关，男性更可能体验到的经历像暴怒和易怒、焦虑、激动和躁动不安，而这些通常与抑郁无关。这也意味着，男性往往长时间无法得到诊断，并且接受治疗的可能性也更小。

我们处于一种非常绩效导向的文化中，很容易认为，承认自己患有心理疾病可能意味着无缘升职或丢掉现在的职位（这在大多数地方是非法的，但是，大多数人都听到过这种情况的发生，而公司通常是用其他理由撤掉你现在的职位）。

归根结底，这很大程度上需要从上至下地进行。组织中的那些管理人员、总监和高级管理人员需要传达这样的信息：公司很关心员工的健康和福祉（表示他们的理解远远超出了提供运动器材的范围！）最好的方法是，让病假政策变得更慷慨和灵活，尽可能超过行业标准。

信任员工。是的，我故意说了两次，因为信任非常重要。

我确实认为公司应该变得更加灵活并接受像远程工作的解决方案。当大多数工作可以通过网络完成时，远程工作真应该成为行业标准。

任何有远程办公的公司应该确保定期访问其远程员工或组织公司范围的线下活动以确保给每个人一个机会来建立人际关系并感觉到自己是团队的组成部分。这个见面时间也是极其重要的。

最关键的事是，尊重工作与生活的平衡和界限，最好的方法就是以身作则，因为行动胜于雄辩。这意味着，准时离开办公室，每周至多工作 40 小时。不要在周末工作。即使我们醒着并且已经读过邮件，也不要在凌晨 2 点回复它，因为如果我们现在回复邮件，那么就是示意其他人都被期望将来也这么做。定期休假。

有些事情只有我们所有人一起合作才能改变；单单一个人是无法改变整个文化的。

除非经美国政府正式授权，否则 ASF(apache 软件基金会) 软件、技术或数据不得直接或间接出口 / 再出口到受美国禁运或贸易制裁的地方。美国政府保留出口禁止名单，包括但不限于财政部的特别指定国民名单和 商务部的实体和被拒绝人名单。

不止 ASF，GitHub 官网也发消息称，“GitHub.com、GitHub Enterprise Server 以及您上传到任一产品的信息可能受美国出口管制法律的约束，包括美国出口管理条例（EAR）。”

根据 GitHub 的服务条款，用户只能按照适用法律访问和使用 GitHub.com，包括美国出口管制和制裁法律。根据美国和其他适用法律，特别指定国民名单和其它被拒绝、被封锁的人士禁止访问、使用 GitHub.com，用户不得代表此类各方使用 GitHub.com，包括受制裁国家 / 地区的政府。

根据美国财政部海外资产控制办公室（OFAC）发布的授权，Github 可允许受美国制裁的管辖区内或通常居住在管辖区内的用户访问某些 Github.com 服务。在访问 GitHub 服务时，这些管辖区内的人员和居民不得使用 IP 代理、VPN 或其他方法来伪装其位置，并且只能使用 GitHub 进行非商业的个人通信。

GitHub Enterprise Server 不得出售、出口或再出口到清单中的国家，目前清单中已经包含古巴、伊朗、朝鲜、苏丹与叙利亚。

微软今天宣布推出专为 macOS 操作系统设计的微软 Edge 浏览器的预览版，根据 Chromium 的命名规则又名金丝雀版。macOS 用户现在就可以在 Microsoft Edge Insider 站点安装 Microsoft Edge for macOS。微软最早公布这一版本是在 5 月 6 日在西雅图举行的年度 Build 开发者大会上。

养老金的领取条件并非参保就有，职工想要领取养老金必须满足两个硬性条件，其一是达到法定退休年龄，其二是养老保险缴费满15年及以上，因此有许多已到法定退休年龄但是缴费年限不足人员无法领取养老金。

实际中各地区对于社保补缴开始规范化，一次性补缴各地开始取消。以个人身份参保的人员在参保时期断缴或者缴费不足的情况下，也不被允许以事后追补缴费的方式增加缴费年限。通过企业参保的人员，在因个人因素导致社保断缴，也不得事后补缴，因所在企业导致社保断缴，从而影响到购房资格、养老金领取、生育津贴领取、医保报销等情况时，可以哦要求企业在次月进行补缴，但是补缴时间不得超过三个月。

退休后缴费年限不到15年，可以办理顺延退休，继续缴纳养老保险，缴费五年后仍不足15年，是可以一次性补缴剩余的费用，也就是最长的情况下也仅仅是推延五年时候领取养老金。

虽然说养老金领取时间是参保15年即可，但是若缴纳15年后选择断缴，那么造成的影响也会导致医疗保险白白缴纳，原因是医疗保险最低缴费年限分别是男性最低缴满25年，女性最低缴满20年，未缴满的人员到达法定退休年龄后无法继续获得医疗保险所带来的待遇，而且医疗保险与养老保险是一起缴纳，不可单独缴纳一种保险，所以当你养老保险停缴后，间接的也就停缴了医疗保险。

所以男性50岁以上，虽不可一次性补缴养老保险，但是在到达法定退休年龄后仍然可以继续顺延缴纳养老保险，另外医疗保险因为所需缴费年限更长，多数地区可以进行一次性补缴，若是在外地进行补缴医疗保险时，需要在当地参保时间满十年后才可以进行一次性补缴。

从参保人角度出发，做到尽早参保，不断缴不停缴社保，在法定退休年龄时一般都是已经满足各项保险的最低缴费年限要求，若距离退休时间不久，养老保险可以顺延缴纳，推迟领取养老金时间，医疗保险可以一次性补缴剩余费用。

当一个项目达到像 Redis 这样的流行程度，并且人与人之间的交流因为新的社交工具而变得更为容易时，作者收到的消息、issue、PR 和建议的数量也将呈指数增长。随之出现一个普遍性问题，至少从 Redis 的情况来看是这样，即没有足够多合格的人去查看并处理社区中的这些信息。

Redis 流行起来后，我的工作更多地转变为了查看 PR 和 issue。这其中确实有些人会比我做得好，但大多数人的贡献仅处于平均水平，只是解决给定问题罢了。

当我设计 Redis 时，我倾向于将它视为一个整体，毕竟这么多年来一直在写这个东西。所以现实是，擅长的东西往往不再有时间去做。

我的解决方法是，给自己几周时间停止查看 PR 和 issue，转而去编程或者设计，这才是我真正喜爱和享受的。但这反过来又给我带来了更大的心理压力，只在做自己喜欢的事情时做得很好，令人感觉很糟糕。

长时间在一个项目上工作有两个问题，至少对我而言是这样。

第一个问题是，在 Redis 之前，我从未有过在每个工作日都工作的经验。我总是干一周，停两周，接着再干一个月，然后消失两个月。做创造性工作需要充电，以获得新的能量和想法。

但开始收到在 Redis 工作的报酬后，道德规范我不能再依照过去的模式，所以我强迫自己按照正常的时间表工作。这对我来说无比挣扎，而且我确信自己做得比实际能做到的要少。目前仍未找到解决方法，跟公司申请回到原先的工作模式是不管用的，因为社区的运作方式如此。

另一个问题是，从精神上讲，在同一个项目中进行大量工作也是一件复杂的事情。我过去常常每六个月换一次项目，而如今十年来都在做同一个项目。我试图通过在 Redis 中部署子项目来留存创造力，先后做了 Cluster、HyerLogLogs 和一个已放弃的磁盘存储项目，现在在做第四个。

不过，最终还是要回到 issue 和 PR 页面，每天重复同样的工作。

文章评论也值得一读

go的社区很活跃，有许多建议，但是go是google的项目，建议很难被采纳。