Draft
草稿整理区(暂时没时间继续维护)
- 1.惊艳系列文章分享:用「增量」思想提升代码检查和打包构建的效率 https://musicfe.dev/delta-mind/ 具体原理是使用 git diff 找到需要构建的资源。 文章很久之前读过,当时留下来挺深的印象,惊讶系列的知识实在太难遇到了..
- 2.学到一个名词:语法噪音 syntactic noise is syntax within a programming language that makes the programming language more difficult to read and understand for humans. 你有想到哪些语法噪音呢。
- 3.设计 内部 DSL ,在我看来就是设计面向开发者的 UI。C# 的 linQ 无疑是实用性与优美性兼得的DSL。
- 4.
- 5.好文分享:好文很难遇到,且行且珍惜。 RxJS 的事件组合机制, 太利于对View 驱动抽象了,惊讶。 refresh$ = merge(clickRefresh$, autoRefresh$, pullRefresh$));
- 6.故事分享:A short history of ReScript (BuckleScript) https://discuss.ocaml.org/t/a-short-history-of-rescript-bucklescript/7222一个Ocaml狂热爱好者与他的一个想法 到 实践 推出 ReScript 的故事。 作者开发了 一个比编译器还复杂的解释器,找到了作者的知乎账号: https://www.zhihu.com/people/hongbo_zhangA: 原来是国人..B: 张宏波大神A: 之前只是听说过 ocaml,原来这么强大的一门语言。
- 7.快餐文分享:目前 Web 还不支持复制多个文件,文件夹,Gif 动图... 里面涉及了 之前我们讨论过的 复制图片的点.
- 8.分享篇文章: Build a Regex Engine in Less than 40 Lines of Code https://nickdrane.com/build-your-own-regex/40 行写一个简易的正则引擎~文章简单易懂, 推荐阅读.
- 9.想讨论下关于 React 状态管理的问题..随着项目的迭代, React 的项目慢慢 分成了 状态管理库(Redux)中的状态 与 组件内 部的状态..感觉状态越来越混乱了..这应该是一个现代前端项目无法绕过的问题.. 全局中的状态 往往都是 很多组件需共用的状态, 组件内部一般都是 关于该组件的 UI 状态..这是我目前的划分, 有什么更好的实践嘛? 总觉得没有统一美..业界感觉除了 rxjs 也没有什么其他的实践, mobx 那一套 感觉只是加了成 proxy 的概念可以想想.. 感觉这块状态管理有痛点欸..想出来你就是下一个 Dan
- 10.A: 每天调UI库的API,调到不知道该怎么提升...B: 可以提升到 如何在繁琐的业务中提升自己的主题。加班只是为了自己的今天,提升自己是为了自己的明天,有多少人只有今天没有明天,当你加班缓过神来,一定要努力提升自己。具体来说,提升就是学习嘛~ 如何学习呢,这个话题就大了。我不想提什么广度,方向,学习资源这些横向的事,想讨论下竖向的事情。 其实这也是老生常谈的话题了,我分享下我的学习方法。每天读各种文章,不管是什么方向,什么领域,从这些信息中提取关键信息 反馈到自己的系统,增强与其他知识的联系。 关于如何读书,又是一个很大的话题了。我一般都是先简单过一遍,没有兴奋的点就pass,如果有就精度几遍,读的时候一定要思考,提问。 就比如一个应用层的框架,一定要思考到操作系统层面。 呃,以上观点 主观性极强,你可以做个参考..A: 我感觉还是主观能动性B: 哦,你说这点嘛,我理解。A: 我有时候读着读着就发现我需要a知识点,然后读a知识点又发现b知识点不知道,然后去读b...B: 哇,我超喜欢这个过程..大把的知识~B: 我只是知识的搬运工,自己创造不了新的知识理论.. 太菜了
- 11.七天沉淀计划,还有同学要参加吗? 我具体讲一下:意义我再补充下,关于上面的群体性,大家可能理解的不是很全面,具体指的是,当你进入到一个群体时,你的上进心 就会被潜意识地挖掘。每天都是由事情所驱动,不会有所懈怠,尽可能的不浪费时间。想参加的同学可以试一下,不需要 7 天全部,也可以单独两三天这样。
- 12.对齐工程师可还行
- 13.GUI 表达语法 的扩展程度超出我的想象。关于刚刚分享工具详细介绍: A soft introduction to Remotion https://www.youtube.com/watch?v=szh2Qgo9SVE&ab_channel=uidotdevThis new tool merges the video creation process with software development concepts like source code control. You don’t create videos, you program them.
- 14.A: 列举一下 目前我了解到的 React render domain:Web、App、PDF、CommandLine、Sketch、Video、PC native software,几乎所有可想象到的终端~现在看来 ,React 的架构设计(core 与 render 的分层)真包含着大智慧。A: hah 我看过这篇文章,关注作者很久了,是位白学家大佬 他之前写过一篇实现v8引擎B: 受益匪浅
- 15.A: 为什么python在科学计算这么火呢?是因为研究者喜欢吗?我一直搞不清..B: 因为大部分库都是写给py的吧C: 动态类型, 运算符重载,调c方便A: 好吧~_~ 运算符重载 是挺酷的,但是对工程化的提升不大.. 好吧,灵活性与工程化本来就很难兼得
- 16.
- 17.
- 18.实用函数式编程技巧: Combinator Pattern https://juejin.cn/post/6919302763306287117 好文分享。 好文不易,受教了。 尤其是讲 rxjs 与 函数组合概念章节 很赞,文中的 demo 将 generator 与 fp tools 结合 给了我另一个视角去思考迭代器。非常建议阅读。
- 19.
- 20.帖子中 有人说 dll 的主要作用有 2 个,一个是代码复用,另外一个是节省内存。 我再补充下,还有混淆加密关键文件的作用。
- 21.虽然文章不长,但是我觉得在工作中确实会被一些除技术外的事情影响进度,如何提高效率很重要
- 22.vs stories 插件作者 ben今天推出了 最近研发的vscode clubhouse 插件~ 执行力max..I built an audio social network that's going to be the next billion dollar unicorn. https://dogehouse.tv https://github.com/benawad/dogehouse
- 23.hah 它终于来了。React renderer to build Node.js server 感觉也就是一个玩具,使用 JSX 表达,让我想起了 使用 xml 配置 tomcat .. 实用价值几乎为0..
- 24.B: 可以衍生谈一谈这点:JSX 最初是用来描述 GUI 的,最大的特点是 可以在 GUI 内部包含逻辑,包含状态。而编程其实就是在写 UI,这里的 UI 是一个更高层次的,指的不仅是 Web,Command,还有面向开发者的 UI。在设计接口,设计API时,从另一个角度来看,我们本质上是在写UI。并且 声明式编程范式,也是一种很好的体现。JSX 代表的是一种表达方式,一种可以很好切合 声明式范式 需求的语义方案。关于声明式编程 其实可以多谈一谈。如果用一句话概况声明式编程的话,它最大的特点是: 它的所有语义表达, 只是在声明要做什么,具体怎么做,剩下的它不需要关心,只需要交给编译器。函数式编程其实就是声明式编程的一种体现。一些业界典型实践有,sql ,graphql,jsxA: 与声明式对应的是啥来着 OO?B: 不不不,oo 其实算不上是语义范式,是命令式的建模我觉得没有对应的,只是思考的层次不同吧。C: 声明式对应命令式吧 比如gui开发,声明式比如HTML,命令式比如qtB: 命令式 感觉和 声明式的思想一样的,只不过是被声明的对象不同。声明式的出发点是开发者,命令式的出发点是 编译器,操作系统,运行时。 照这么说,感觉所有语义范式 应该都是声明式的,只不过是声明粒度不同而已。而 oop 与 fp,算不上语义范式,是编程范式。oop 对应建模,状态传递,fp 对应 状态映射,其实 oop 与 fp 之间的关系很近的。A: 嗯,实际写代码的时候我基本都不 care 声明式还是命令式啥的范式。。按直觉去写了 B: hah 我除了遵循 fp 的编程规范外,做到最多的事 就是隔离状态。
- 25.A: 之前我看 Go web frame 源码时,经常看到使用前缀tree做路由匹配 其实是字典树,也叫字母树的一种应用。B: trie树 leetcode上刷到过
- 26.24 年前... 都比我大了。
- 27.Q: 给你一个 fetch 函数,fetch => Promise<Data>. 请你实现 请求 8 秒无结果后,超时报错的机制。A: ablortController 加上promise.race Q: 回答上了 promise.race 就成功了。
- 28.分享篇多年前看过的好文,出自黄峰达老师之手:演进:如何用练习快速提升技术对最开始刚学计算机的我,产生了很大的影响,还记得看完后 我练了一周的指法... 当时看完真是 收益匪浅,现在看了一遍 没多少感觉了..
- 29.分享篇 科普文章:
- 30.分享篇文章:作者的一个观点我很赞同:编程语言的语法就是开发者的用户界面。很大程度上,编程语言的风格决定了开发人员的思维风格,编程语言的局限也会成为开发人员的思维局限。
- 31.mutex 是 mutual exclusion 的简写,翻译一下:互相排斥。
- 32.人每天只有八个小时工作时间,谁都一样。其中能高效工作的时间绝对不超过4个小时。 这些工程师编写的代码行数绝对不算多,但从事的项目影响大。 比如 Pike,大部分时间花在了审查其他成员的 Go 代码上。而一个刚入行的 Golang 工程师,每天的任务就是写作 Go 的标准库,今天写 http 明天写 sort,写的比 Pike 多很多。 考核时,高级工程师因为带领着高效团队,每季度 OKRs 上都有诸多亮点;而刚入行的工程师,只能报告一些比较琐碎的成就。 这个观察近乎于常识,然而对于当时的我来说是一个顿悟:做出 MapReduce 框架的和写琐碎 MapReduce 程序的工程师之间的差距并不是他们的工具和编程效率,也往往不是教育背景或者经验,而是他们各自的杠杆:所带领的团队。问题是,没有人会给你这个杠杆。
- 33.自由过了火~
- 34.
- 35.刚刚学到两个快捷键,在 Chrome 下键入:
- 1.Command + up arrow:页面滚动至顶部
- 2.Command + down arrow: 页面滚动至底部 平时都是用 vimium 的 G 与 gg...
并且在 Finder 中键入:- 1.Command + up arrow:返回上一目录
- 2.Command + down arrow: 返回刚刚的目录 这些快捷键 与 鼠标手势,剪切板手势结合 简直完美~
- 36.如何监听 React 应用的性能:
- 1.使用 React 官方提供的 Development tool plugin 中的 Profiler panel,控制台可见
- 2.与上面类似,使用 React 提供的 Profiler 组件,在 onRender props 中可以拿到渲染的信息。
- 3.使用 Chrome Dev Tools 的 performance tab,使用之前需要禁用 React Development tool 插件,不然会影响性能,记录之后 在 timing 中有查阅。
- 4.使用 performance api 拿到信息,不过经常用于埋点。
- 37.React 组件测试的两种场景:
- 1.组件 snapshot 测试,常见的工具有 jest
将组件渲染出来的元素截取 与预期元素做判断,可以看做一种断言测试。2. e2e 测试(end to end),一般使用 headless browser 作为测试工具,常见的工具有 cypress在“真实”环境下,模拟用户运行应用测试。测试的类别:单元测试,集成测试,冒烟测试 等...随便提下:AB 测试与灰度发布 其实是一种概念,AB 测试可以看做带有埋点系统的灰度发布。 之所以这么划分,在我看来 是因为出发点的不同。 AB测试 是从产品,数据角度。 灰度发布 是从运维,开发角度。 - 38.A: 可以讨论下 测试驱动开发。业界俗称 TDD测试驱动开发 我觉得最关键的是 分场景。 需要质量保障,可以按模块分期迭代的场景比较适合。因为我从来没写过测试,所以对它的解决的痛点不是很了解。B: 先编写测试 测试飘红写业务代码,然后绿了在重构,红绿红绿A: 原来这就是 测试驱动开发,还能被绿,开心。感觉最好的测试 就是防御性编程了。我指的是,开发时遵守规范,如果当复杂性很难控制 或者 数据流模糊不清,就是测试失败了。我感觉很多时候,先写测试用例,大概率会重写,因为有的点 只有开发时才会意识到...还是看测试粒度吧.. B: 我觉得tdd是个好的锻炼思维逻辑还有对后期代码维护调试的方法传统的tdd应该就是先写测试,不写业务代码,全权由测试引出需要抽象的那些,看过一些大佬码代码的过程 是啊,正常写代码也是迭代的过程吧,那些点就是重构的阶段了也符合tdd A: 哦,看起来 测试驱动 应该是强调 思维重心,先由 测试引出设计,这个听起来挺厉害的... B: 是啊,而且先写测试也能强迫你出松散耦合的设计 而且测试可以当做文档使用A: 了解,测试当文档使用,指的是测试的伪代码吗?还是说 测试有一套 dsl 可以描述信息? 感觉 tdd 并不适合UI开发。 B: 一个测试对应一个功能,一个测试对应一个类 加上测试方法命名规范,基本上就知道这个测试 A: 我刚刚想了下,感觉 tdd 的适用性 与 前端(这里泛指GUI)与后端开发模式的不同存在很大关系。 今天早上看了一篇文章,写的很有道理,关于GUI 开发复杂性。The complexity that lives in the GUI https://blog.royalsloth.eu/posts/the-complexity-that-lives-in-the-gui/ 文章把主要的痛点 都归结于组件之间的状态管理。 正因为组件(模块,单元,类 一种概念)之间的状态 划分不清,开始设计时 很难把所有的 UI 状态,数据状态都想到位。
- 39.分享两篇关于介绍 React-Native 比较简明的文章:
- 1.
- 2.
- 40.分享个好玩的项目:GTA3 罪恶都市源代码 全局搜了下 nuttertools 居然啥也没找到,这不是真的罪恶都市
- 41.想讲讲 客户端缓存,也就是只有静态页面,没有服务端的应用 该怎么利用好缓存,让页面加载更快。 我在这方面有一些实践,因为我的网站是一直是托管在 github page 和使用 jsdriver cdn 这样的,除了域名 没有买过服务器,所以网络请求的优化也无法涉及,只能从客户端性能这边入手。 但是 只讲下 页面缓存,其他优化的点 暂时不涉及。 我最开始使用的页面缓存 很蠢,我把关键 css,js 的内容保存到 localStorage 中,然后页面 onload 时,判断是否命中,命中的话读取,反之拉取数据。 这是真的,我大二的实践,当时还写了一个简单的版本管理... 唯一的性能就是 从磁盘与从网络 读取 的速度不同了,但是由于 localStorage 最大 5 mb ,没办法继续。 然后我开始想办法 在用户进入我的首页时,就把其他页面的资源加载好,就比如我其中一个实践是:在用户进入 tomotoes.com 时,会加载一个display:none 的 blog 页面的 iframe,然后用户大概率会进入到博客,此时 博客的所有资源都是从 内存中加载的,超快。 但是很明显,牺牲了首页的性能换来了其他页面的性能提升。 然后,我就开始钻研起了 pwa-service-worker 的 缓存机制 A: 这种像是prefetch啊 是的,不过我的优先级很高,hh~ 关于全站上 sw 这事我做了一周多,因为我的网站分为多个子站点,而每个站点的技术栈不同,打包的机制不同,想把所有站点全上 sw 缓存 就必须把所有打包机制全统一化,就比如 主页使用 gulp,博客使用 hexo,关于页 webpack 等等。 其实 sw 缓存还有代理的功能~ 配置项很多,玩法就很多
- 42.注意,module 文件 A 中 import 的其他文件(B,C) 加载机制是不同的。
- 1.A 与 BC 是串行加载,只有 fetch A 之后 才能加载 B C
- 2.B 与 C 是可以并行加载
- 43.好家伙,Windows 又新增了一种设计系统.. 之前的 WinXP,Win7 拟物,Win10 Fluent Design 还不嫌乱嘛..
- 44.
- 45.分享一个数据结构的基础知识:
- 1.树是图的联通无环类型
- 2.链表是树的非叶节点只有一个子节点类型
- 46.提个观点,平衡二叉树(AVL)树 是二分搜索在存储结构设计上的体现。A: 在学红黑树,突然联想到的一个概念.. B: 我之前面试的时候,让我手撕红黑树 A: 之前X给我讲过 java hashmap 的底层设计。 hashmap 不可避免的问题是 hash 冲突,解决 hash 冲突的两种办法: 开放寻址,链式解决。 java hashmap 的设计是当相同地址,冲突的元素小于等于 8 时,是链表挂载;当大于 8 时会变成一根红黑树(当然概率很小)。 所以说 hashmap 存取 都为 O(1) ,在 java 的 hashmap 某些场景中(冲突数大于 8)是不成立的。 当然 O(1) 本身就是个伪命题,感兴趣可以延伸讨论下 之前我的观点(聊天记录搜索 大 O符号表示法) C: 解决哈希冲突还可以在哈希 推荐一个红黑树操作的可视化演示网址
- 47.
- 48.安利下 三款命令行应用:
- 1.
- 2.
- 3.
一些其他的 autojump fzf ni bat git-extra gacp silver-searcher ... - 49.分享个项目:使用 CSS HTML JS 构建的 50 个小项目,代码质量可以、项目也都很不错,可以作为练手项目。 比如使用 React Hooks + TS 重写一些例子。 下面是我重写 ToDo App 的一个例子: https://github.com/Tomotoes/50projects50days-react/blob/master/src/todo-list/index.tsx
- 50.这买了血赚,才 20k
- 51.分享篇文章(官方faq):
- 52.分享个项目:apankrat/nullboard https://github.com/apankrat/nullboard Nullboard is a minimalist kanban board, focused on compactness and readability.53kb 的“单页面”看板应用,看了下源码 太强了.. 该应用使用 jQuery 写的,假如是 React 的 会是什么形式呢? 首先一定会分隔成多个组件,每个组件有多种状态... 这种 jQuery 一把梭 的方式看起来挺酷的.. 所以说 React 的组件化 与 状态驱动 思想 很利于工程化,在大中型项目中会感受到明显收益,而小型项目中引入(主要还是看场景)多少有点过渡设计的味道。 好吧,这句话没什么价值。 因为项目大小 与 工程化 没有一个很好的鉴定。
- 53.A: 感觉技术的发展有点像个圈子 新的东西也很容易找到以前的影子是啊,计算机领域多久没更新新的理论了,很多基础概念都是89十年代的那群大佬已经定下的了。 就比如 redux 提倡的全局唯一状态不可修改,纯函数,都是来自 fp 的基础理论。 今天我了解到了一个概念,编程范式会对GC有明显的影响。 我想说的重点不是这句话,而是 我觉得很多基础设施决定了上层的发展,同时也限制了新的创新。 举个例子,假如从一开始就不是冯诺依曼体系的计算机,而是细胞自动机或者其他体系,还会有并发原语,数据结构等这些概念的出现嘛。
- 54.今天还和一朋友讨论 css 的设计,不正交性,理论耦合过深。 我相信很多同学从一开始接触前端 都用过dreamweaver,它支持可视化搭建界面,就像 winform,android studio那样,为什么它没有继续流行起来? 我相信在以后(现在 low code 平台已经成为了大厂绩效的风向标),一定会再出现的。
Last modified 2yr ago