Development

Google 技术写作课程搬运，原文地址：https://developers.google.com/tech-writing/overview?hl=zh-cn Facilitating Technical Writing Courses This section provides resources for anyone facilitating or considering facilitating technical writing courses. The following table contains links to all relevant material for facilitators: for facilitators for students Course Facilitator’s Guide slide deck log pre-class in-class Technical Writing One Facilitator’s Guide[1] slide deck[2] log[3] pre-class[4] in-class[5] Technical Writing Two Facilitator’s Guide[6] slide deck[7] log[8] pre-class[9] in-class[10] If you’d like to facilitate a particular course, please start by reading the course’s Facilitator’s Guide. ...

Google 技术写作课程搬运，原文地址：https://developers.google.com/tech-writing/overview?hl=zh-cn Technical Writing Courses Every engineer is also a writer. This collection of courses and learning resources aims to improve your technical documentation. Learn how to plan and author technical documents. You can also learn about the role of technical writers at Google. Overview of technical writing courses The following table summarizes the technical writing courses: Take this course… Title Focus Pre-Class In-Class first Technical Writing One the critical basics of technical writing 2 hours 2 to 2.5 hours second Technical Writing Two intermediate topics in technical writing 1 hour 2 to 2.5 hours The pre-class components introduce topics; the in-class components help students integrate those topics. That said, the pre-class lessons on their own still provide a valuable educational experience. ...

