Brain Dumps

  domain是随着role的变化而变化的，SDE可能可以分成至少如下几个role吧。 前端，没什么好说的，算是一大块，我的理解是不管什么公司什么领域，任何前端做的事情都是差不多的。depth可能就是指能熟练掌握流行的CSS/JS框架以及工具，能灵活满足business requirement。但我在前端方面只在刚开始工作时做过短短一年，那时候几乎每年都会有新框架新library出来，react也才方兴未艾。现在不知如何，可能我的理解已经过时。 Service Backend，这里主要就是写服务的后端，也就是业务逻辑。这里其实分得最细，广告、电商、社交、外卖、搜索、商务（B2B软件）、地图等等，都有自己与众不同的业务逻辑和实现方法，每一个小的domain都有值得深挖的部分。depth应该指的是熟悉相关service背后的典型架构，了解各种常用的tooling（data pipeline, database, microservice等），很多所谓的 系统设计 题就是从这里出的，就是看你能不能组合相关的tooling来开发一个满足business requirement的系统。除此之外，当然也要有快速掌握常规开发语言的framework的能力，因为不同公司甚至不同项目之间，用不同的开发语言的现象非常常见（Java，Go，部分Python，C/C++等）。 System Infra，这里大部分指的是Compute，Network和Storage（我们把这仨叫做Core）相关的系统的开发和运维，有的会在其中某一块钻研，有的则需要组合core infra来开发针对特定需求的infra，比如这里讨论的ML Infra就是其中一种。这里的depth指的自然是在core infra或者hybrid infra方向的深耕细作，在这个年代里，相关的专家往往坐落于各种云服务背后，同时需要开发和运维的技能，如果是Core的话侧重运维，非Core则是侧重开发。 .google  и SRE，我的理解指的是针对某个Service的运维，分类和Service一样，只不过Service主做开发，SRE主做运维，需要的技能主要是Linux和K8s，以及相关的tooling。我觉得需要注意的是虽然Google、抖音等公司依然有专门的SRE，但是现在越来越多SR

  In computer science , write-ahead logging ( WAL ) is a family of techniques for providing atomicity and durability (two of the ACID properties) in database systems . [1] A write ahead log is an append-only auxiliary disk-resident structure used for crash and transaction recovery. The changes are first recorded in the log, which must be written to stable storage , before the changes are written to the database. [2] The main functionality of a write-ahead log can be summarized as: Allow the page cache to buffer updates to disk-resident pages while ensuring durability semantics in the larger context of a database system. Persist all operations on disk until the cached copies of pages affected by these operations are synchronized on disk. Every operation that modifies the database state has to be logged on disk before the contents on the associated pages can be modified Allow lost in-memory changes to be reconstructed from the operation log in case of a crash. In a system

 https://mp.weixin.qq.com/s/A9mjMUGV0518uSbWv3imAw 腾讯微搭的对手从来都不是钉钉。 01 低代码 是 “旧瓶装新酒” 吗？ 低代码风潮在国内兴盛已有两年，但也并不是已经被所有人接受，有不少开发者还保有否定、抵触的态度。 那为什么我们还认为这是一个不可逆的趋势呢？ 这里先看下被否定的原因，雷峰网在调研中听到的主要是这三种情况： 其一，低代码的出现会很大程度上分流某些程序员的一大部分工作，使他们的存在感和价值大大降低； 其二，有一定能力的程序员都希望通过自己的双手创造价值，而低代码却让他们“造火箭”的梦想破灭了； 其三，国内的低代码在技术、产品、人才等方面均不成熟，导致低代码功能不完善，程序员用起来不习惯，所以不愿意用。他们认为，低代码如同一个黑匣子，不仅不能解决他们在工作中遇到的棘手问题，还很难控制开发过程中产生的突发问题。 他们称低代码不过是“旧瓶装新酒，没什么了不起”。 从时间上来看，其实低代码确实诞生的很早，起源甚至可以追溯到上个世纪90年代。 其主要经过了四个发展阶段：1980年IBM的快速应用程序RAD出现；2000年可视化编程迭代；2014年Forrester提出低代码概念；2016年国内相继发布低代码平台；2018年Gartner提出aPaaS和iPaaS的概念后市场逐步稳固。 人们产生“低代码就是一个旧事物”的认知是很正常的，技术圈中关于低代码的讨论更是层出不穷：“一个旧事物能带来多大的价值？一个旧事物能取代程序员？”等等。 但旧事物到底能不能创新，这又是另外一回事。 德鲁克曾经谈过创新的本质有两种，一是让昂贵东西变得便宜老百姓能用，二是让高门槛东西变得低门槛普通人可用。 低代码在这个时代就很符合这两个本质描述，所以从这个角度来说，低代码在这个时代具有创新价值。 低代码至少顺应了这几个时代趋势： 其一，IT部门越来越贵，企业要降本。从企业高管角度来说，秉着降本增效的经营理念，大部分企业尤其是传统企业一般不会通过招聘几个工程师实现企业的数智化升级。一方面工程师的工资高，一年动辄上百万的开支，另一方面采购低代码工具的成本要低的多。 其二，需求越来越精细，高级程序员、架构师们需要增效。低代码因其灵活易用等特性在降本的同时，还能给企业和团队增加效益； 其三，人们用低代码产品更方便，都用成习惯已经不可逆了。三年疫

 https://mp.weixin.qq.com/s/x-AdmN0UN5KT58XWO1BCOA   本文不对 raft 算法从头到尾细细讲解，而是以 raft 算法论文为起点，逐步解读 raft 算法的理论，帮助读者理解 raft 算法的正确性。然后，etcd 不仅是 raft 算法最为热门的工程实现，同时也是云原生 kubernetes 的核心存储，本文也对 etcd 的底层实现进行剖析，让读者在使用 etcd 组件的过程中能够做到心中有数。对 raft 算法足够熟悉的同学，也可以直接阅读 etcd 工程实现那块内容。 1. raft 算法的简单介绍 在 raft 算法中，每个机器节点的状态包含三种：leader、follower、candidate。系统在时间上被划分为一系列连续的任期 term，每个 term 的 leader 可以产生连续的 log，如下图所示。每个任期 term 可以选举出一个 leader，该 term 的 leader 选举出来后可以产生日志。异常情况下，一些任期 term 可能选举 leader 会失败而直接进入下一个 term，或者 leader 没有产生任何日志就超时从而进入下一个选举周期。 leader 节点需要将其产生的 log 复制给其他节点，当多数派节点收到 log 则表明该 log 可提交。对于集群机器更换或者扩缩容，leader 节点生成配置变更日志并且复制给其他节点来达成一致。 从上面对 raft 算法的介绍中，可以得出 raft 需要解决以下三个问题。后续章节将围绕这三个问题剖析 raft 算法的实现。 raft 如何安全地选举出一个 leader？ leader 如何将 log 安全地复制到其他节点？ 集群如何安全地变更机器节点？ 2. leader 选举以及选举安全性 2.1 leader 的选举流程 下图是 leader 选举的流程图。节点初始化的时候，首先进入到 follower 状态，一段时间内没有收到 leader 节点的心跳就会切换到 candidate 状态去竞选 leader。节点进入到 candidate 状态后，首先将自身任期 term 加一，然后给自己投票，并且向其他节点广播 RequestVote 投票请求。candidate 竞选 leader 的结果有三种：