技术

疫情之下，各国都在不断地调整自己的防疫政策。中国的模式已经证明了其可能是最有效的方式之一，但因为种种原因大部分国家难以效仿和接受。从技术层面来讲，基于支付宝/微信等国民APP之上的健康码模式也是如此:有效，但是别国难以效仿。新加坡最开始使用BlueTrace协议并开发出了相应App让国民下载使用,部分其他国家也开始效仿，甚至有望能成为一种国际通用的防疫标准。 隐私保护是 BlueTrace 所考虑的最主要特点之一。其手段包括如下方面: 尽可能少的收集用户信息，卫生部门唯一收集的信息是手机号 本地存储用户接触记录，只有当被感染者愿意分享此数据时卫生部分才能获取 第三方无法通过此协议一直追踪用户。因为相关标识ID会一直更换 … 所以在对用户的标识方面，主要是通过算法生成的 UserID 和 TempID 来进行。当用户用手机号进行注册时,后台服务会生成一个 UserID, 而用户在互相接触需要通过蓝牙交换信息时，则通过 TempID 进行。TempID的 大概结构如下: 可以看到其有如下特点: 加密。只有卫生部门才有密钥能解密数据 过期时间。TempID有过期时间，一般在15m左右.这样可以尽量减少恶意攻击或者伪造假数据 TempID的生成需要联网(加密啥的)，所以为了考虑到用户不联网的情况，所以TempID可以一次性尽量生成多个，在联网的时候一次性发给用户以备用。 当装有相应APP的用户相遇时，设备会通过 Bluetooth Low Energy (BLE)协议进行通信并交换信息，其数据流程如图所示: 这里面两个 Device 分别有一个角色定位，一个叫 Central ，一个叫 Peripheral。Central 主动扫描 Peripheral 并读取其信息，然后返回一些额外信息。一个手机一般是按一定时间比率轮换在两个角色之间切换。其交换的数据大概如下所示: { "id": "FmFISm9nq3PgpLdxxYpTx5tF3ML3Va1wqqgY9DGDz1utPbw+Iz8tqAdpbxR1 nSvr+ILXPG==", // TempID "md": "iPhone X", // Device model "rc": -60, // Signal strength "o": "IJ_HAI", // Health authority identifier "v": 2 // Protocol version } 这里面需要注意的是: ...

代码应该拥有良好的注释一直是业界共识，毕竟，在可预见的未来里，阅读代码的主要还是人。所有的语言都支持注释，有的拥有额外的注释提取工具及格式规范。但总体来说，大部分语言在这块做的都比较一般。Python有一些约定俗称的规范以及 Sphinx 这样的工具， Golang 的规范比较简单，但内置了 godoc 工具。Lisp 算是做的比较好的，示例如下： (defun small-prime-number-p (n) "Return T if N, an integer, is a prime number. Otherwise, return NIL." (cond ((or (< n 2)) nil) ((= n 2) t) ((divisorp 2 n) nil) (t (loop for i from 3 upto (sqrt n) by 2 never (divisorp i n))))) 其独特之处在于，不同于一般语言注释位于函数体之外，而是将其放置于函数 body 开始处。这样开发者更容易将其当作函数定义的一部分，也有助于养成良好的注释习惯。 Golang 虽然 在注释方面做的普通，但是在官方 library 以及最佳实践方面成功地鼓励了人们尽可能地写非常详细的注释，具体到一个 struct 的各个字段上。尤其是在 kubernetes 社区里面, 其Space Shuttle style 的 Code 对于社区的蓬勃发展可以说是一个极大的背后功臣，从如下的代码便可一窥其风格： // Adapts a ConfigMap into a projected volume. // // The contents of the target ConfigMap's Data field will be presented in a // projected volume as files using the keys in the Data field as the file names, // unless the items element is populated with specific mappings of keys to paths. // Note that this is identical to a configmap volume source without the default // mode. type ConfigMapProjection struct { LocalObjectReference // If unspecified, each key-value pair in the Data field of the referenced // ConfigMap will be projected into the volume as a file whose name is the // key and content is the value. If specified, the listed keys will be // projected into the specified paths, and unlisted keys will not be // present. If a key is specified which is not present in the ConfigMap, // the volume setup will error unless it is marked optional. Paths must be // relative and may not contain the '..' path or start with '..'. // +optional Items []KeyToPath // Specify whether the ConfigMap or it's keys must be defined // +optional Optional *bool } 可读性越好的代码越容易流行。Golang 在这方面做的很好。 ...

最近发现之前写过的很多项目，不管是 python/go/cpp 的，最终回看起来代码都变的很难看，尤其是多人合作的时候。 这是一个很头疼的问题。自己平时很在意这个，但是代码最终确都变成了 shit。 问题 当一个人开发的时候，问题主要在于一个人的自律性不够强，不管是代码注释等都是随意写的，即使偶尔意识到了问题，但也难以保证能一直坚持下去。 而当人多的时候，问题经常处在多人风格的不同上。如果没有工具来强制大家遵守一定的规则，那么大家每个人自己的风格放在一起的时候，就成了垃圾代码。 避免代码变成 shit 的唯一方法，就是让大家写的代码看起来都一个样。而这个工作除了由开发人员的 Code Review 之外，还需要工具来约束。 解决方法 CI/CD 最开始接触 CI/CD，我只是认为它主要是用于部署方面的一个工具。现在发现，它对于代码质量的改进也是意义巨大的。所有代码通用规范上的约束，静态分析，复杂度分析等都可以通过自动化工具来执行。 一方面，我们可以组合尽可能多的代码静态分析工具，来约束提交代码的错误，提供代码改进的建议，形成统一的代码风格。另一方面，最于 Code Review 来说，不再需要关注基本的代码风格以及基础部分，而只用关注于具体的业务以及代码架构层面的问题。 静态分析 Python 这样的代码，在多人合作的大型项目上，如果没有非常严格的代码约束，最终出来的项目时非常难以维护的。可能经常部署出来的代码连跑都跑不起来。相对来说，静态类型语言在这方面的优势是巨大的，编译器在编译代码阶段能发现大多数比较明显的问题，最终线上的问题一般都是需要人来参与分析的。 代码的静态分析是一个非常古老但是重视程度不够的技术。静态类型语言的代码分析技术能够极大地减少代码中可能存在的 bug,并给出很多的建议。以 Golang 为例，目前已经有几十款静态分析工具。 而像golangci-lint这样的工具，可以将多种分析工具结合起来，在各个层面给出代码改进的建议。比如： 代码的简化写法 可能的 bug Dead Code 未使用的或者被覆盖的变量 … SonarQube 其实是类似的产品，只不过是 Client/Server 的架构，提供了诸如复杂度分析，单元测试覆盖率等指标。良好的 UI，以及插件式的架构，与普通的 cli 工具结合起来之后，对于代码质量的提高是非常有益的。 总之，工具能处理的事情越多，人的精力就更多的能去关注更上的层面和业务层面。 Code Review Code Review 虽然成为一个共识，但真正的效率确实难以保证的。莫名其妙的改动，形式化的 approve,现有工具的局限等等问题都造成了参与的人在这方面的低效率。所以总是需要有各种规范来指导人们如何进行 Code Review。一般来讲，我们可以将代码的改动拆分为三个问题 Why? 为什么要做这个改动 How? 怎么做这个改动 What? 具体做了哪些改动。 这几个问题，工具能参与的只是What的一部分。其他的部分都需要人来 review。一般的 Code Review 提交的模板也都要求提交 PR 的人尽量说清楚 Why,通过文档 link 或者文字等形式。具体的 How 以及 What，则需要具体的人来参与 review。 ...

互联网到今日已经越来越趋向于中心化，用户的隐私安全以及大公司的行为也日渐引起担忧。去中心化网络是一个应对此问题的重要思想，blockchian,bitcoin,tor 等都是一些具体的技术探索，很多已经有了越来越大的影响力。Namecoin 也是其中的一个。 Namecoin 想要解决的是目前 DNS 存在的一些问题。中央机构控制的 DNS 很容易因为各种原因受到干扰，用户的利益和隐私容易受到侵犯。Namecoin 借助于 bitcoin 的思想，构建了一个去中心化的 DNS 系统。 Zooko’s triangle 类似于分布式系统中的 CAP 理论。类似 DNS 这样的协议，我们期望它具有的三个特性很难满足: 安全,可读性好,去中心化。目前的最常用的 DNS 系统不满足去中心化。DNSSec 对现有的 DNS 做了一些安全性的增强，但仍然是中心化的。.onion和bitcoin是去中心化的和安全的，但是可读性很差等等。 Namecoin 是满足上面要求的一个系统。（Aaron Swartz曾经提出过这样的设计思路) Namecoin Namecoin 基于 BitCoin,本身就是在 Bitcoin 的代码上实现的(大概做了 400 多行改动)。挖矿的方式跟 bitcoin 一样，只是用的是不同的 block chain.二者的目的不同,bitcoin 主要还是为了成为一种货币系统，Namecoin 是为了成为一种命名系统。所以二者的关注点不同，blockchain 分开也是最合理的。二者有一些不同的规则： namecoin 要求名字的唯一性(域名)，而 bitcoin 不要求 经济交易以及域名注册使用的货币大小不一样，block size 设的不一样更好 通货膨胀对 bitcoin 的影响很大，namecoin 则不一样。 namcoin 中，注册域名需要花钱,但这些货币会被销毁(0.01NMC).因为是去中心化的系统，没有收费的中央系统。 Namecoin 里的数据主要分为两种 domain name 和 NameID Domain Domain 的格式类似于: ...