[TOC] 祈祷式编程 祈祷式编程 如果代码中包含以下代码 或者上线后进行这种活动 那么这种编程方式就是祈祷式编程。 用流程图表示基本就是这个样子。 祈祷式编程有什么危害呢？ 累，每次写完代码还需要再祈祷 不受控，代码运行结果主要看运气，大仙忙的时候可能保佑不了 解决这个问题有好多种方法，单元测试是其中之一。 单元测试 什么是单元测试 单元测试是由开发人员编写的，用于对软件基本单元进行测试的可执行的程序。 单元（unit）是一个应用程序中最小的课测试部分。（比如一个函数，一个类 google 把测试分成小型测试、中型测试和大型测试。单元测试基本和小型测试的作用类似，但是通常也会使用mock或者stub 的方式模拟外部服务。 理想情况下，单元测试应该是相互独立、可自动化运行的。 目的： 通常用单元测试来验证代码逻辑是否符合预期。完整可靠的单元测试是代码的安全网，可以在代码修改或重构时验证业务逻辑是否正确，提前发现代码错误，减少调试时间。设计良好的单元测试某些情况下可以比文档更能反应出代码的功能和作用。 单元测试这么多优点为什么有人不喜欢写单元测试呢？ 单元测试太费时间了，对于编写单元测试不熟练的新手来说，编写单元测试可能比写代码的还费时间 单元测试运行时间太长（这通常是单元测试设计不合理或者代码可测试性较差造成的 祖传代码，看都看不懂怎么写单元测试（这个确实优点棘手。。可以考虑先给新代码加单元测试 不会写单元测试 这篇文章主要关注第四个问题，如何写单元测试。 单元测试的结构 首先看一下单元测试的结构，一个完整的单元测试主要包括Arrange-Act-Assert（3A） 三部分。 Arrange–准备数据 Act–运行代码 Assert–判断结果是否符合预期 比如我们要给下面这段代码（golang）加单元测试： func Add(x, y int) int { return x + y } 单元测试代码如下： import "testing" func TestAdd(t *testing.T) { // arrange 准备数据 x, y := 1, 2 // act 运行 got := Add(x, y) //assert 断言 if got != 3 { t.Errorf("Add() = %v, want %v", got, 3) } } 如何编写好的单元测试 什么样的单元测试才是好的单元测试呢？ ...

题目：设计一个身份证查询系统，将身份证号md5 之后存储，输入md5值查询对应的身份证号。 要求：成本低，查询速度快 设计思路： 将所有可能的身份证号做一个简单的统计计算数据量 根据数据量选择存储方式 查询 身份证生成规则： 身份号码是特征组合码，由前十七位数字本体码和最后一位数字校验码组成。排列顺序从左至右依次为六位数字地址码，八位数字出生日期码，三位数字顺序码和一位数字校验码。 地址码： 表示编码对象常住户口所在县(市、旗、区)的行政区划代码。对于新生儿，该地址码为户口登记地行政区划代码。需要没说明的是，随着行政区划的调整，同一个地方进行户口登记的可能存在地址码不一致的情况。行政区划代码按GB/T2260的规定执行。 出生日期码：表示编码对象出生的年、月、日，年、月、日代码之间不用分隔符，格式为YYYYMMDD，如19880328。按GB/T 7408的规定执行。原15位身份证号码中出生日期码还有对百岁老人特定的标识，其中999、998、997、996分配给百岁老人。 顺序码： 表示在同一地址码所标识的区域范围内，对同年、同月、同日出生的人编定的顺序号，顺序码的奇数分配给男性，偶数分配给女性。 校验码： 根据本体码，通过采用ISO 7064:1983,MOD 11-2校验码系统计算出校验码。算法可参考下文。前面有提到数字校验码，我们知道校验码也有X的，实质上为罗马字符X，相当于10. 校验码算法 将本体码各位数字乘以对应加权因子并求和，除以11得到余数，根据余数通过校验码对照表查得校验码。 加权因子表： +-----------------------------------------------------------+ |位置序号|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|13|14|15|16|17| +-----------------------------------------------------------+ |加权因子|7 |9 |10|5 |8 |4 |2 |1 |6 |3 |7 |9 |10|5 |8 |4 |2 | +-----------------------------------------------------------+ 校验码表: +----------------------------------------------------+ | 余数 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | +----------------------------------------------------+ | 校验码| 1 | 0 | X | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | +----------------------------------------------------+ 算法举例： 本体码为11010519491231002 ...

在stackoverflow 看到一个问题，Redis strings vs Redis hashes to represent JSON: efficiency?内容如下： I want to store a JSON payload into redis. There’s really 2 ways I can do this: One using a simple string keys and values. key:user, value:payload (the entire JSON blob which can be 100-200 KB) SET user:1 payload Using hashes HSET user:1 username “someone” HSET user:1 location “NY” HSET user:1 bio “STRING WITH OVER 100 lines” Keep in mind that if I use a hash, the value length isn’t predictable. They’re not all short such as the bio example above. Which is more memory efficient? Using string keys and values, or using a hash? ...

前几天写了《markdown 生成头条文章的一个思路》，周末就试了试。 先回顾一下思路，大致流程如下： 这里的三个关键点是： 提取code 把code 转换为html 把html 生成图片 code 替换成图片 第一个很简单，只有用正则表达式就可以解决： _fenced_code_block_re = re.compile(r''' (?:\n+|\A\n?) ^```\s*?([\w+-]+)?\s*?\n # opening fence, $1 = optional lang (.*?) # $2 = code block content ^```[ \t]*\n # closing fence ''', re.M | re.X | re.S) 这个正则来自 python-markdown2: https://github.com/trentm/python-markdown2 这个正则只匹配了 ``` 样式的代码，对于前边有四个空格的并没有做处理（也不想做处理，还是严格一点好）。 第二个也不麻烦，只需要把提取出的code 放到html 中，下面是一个html模板： <html> <head> <link rel="stylesheet" href="http://media.gusibi.mobi/highlight/static/styles/atom-one-dark.css"> <script src="http://media.gusibi.mobi/highlight/static/highlight.site.pack.js"></script> <script>hljs.initHighlightingOnLoad();</script> </head> <body style="width: 640px;"> <pre> <code class="{{.Language}}">{{.Code}}</code> </pre> </body> </html>` 这里有一个点是渲染html 页面的时候， 由于加载html 页面的工具都是get请求，这里我们需要先把code 数据保存起来。所以请求code 的html 页面分成了两步。 ...

最近在头条上写东西，遇到了一个比较烦的事情—编辑器不支持代码。这对于一个像我这样使用代码凑字数的人来说实在不是一个好的消息。但是等头条改进编辑器太遥远了，只能自己自足实现一个替代方案了–把代码替换成图片。 一段代码的时候，我随手截图，简单完成了； 两段代码的时候，我随手随手截图，也完成了； 三段代码的时候，我随手随手随手截图，强忍着完成了； 等我发现代码越来越多的时候，不能忍了。 懒惰是程序员的美德，不能再花费时间干这些事情了。我觉得要写个程序，把markdown 中的代码自动生成图片。 考虑了一下，大概需要做的工作是： 把markdown 中 “ ” 包换的代码提取出来（也可以使用工具先把markdown 转换成html 再解析html 取出code 把每一段code 分别生成图片 把图片对应的代码替换掉 想想还是很简单的。那就开始吧。 但是到第二步的时候遇到了问题，code 如何生成图片，生成什么样的图片？ 首先code 需要保持原有的样式，如果能高亮那就更好了（嗯，高亮 生成图片的时候是把code 作为文字使用PIL（我使用python）写在背景上么，图片大小是多少，高亮怎么实现 算了，还是先把code 生成html，然后截取html页面吧。（这样html 还能使用 highlight.js 来实现高亮） 如何动态生成包含code 的html 页面呢？ 如何把截取html 页面呢？ 动态生成包含code 的html 页面有两个思路： 使用post 请求，把code 写入数据库（或者文件），然后返回id，再使用id GET 请求获取页面（需要存储，两次请求） 压缩code，把code 作为url参数，使用GET请求获取页面（可能会造成url太长的错误） 那如何截取html呢？ 如果是python，可以使用pyqt，渲染html页面，截取webview。 如果使用node，可以使用 html2canvas。 大致流程如下： 哎，这一篇没有代码，就凑不了多少字。 最后，感谢女朋友支持和包容，比❤️ 也可以在公号输入以下关键字获取历史文章：公号&小程序 | 设计模式 | 并发&协程 内推时间

json 简介 JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。 易于人阅读和编写。同时也易于机器解析和生成。 它基于JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集。 JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯（包括C, C++, C#, Java, JavaScript, Perl, Python等）。 这些特性使JSON成为理想的数据交换语言。 JSON支持两种数据结构存在： 对象（object）：一个对象包含一系列非排序的名称／值对(pair)，一个对象以{开始，并以}结束。每个名称／值对之间使用 : 分割。 数组 (array)：一个数组是一个值(value)的集合，一个数组以 [ 开始，并以]结束。数组成员之间使用 , 分割。 具体的格式如下： [value1, value2, value3] 名称／值（pair）：名称和值之间使用 : 隔开，格式如下： {name:value} 名称必须是字符串类型； 值(value)必须是可以是字符串(string)，数值(number)，对象(object)，有序列表(array)，或者 false， null， true 的其中一种。 JSON的格式描述可以参考RFC 4627。 为什么JSON不支持 int64 类型？ 通过上面的介绍有两个关键点： JSON 是基于 JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集 JSON 支持number 类型 Javascript的数字存储使用了IEEE 754中规定的双精度浮点数数据类型，而这一数据类型能够安全存储 -(2^53-1) 到 2^53-1 之间的数值（包含边界值）。JSON 是Javascript 的一个子集，所以它也遵守这个规则。 ...

json 类型 说明 根据RFC 7159中的说明，JSON 数据类型是用来存储 JSON（JavaScript Object Notation）数据的。这种数据也可以被存储为text，但是 JSON 数据类型的优势在于能强制要求每个被存储的值符合 JSON 规则。也有很多 JSON 相关的函数和操作符可以用于存储在这些数据类型中的数据 PostgreSQL支持两种 JSON 数据类型：json 和 jsonb。它们几乎接受完全相同的值集合作为输入。两者最大的区别是效率。json数据类型存储输入文本的精准拷贝，处理函数必须在每 次执行时必须重新解析该数据。而jsonb数据被存储在一种分解好的二进制格式中，因为需要做附加的转换，它在输入时要稍慢一些。但是 jsonb在处理时要快很多，因为不需要重新解析。 重点：jsonb支持索引 由于json类型存储的是输入文本的准确拷贝，存储时会空格和JSON 对象内部的键的顺序。如果一个值中的 JSON 对象包含同一个键超过一次，所有的键/值对都会被保留（** 处理函数会把最后的值当作有效值**）。 jsonb不保留空格、不保留对象键的顺序并且不保留重复的对象键。如果在输入中指定了重复的键，只有最后一个值会被保留。 推荐把JSON 数据存储为jsonb 在把文本 JSON 输入转换成jsonb时，JSON的基本类型（RFC 7159 ）会被映射到原生的 PostgreSQL类型。因此，jsonb数据有一些次要额外约束。 比如：jsonb将拒绝除 PostgreSQL numeric数据类型范围之外的数字，而json则不会。 JSON 基本类型和相应的PostgreSQL类型 JSON 基本类型 PostgreSQL类型 注释 string text 不允许\u0000，如果数据库编码不是 UTF8，非 ASCII Unicode 转义也是这样 number numeric 不允许NaN 和 infinity值 boolean boolean 只接受小写true和false拼写 null (无) SQL NULL是一个不同的概念 json 输入输出语法 -- 简单标量/基本值 -- 基本值可以是数字、带引号的字符串、true、false或者null SELECT '5'::json; -- 有零个或者更多元素的数组（元素不需要为同一类型） SELECT '[1, 2, "foo", null]'::json; -- 包含键值对的对象 -- 注意对象键必须总是带引号的字符串 SELECT '{"bar": "baz", "balance": 7.77, "active": false}'::json; -- 数组和对象可以被任意嵌套 SELECT '{"foo": [true, "bar"], "tags": {"a": 1, "b": null}}'::json; -- "->" 通过键获得 JSON 对象域 结果为json对象 select '{"nickname": "goodspeed", "avatar": "avatar_url", "tags": ["python", "golang", "db"]}'::json->'nickname' as nickname; nickname ------------- "goodspeed" -- "->>" 通过键获得 JSON 对象域 结果为text select '{"nickname": "goodspeed", "avatar": "avatar_url", "tags": ["python", "golang", "db"]}'::json->>'nickname' as nickname; nickname ----------- goodspeed -- "->" 通过键获得 JSON 对象域 结果为json对象 select '{"nickname": "goodspeed", "avatar": "avatar_url", "tags": ["python", "golang", "db"]}'::jsonb->'nickname' as nickname; nickname ------------- "goodspeed" -- "->>" 通过键获得 JSON 对象域 结果为text select '{"nickname": "goodspeed", "avatar": "avatar_url", "tags": ["python", "golang", "db"]}'::jsonb->>'nickname' as nickname; nickname ----------- goodspeed 当一个 JSON 值被输入并且接着不做任何附加处理就输出时， json会输出和输入完全相同的文本，而jsonb 则不会保留语义上没有意义的细节 ...

《代码大全》读书笔记 太长不看版 软件构建中的设计 软件设计是一项明确的活动 设计中的挑战 软件设计一词意味着去构思、创造或发明一套方案，把一份计算机软件的规格说明书要求转变为可实际运行的软件。 设计就是把需求分析和编码调试连接在一起的活动。 好的高层词设计能够提供一个可以稳妥容纳多个较低层次设计的结构。 设计是一个险恶的问题 险恶（wicked）的问题就是那种只有通过解决或部分解决才能被明确的问题。 Tacoma Narrows 大桥是一个险恶问题的好例子，因为直到这座桥坍塌，工程师才知道不应该只考虑桥的负荷，还需要充分的考虑空气动力学因素（只有建造大桥，才能从中学到需要考虑额外的环节）。 设计是一个了无章法的过程（即使它能得处清爽的成果） 是因为在设计的过程中可能会采用很多错误的步骤，多次出错 因为设计的优劣差异往往非常微妙 因为不能判断设计是否足够好 设计就是确定取舍和调整顺序的过程 现实世界中，设计者工作的一个关键内容就是衡量彼此冲突的各项设计特性，并尽力在其中寻求平衡。响应速度优先和开发时间短优先得出的设计结果可能是不同的。 设计受到诸多限制 设计的要点一部分是在创造可能发生的事情，另一部分是在限制可能发生的事情。 如果一个人有无限空间和资源来建造房子，可能会建造出无法控制的建筑。正是因为有了限制，才得出了简单的结果。软件设计也是一样。 设计是不确定的 每个人设计的结果可能是不同的，并且可能用起来都不错。设计没有标准答案。 设计是一个启发式的过程 设计过程中充满了不确定性，因此设计技术也趋于具有探索性–“经验法则”或者“试试没准能行”–而不是保证能产生预期结果的可重复的过程。 设计是自然而然形成的 设计不是在谁的头脑中直接跳出来的，它是在不断的设计评估、非正式讨论、写试经验以及修改试验代码中演化和完善的。 关键的设计概念 软件的首要技术使命：管理复杂度 本质的难题和偶然的难题 偶然的难题可以理解为bug，编程语言笨拙的语法，等易于发现容易解决的问题。 本质的难题则比较复杂，本质上说，软件开发就是不断去发掘错综复杂，相互关连的整套概念的所有细节。本质困难就是： 要面对复杂、无序的现实世界； 精确而完成的识别出各种依赖关系和外部情况 设计出完全正确而不是大致正确的解决方案 。。。 管理复杂度的重要性 一个失败的项目如果是由于技术原因而失败，通常都是因为软件复杂度失控了。如果复杂度失控，那么软件就会变得极端复杂，没有人知道它能做什么，它出了问题如何解决。 管理复杂度是软件开发中最为重要的技术话题。 在软件架构层次上，可以通过把大的系统分解为多个子系统来降低问题的复杂度，多个简单的问题比一个复杂的大问题更容易理解。 子系统相互间应该减少依赖； 子系统的关注点应该是相互分离的。 如何应对复杂度 高代价、低效率的设计源于下面三种根源： 用复杂的方法解决简单的问题 用简单但错误的方法解决复杂的问题 用不恰当的复杂的方法解决复杂的问题 用下面的方法管理复杂度 把任何人在同一时间需要处理的本质复杂度降到最低 不要让偶然性的复杂度无谓的增长 理想的设计特征 最小的复杂度 易于维护 松散耦合 可扩展性 可重用性 高扇入：让大量的类使用某个给定的类。（意味着设计出的系统很好的利用了在较低层次上的工具类 低扇出：让一个类少量或始终的使用其他类。（高扇出（7个）意味着一个类过多的使用了其他类，可能会变得过于复杂 可移植性 精简性：没有多余的部分 层次性：比如一个新系统会用到很多设计不佳的旧系统，这时就应该为新系统编写一个负责同就代码交互的层（代理模式） 层次性能把低劣的代码紧闭起来 如果能最终抛弃或重构旧代码，旧不必修改处交互层之外的任何新代码。 标准技术：用到的外来的、古怪的东西越多，也越难理解。 设计的层次 1. 软件系统（Software System） 2. 分解为子系统或包（Division into Subsystems or Packages） 这一层的主要目的是确定如何把程序分为主要的子系统，并定义清楚允许各子系统如何使用其他子系统。 ...