├── README.md ├── book ├── CSS设计指南.md ├── Linux-Unix设计思想.md ├── css世界.md ├── img │ ├── 01 │ │ ├── 1.webp │ │ ├── 2.webp │ │ ├── 3.webp │ │ ├── 4.webp │ │ ├── 5.webp │ │ ├── 6.webp │ │ ├── 7.webp │ │ ├── 8.webp │ │ └── 9.webp │ └── 02 │ │ ├── 01.png │ │ ├── 02.png │ │ ├── 03.png │ │ ├── 04.png │ │ ├── 05.png │ │ ├── 06.png │ │ ├── 07.png │ │ ├── 08.png │ │ ├── 09.png │ │ ├── 10.png │ │ └── 11.png ├── linux-screen常用命令.md ├── vimtutor教程.md ├── 前端工程化体系设计和实践.md ├── 图解http.md ├── 图解tcp-ip.md ├── 数学之美.md ├── 松本行弘的程序世界.md ├── 深入浅出nodejs.md ├── 第三方javascript编程.md ├── 网络是怎么连接的.md └── 跨终端web.md └── video ├── docker入门.md ├── img ├── 0.png ├── 1.png ├── 10.png ├── 11.png ├── 12.png ├── 13.png ├── 14.png ├── 15.png ├── 16.png ├── 17.png ├── 18.png ├── 19.png ├── 2.png ├── 20.png ├── 21.png ├── 22.png ├── 23.png ├── 24.png ├── 25.png ├── 26.png ├── 27.png ├── 28.png ├── 29.png ├── 3.png ├── 30.png ├── 31.png ├── 32.png ├── 33.png ├── 34.png ├── 35.png ├── 36.png ├── 37.png ├── 38.png ├── 39.png ├── 4.png ├── 40.png ├── 41.png ├── 42.png ├── 43.png ├── 44.png ├── 45.png ├── 46.png ├── 47.png ├── 48.png ├── 49.png ├── 5.png ├── 50.png ├── 51.png ├── 52.png ├── 53.png ├── 54.png ├── 55.png ├── 56.png ├── 57.png ├── 58.png ├── 59.png ├── 6.png ├── 60.png ├── 61.png ├── 7.png ├── 8.png └── 9.png ├── img1 ├── 1.png ├── 10.png ├── 11.png ├── 12.png ├── 13.png ├── 14.png ├── 15.png ├── 16.png ├── 17.png ├── 18.png ├── 19.png ├── 2.png ├── 20.png ├── 21.png ├── 22.png ├── 23.png ├── 24.png ├── 25.png ├── 26.png ├── 27.png ├── 28.png ├── 29.png ├── 3.png ├── 30.png ├── 31.png ├── 32.png ├── 33.png ├── 34.png ├── 35.png ├── 36.png ├── 37.png ├── 38.png ├── 39.png ├── 4.png ├── 40.png ├── 41.png ├── 42.png ├── 43.png ├── 5.png ├── 6.png ├── 7.png ├── 8.png └── 9.png ├── redis入门.md ├── webpack4.md ├── 与mysql零距离接触.md ├── 操作系统.md ├── 数据结构与算法.md ├── 汇编语言.md ├── 编译原理.md └── 计算机组成.md /README.md: -------------------------------------------------------------------------------- 1 | # read-notes 2 | 3 | 做任何事情都要有产出，读书也一样，读书最合适的产出就是总结读书笔记。产出不在于多少，几行文字、一个表格或者一幅流程图也可以。产出也不在于 100% 看懂书的所有内容，把看不懂的总结出来，也是产出。 4 | 5 | 此前读书，记录笔记比较零碎，甚至有些时候看完书就没记录笔记。现在统一将读书笔记放在这里，后续每读完一本书都在这里总结记录，此前读完的书也会陆续复读并重新总结笔记。 6 | 7 | 看书不能以看完了为目的，如果看完了书之后提笔一字写不出，那基本等于没看。 8 | 9 | ## 读书 10 | 11 | - [《前端工程化体系设计和实践》](./book/前端工程化体系设计和实践.md) 12 | - [《第三方 javascipt 编程》](./book/第三方javascript编程.md) 13 | - [《图解 http 》](./book/图解http.md) 14 | - [《数学之美》](./book/数学之美.md) 15 | - [《跨终端 web》](./book/跨终端web.md) 16 | - [《深入浅出 nodejs》](./book/深入浅出nodejs.md) 17 | - [《Linux/Unix设计思想》](./book/Linux-Unix设计思想.md) 18 | - [《松本行弘的程序世界》](./book/松本行弘的程序世界.md) 19 | - [《CSS 设计指南》](./book/CSS设计指南.md) （待写） 20 | - [《vimtutor教程》](./book/vimtutor教程.md) 21 | - [《screen常用命令》](./book/linux-screen常用命令.md) 22 | - [《CSS世界》](./book/css世界.md) 23 | - [《网络是怎么连接的》](./book/网络是怎么连接的.md) 24 | - [《图解 TCP/IP》](./book/图解tcp-ip.md) 25 | 26 | ## 视频 27 | 28 | - [数据结构与算法](./video/数据结构与算法.md) 29 | - [操作系统](./video/操作系统.md) 30 | - [编译原理](./video/编译原理.md) 31 | - [汇编语言](./video/汇编语言.md) 32 | - [计算机组成](./video/计算机组成.md) 33 | - [与mysql零距离接触](./video/与mysql零距离接触.md) 34 | - [redis入门](./video/redis入门.md) 35 | - [docker入门](./video/docker入门.md) 36 | - [webpack 4.x 常用配置汇总](./video/webpack4.md) 37 | 38 | ## 关于作者 39 | 40 | - 关注作者的博客 - 《[深入理解javascript原型和闭包系列](http://www.cnblogs.com/wangfupeng1988/p/4001284.html)》《[深入理解javascript异步系列](https://github.com/wangfupeng1988/js-async-tutorial)》《[换个思路学习nodejs](https://github.com/wangfupeng1988/node-tutorial)》《[CSS知多少](http://www.cnblogs.com/wangfupeng1988/p/4325007.html)》 41 | - 学习作者的教程 - 《[前端JS高级面试](https://coding.imooc.com/class/190.html)》《[前端JS基础面试题](http://coding.imooc.com/class/115.html)》《[React.js模拟大众点评webapp](http://coding.imooc.com/class/99.html)》《[zepto设计与源码分析](http://www.imooc.com/learn/745)》《[json2.js源码解读](http://study.163.com/course/courseMain.htm?courseId=691008)》 42 | 43 | 如果你感觉有收获，欢迎给我打赏 ———— 以激励我更多输出优质开源内容 44 | 45 | ![图片](https://camo.githubusercontent.com/e1558b631931e0a1606c769a61f48770cc0ccb56/687474703a2f2f696d61676573323031352e636e626c6f67732e636f6d2f626c6f672f3133383031322f3230313730322f3133383031322d32303137303232383131323233373739382d313530373139363634332e706e67) 46 | -------------------------------------------------------------------------------- /book/CSS设计指南.md: -------------------------------------------------------------------------------- 1 | # 《CSS 设计指南》读书笔记 2 | 3 | 待写…… -------------------------------------------------------------------------------- /book/Linux-Unix设计思想.md: -------------------------------------------------------------------------------- 1 | # 《Linux/Unix设计思想》读书笔记 2 | 3 | 本书总结了 Unix/Linux 这些年积累的一些经验和方法，阅读了解它们对于我们日常的工作、学习帮助和启发非常大，有些甚至能颠覆自己的传统认知（如：避免强制性的用户界面）。本书通过一些准则总结这些经验和思想，我将记录在阅读过程中感觉有趣或者重点的地方。 4 | 5 | 另外值得一提的是，本书已经买不到纸质版了，无奈我下载了 PDF 然后一页一页打印出来的，是在 2017.7.31 ，距今已有半年多时间。 6 | 7 | - 准则1：小即是美 8 | - 准则2：让每个程序只做好一件事 9 | - 准则3：快速建立原型 10 | - 准则4：舍弃高效率而取可移植性 11 | - 准则5：采用纯文本来存储数据 12 | - 准则6：充分利用软件的杠杆效应（软件复用） 13 | - 准则7：使用 shell 脚本来提高杠杆效应和可移植性 14 | - 准则8：避免强制性的用户界面 15 | - 准则9：让每个程序都称为过滤器 16 | - 十条小准则 17 | - 允许用户定制环境 18 | - 尽量使操作系统内核小而轻量化 19 | - 使用小写字母并尽量简短 20 | - 保护树木 21 | - **沉默是金（看下书中 94 页，讲的非常精彩，很受启发！！！）** 22 | - 并行思考 23 | - 各部分之和大于整体 24 | - 寻求 90% 的解决方案（剩余 10% 放弃，**即 2/8 原则**） 25 | - 更坏就是更好 26 | - 层次化思考 27 | 28 | ## 准则1：小即是美 29 | 30 | > 其实我一直有把车换成高尔夫 GTI 的冲动 —— 车小，性能还不错 31 | 32 | 其实这个和准则2（让每个程序只做好一件事）一致，**“小”到什么程度呢？—— 小到只能做好一件事**，这就够了。其他的事，交给其他的程序去做。书中讲到了小的好处： 33 | 34 | - 易于理解和学习。如果你想要写出全世界都是用的程序，那这一点很重要，无论是大牛还是小白，都能轻松是用，才能推广开来。 35 | - 易于维护。即便是自己写的代码，过半年自己都忘记当时写的是什么了，要考虑这一点。 36 | - 消耗更少的资源。“小”到制作一件事，用多少就消耗多少，不做一点额外的开销和浪费。 37 | - 更易于和其他工具结合。即可扩展性更好，符合开放封闭原则。 38 | 39 | ## 准则2：让每个程序只做好一件事 40 | 41 | 这个和准则1（小即是美）表达的意思一致，只做好一件事，说明足够小。越是大型的系统，这个原则越重要，否则越大就越乱。这让我联想到了一个哲学话题 —— **递弱代偿** —— 整体越复杂，个体就越简单、专一，通过相互补偿来完成整体功能。 42 | 43 | 书中列举了一个范例 —— `ls`命令。`ls`本来是很简单的一个命令，现在却搞的有 20 多个参数，而且正在逐步增加。这就使得`ls`慢慢变成一个很庞大的命令，但我们日常 90% 的场景都使用它最简单的功能。理想的做法是，`ls`还保持简洁的功能，另外开发新的命令来满足其他配置参数实现的功能。这就例如，`cat`可查看全部内容，想看头或者尾，分别使用`head`和`tail`——这就分的清晰了。 44 | 45 | ## 准则3：快速建立原型 46 | 47 | **大教堂与集市，我们选择集市**。 48 | 49 | 软件不是汽车，它可以每天都迭代更新，它可以今天发现有问题然后明天修复过来。而且，谁都无法预测它未来将会怎样变化，客户也无法通过语言清楚的描述他们需要的软件。基于以上所有原因，软件都需要先有原型，再不断慢慢完善，这也是一个降低风险、慢慢学习的过程。 50 | 51 | - 永远不要自己猜测用户想要的软件 52 | - 永远不要相信用户开始时描述的他们想要的软件 53 | - 永远不要想一次做完永远不改 54 | 55 | ## 准则4：舍弃高效率而取可移植性 56 | 57 | 越高效的程序往往越不可移植，但是好的程序往往会被移植到各个地方使用 —— 从这里能看出，对于程序来说，最重要的是可移植性，而非高效。 58 | 59 | 至于效率问题，不用花费太多的精力去优化，它会很快因为硬件的更新而得到解决 —— **摩尔定律** 60 | 61 | ## 准则5：采用纯文本来存储数据 62 | 63 | 采用纯文本存储数据，可能没有二进制方式效率高，但是有以下好处： 64 | 65 | - **方便转换格式**：所有系统都支持文本编辑，而且文本的编码规范，业界都是统一标准的。但是对于二进制 —— 每个供应商都提供了自己的二进制编码，切相互不兼容 66 | - **易于阅读和编辑**：首先，文本格式人类一眼就认识；其次，可通过简单的工具进行编辑、编辑完直接保存无需转换；第三，文本格式非常适合 linux 中的管道（pipe）操作 67 | - **易于系统处理**：存储是文本格式，那么 linux 的标准输入输出就可以全部用文本格式，linux 的实用工具只处理文本格式即可。如`grep` `diff`等 68 | 69 | 虽然效率不佳，但是可移植性好，而且易于阅读和操作，这些都是符合本书其他原则的。最后，效率不佳的问题，会通过明年硬件的升级而得到解决（摩尔定律） 70 | 71 | ## 准则6：充分利用软件的杠杆效应（软件复用） 72 | 73 | > NIH —— Not Invent Here ，即要借用（或复用）现有的软件，而不是重造轮子 74 | 75 | 这个道理大家都明白，但是书中有两点我觉得很重要： 76 | 77 | - 软件想要被复用，就得符合工业标准。第一，软件贡献者要熟悉标准；第二，软件使用者也要熟悉标准；第三，当某个软件在业界还没有标准的时候，要勇敢的去自己制定（如 jquery） 78 | - 更多的人贡献软件，开源社区和开源文化很重要 79 | 80 | 81 | ## 准则7：使用 shell 脚本来提高杠杆效应和可移植性 82 | 83 | 感觉和 准则4 、准则6 重复了 84 | 85 | ## 准则8：避免强制性的用户界面 86 | 87 | linux 系统中，CUI 都只是一个普通的软件而已，并不是强行和系统绑定的。如果软件有了强制性的用户界面，会带来各种各样的问题 88 | 89 | - 强制要求用户是人类，但是一个软件的用户很可能不是人类 90 | - 导致软件庞大，占用资源多 91 | - 扩展性差 92 | - 无法发挥杠杆效应 93 | - …… 94 | 95 | ## 准则9：让每个程序都成为过滤器 96 | 97 | > 程序不会创造数据，只有人类才会创造数据。因此，每个程序都仅仅是一个过滤器而已。 98 | 99 | linux 的常用都是过滤器，例如`ls | grep 'README.md'`，就是找出当前目录下的`README.md`文件。其中`ls` `grep`都是过滤器，**过滤器就必须有：输入、输出。** 这其实正好对应着 **linux 的标准输入输出（stdio）—— `stdin` `stdout` `stderr`**。书中简单介绍了 stdio，并不是很详细，我想找个地方单独详细写一下 stdio ，这里就此略过吧。 100 | 101 | ## 扩展 & 遗留问题 102 | 103 | - linux 标准输入输出 stdio 104 | -------------------------------------------------------------------------------- /book/css世界.md: -------------------------------------------------------------------------------- 1 | # 《CSS 世界》读书笔记 2 | 3 | 本书可以说是深入理解 CSS 原理的必读之书，作者张鑫旭也是十年磨一剑，编写了这本独一无二的 CSS 书籍。读其他 CSS 的书籍只能做到知其然，而读这本书却能做到知其所以然。没别的称赞，果断推荐，而且我觉得应该所有的前端开发者都应该好好拜读这本书，以强化自己的 CSS 知识和认知。 4 | 5 | 本书一开始先给大家构建了一个 CSS 的时间观，让读者知道 CSS 在这个缤纷的网络世界中扮演了什么样的角色，有什么价值。接下来，全书以“流”这个 CSS 设计时最核心的思路，来讲了我们开发常用的一些样式和语法，它们如何构建一个“流”的世界。除了“流”之外，本书也讲了其他的内容，不过那不是我关心的重点。 6 | 7 | 最后，本书讲解的内容都是 CSS 2.1 版本的，发布距今都已经 10+ 年了，可以说是最常用、最普及的知识了。CSS 3 的知识本书没有涉及，作者没有解释，但是读到最后我想明白了这个原因 —— 本书立意独特，讲解的都是作者精心准备、读者常不理解或者犯错误的知识点，例如`float`的使用、`line-height`的认知等。而这些易理解出错的方面，CSS 2.1 中有很多，但是 CSS 3 中却很少。因为，CSS 2.1 很多语法的设计初衷和现在的使用场景都不一致，导致很多误解或者误用，而 CSS 3 设计用意和场景完全匹配，误用很少。因此，CSS 3 也就没得讲了，干脆就不讲了。 8 | 9 | 当然，以上的这个原因，纯属我个人的猜测。如有雷同，也属于巧合。最后，再重点强调一下 CSS 2.1 的设计初衷： 10 | 11 | > CSS 2.1 是为**图文展示**而设计的。 12 | 13 | ## CSS 世界观 14 | 15 | 书中这部分内容比较少，但是作者提出来的这个比喻我觉得特别贴切。这么一比喻，就把 CSS 与浏览器、操作系统的关系给一下子说清楚了，生动形象。 16 | 17 | - 操作系统是宇宙，浏览器是王国，css 是一个一个的魔法师，例如`width`魔法师、`font`魔法师…… 18 | - 不同的操作系统就是不同的平行宇宙，比较强大的如 windows, os X, ios, android 19 | - 不同的宇宙中王国的命运不一样，例如 os X 宇宙中 safari 王国比较强大，而 windows 宇宙中 safari 王国就异常没落 20 | - 不同宇宙或者不同王国中，魔法师在法力表现上也不尽相同，如 chrome 王国和 firefox 王国中的魔法师，有些法术可能就不太一样（即浏览器兼容性） 21 | 22 | ## 流 23 | 24 | 书中这部分也内容比较少，但是我觉得“流”这个概念对于本书的阅读和理解非常总要，因此就单拿出来一个大标题来重点说明，可能文字并不多。 25 | 26 | 书中提到，SVG 的标准在 2003 年就发布了，而 CSS 2.1 的标准直到 2007 年才发布，而那时候 web 1.0 已经很普及了，但是最终还是 CSS 战胜了 SVG 成为了网页布局的主导语言。究其原因，第一是因为 CSS 更加适合图文布局，第二就是 CSS 的“流”特性。当然，SVG 后来换发第二春，成为了 canvas 直接的竞争对手，也是因为网页图形化的兴起，这是另外一回事儿。 27 | 28 | “流”，我理解就是它能在不同尺寸的容器中，合理的处理图文信息的这种不确定性，其实就是流动特点。图片可大可小，文字可多可少、字体多变，再加上尺寸多变，这种不确定性只能通过“流”去解决。例如一个不确定尺寸的容器，只能用水来完全填满，而水就具有流动特性。具体 CSS 的例子就不列举了，下文遍地都是，在这里也列举不全。 29 | 30 | ## 元素的尺寸 31 | 32 | ### width 33 | 34 | `width:auto`使用场景很多，表现形式也很多，书中提到以下几种情况： 35 | 36 | - 充分利用可用空间，即流动性。例如`
`会自动铺满整个父容器。 37 | - 收缩和包裹，例如浮动和绝对定位的“包裹性”， 38 | - 收缩到最小，例如表格中每个单元格的文字，会自动收缩 39 | - 超出容器限制，例如其中的内联元素设置了`white-space: nowrap` 40 | 41 | 其中最常用的就是，让`
`铺满父容器时，不要故意设置`width:100%`，因为还可能会有 padding margin border 的宽度影响，让其自适应就好了。 42 | 43 | 针对盒子模型来说，`width`默认作用域`content-box`上，即内容区域。现在的普遍做法是增加`box-sizing: boxer-box`。不过作者的另外一种解决方案也非常体现“流”特性。 44 | 45 | ```css 46 | .father { 47 | width: 180px; 48 | } 49 | .son { 50 | margin: 0 20px; 51 | padding: 20px; 52 | border: 1px solid; 53 | } 54 | ``` 55 | 56 | 最后作者解释了`box-sizing`设计的初衷，让我读来眼界大开。因为我们专业于一门技术，不仅仅要知道 what 和 how ，还要知道 why 。书中提到，**`box-sizing`的设计初衷是为了解决替换替换元素宽度自适应问题**。所谓的“替换元素”可以简单的理解为各种表单元素，例如`input` `textarea` `video` `object` 还有 `img` ，这些元素的样式最难控制。 57 | 58 | 替换元素有一个特点，例如`textarea`，宽度不容易被控制，不具有流动性。即，`div`如果不设置宽度会撑满父容器，而`textarea`则不会。这种情况下，如果没有`box-sizing`的话，我们没法通过控制宽度来实现自适应。例如，如果针对`textarea`设置`width:100%`，是作用域`content-box`，再加上`padding` `border`宽度，就超出父元素了。 59 | 60 | ### height 61 | 62 | > CSS 的默认“流”是水平方向的，宽度是稀缺的，高度是无限的 63 | 64 | 有时候设置`height:100%`无效，是因为**只要父元素是`height:auto`，子元素在文档流中（不是`float`或者`absolute`），那么子元素的高度百分比就被忽略** ，记住这条原则。要想解决这个问题，就得**让父元素必须有一个可以生效的高度值**，例如： 65 | 66 | ```css 67 | html. body { 68 | height: 100%; 69 | } 70 | div { 71 | height: 100%; 72 | } 73 | ``` 74 | 75 | 当然，直接对`div`设置绝对定位，也可以让`height:100%`生效。不过注意，**绝对定位的宽高百分比计算是相对于`padding-box`的，而正常情况下的计算则是相对于`content-box`的**。 76 | 77 | ### 内联元素 78 | 79 | > 块级原则负责结构，内联元素负责内容 80 | 81 | 内联元素不仅仅是`display: inline`，`inline-block` `inline-table`也算是内联元素，其表现就是可以和文字在一行显示。 82 | 83 | 书中提到了“内联盒子模型”，可以对比一下普通的盒子模型。不过这个模型日常使用中基本不会关心到，因此简单列一下，详细内容去看书。 84 | 85 | - 内容区域 86 | - 内联盒子 87 | - 行框盒子 88 | - 包含盒子 89 | 90 | 最后书中提出了一个非常非常非常重要的概念 —— **幽灵空白节点**（作者起的名字），这是日常开发中实时遇到但却实时被大家忽略的一个问题。该问题触发有一个前提，就是必须是 HTML5 文档声明。 91 | 92 | ```html 93 | 94 | 95 | ``` 96 | 97 | 如下例子，这个`div`的高度并不是 0 ，而是 18px 。命名里面什么内容都没有，为何有高度呢？ 98 | 99 | ```html 100 |
101 | ``` 102 | 103 | 其实可以这么理解，**在``前面有一个宽度为 0 的空白字符（即幽灵空白节点）**，它撑起了整个内联元素的高度，也就撑起了`
`的高度。 104 | 105 | 这个空白节点的影响，会出现于没有文字的内联元素场景中，而且基本是以“坑”的形式来出现的。例如，下面代码执行后，`img`和`div`的下边界会有一个空白区域，这是为何？ 106 | 107 | ```html 108 |
109 | 110 |
111 | ``` 112 | 113 | ## 盒模型 114 | 115 | 盒模型是 CSS 的基础知识，它包含四个盒子：content-box, padding-box, border-box, margin-box ，书中也是按照这个顺序来写的，下面针对一些印象比较深的内容做记录。 116 | 117 | ### content 118 | 119 | **替换元素，即可以被替换的元素**。常见的有`` `` `