介绍 区块结构 头结构 区块结构 创世区块 分叉 Proof-of-work(工作量证明) 邮件 Header Bitcoin REF 介绍 区块链是由一串使用密码学方法产生的数据块组成的，每一个区块都包含了上一个区块的哈希值(hash),从创始区块(genesis block)开始连接到当前区块，形成块链(类似数据结构中的链表).每一个区块都确保按照时间顺序在上一个区块之后产生，否则前一个区块的哈希值是未知的。 其优势在于: 完全分布式的，无中心节点(单点故障) 任何节点都可以创建交易。在经过一段时间的确认之后，就可以合理地确认该交易是否有效。 修改交易记录的成本非常高 区块链也是比特币等技术的基础。它也是一种非常重要的新思想，促使人们对现有的网络,社会,经济等进行重新思考。 区块结构 头结构 大小(bytes) 字段 描述 4 版本 版本号 32 父区块哈希值 引用区块链中父区块的哈希值 32 merkle 根 该区块交易的 merkle 树根的哈希值 4 时间戳 该区块产生的近似时间(精确到秒的 unix 时间戳) 4 难度目标 该区块工作量证明算法的难度目标 4 Nonce 用于工作量证明算法的计数器 区块结构 大小(bytes) 字段 描述 4 区块大小 该字段之后的区块大小 80 区块头 区块头结构 (上面的大小之和) 1-9 可变整交易计数器 交易的数量 可变 交易 记录在区块里的交易信息 创世区块 比特币区块链的第一个区块，创建于 2009 年，我们称之为创世区块。它是比特币区块链里所有区块的共同祖先，这意味着你从任一区块，循链向后回溯，最终都将到达创世区块。每一个节点都“知道”创世区块的哈希值、结构、被创建的时间和里面的一个交易。因此，每个节点都把该区块作为区块链的首区块，从而构建了一个安全的、可信的区块链的根。 ...