-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathcontent.json
More file actions
1 lines (1 loc) · 109 KB
/
content.json
File metadata and controls
1 lines (1 loc) · 109 KB
1
{"meta":{"title":"L空间","subtitle":"","description":"Keep going.","author":"longguzzz","url":"https://longguzzz.github.io","root":"/"},"pages":[{"title":"","date":"2022-08-01T12:54:32.702Z","updated":"2022-08-01T12:54:32.702Z","comments":true,"path":"about/index.html","permalink":"https://longguzzz.github.io/about/index.html","excerpt":"","text":"99年后生,毕业于机械工程专业,目前正在积极学习计算机相关的种种知识,磨炼相关能力~ 兴趣爱好广泛。了解稍微比较多的是泰拳,其他兴趣爱好暂时没法投入时间来发展,有待未来逐一解锁。"},{"title":"所有标签","date":"2022-08-01T07:42:47.193Z","updated":"2022-08-01T07:42:47.193Z","comments":true,"path":"tags/index.html","permalink":"https://longguzzz.github.io/tags/index.html","excerpt":"","text":""},{"title":"所有分类","date":"2022-08-01T07:41:59.289Z","updated":"2022-08-01T07:41:59.289Z","comments":true,"path":"categories/index.html","permalink":"https://longguzzz.github.io/categories/index.html","excerpt":"","text":""}],"posts":[{"title":"【20】执行计划的技巧【2023-01-20】","slug":"日知录/【20】执行计划的技巧【2023-01-20】","date":"2023-01-19T16:00:00.000Z","updated":"2023-01-20T16:43:02.616Z","comments":true,"path":"日知录/【20】执行计划的技巧【2023-01-20】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9020%E3%80%91%E6%89%A7%E8%A1%8C%E8%AE%A1%E5%88%92%E7%9A%84%E6%8A%80%E5%B7%A7%E3%80%902023-01-20%E3%80%91/","excerpt":"","text":"发现:打印出的阅读材料,按计划预先分叠,那么每天要完成的事就非常直观,进度如何也非常直观,不再需要反复计算什么的。 关键在于:估计出准确的时间消耗,可用时间量,从而做出可以实现的有意义目标。 在笔记本里安排、记录短期计划,会比在电脑软件里写安排更好。原因在于,随时可以翻阅,大页面,多页间可以快速跳转,也不占电脑屏幕空间……最重要的是,计划只有在现实中执行完成了才有意义,并不一定需要电子化存档,并且是每一天更新一点、完成后就归档(,半永久忽略)。所以,相对于“永久存档、快速复制备份、快速输入大量文字、重新排版组合”这些效果而言,能够快速翻阅、操作简单、反复自我提示、自由表达等效果更重要。(即使需要电子化,也可以扫描+OCR) 当习得了心境和科学方法,便可以做到科学可持续有效积累。剩下的重点则是,怎么安排时间,怎么估准时间。想让“时间”来解决这个问题,那么要做的就是积累有效数据以及分析并优化。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【19】想象力充沛的费曼方法【2023-01-19】","slug":"日知录/【19】想象力充实的费曼方法【2023-01-19】","date":"2023-01-18T16:00:00.000Z","updated":"2023-01-20T15:44:11.267Z","comments":true,"path":"日知录/【19】想象力充实的费曼方法【2023-01-19】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9019%E3%80%91%E6%83%B3%E8%B1%A1%E5%8A%9B%E5%85%85%E5%AE%9E%E7%9A%84%E8%B4%B9%E6%9B%BC%E6%96%B9%E6%B3%95%E3%80%902023-01-19%E3%80%91/","excerpt":"","text":"灵感来源:给老弟传授我已知的学习方法 倘若可以,最好真的去找到一个不懂的人,细细地讲,思考用什么样的思路来讲,从对方的反应获得真实的反馈。相比于自己想象出某个人来讲课,这样的方法会有更多的启发。 所以,在通过想象力使用费曼方法的时候,不应该想象某种抽象的人,应该代入真实的人,这样才会有足够的细节来支撑想象。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【18】主线计划之外——输入法【2023-01-18】","slug":"日知录/【18】主线计划之外——输入法【2023-01-18】","date":"2023-01-17T16:00:00.000Z","updated":"2023-01-20T16:31:29.903Z","comments":true,"path":"日知录/【18】主线计划之外——输入法【2023-01-18】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9018%E3%80%91%E4%B8%BB%E7%BA%BF%E8%AE%A1%E5%88%92%E4%B9%8B%E5%A4%96%E2%80%94%E2%80%94%E8%BE%93%E5%85%A5%E6%B3%95%E3%80%902023-01-18%E3%80%91/","excerpt":"","text":"主线计划与长时间跨度的兴趣分支 学会输入法的时间量级以及其本身的性质,决定了这将是一个总时长不是很多,但是时间跨度会很长的行动。因为每天超过一定量的时间投入,整体的效率就会下降。(大脑需要时间间隔和反复刺激。)所以这类的行动需要在时间周期中设计结构,并且耐心地一步一步地执行完成。 看书、学语言这些则需要“集中突破”,更准确地说,也是在长时间尺度上做这件事,但是,应该在每次集中达成有效输入。 意外之外的事,必然在计划之后出现。每日尽早尝试完成计划,及早推进进度,这样才能减少节外生枝的可能性。 既然想清楚了要做什么,已经设计好了自己的主线,就不应该跑题。如果持续跑题,或许有如下可能: 第一种可能,设计主线时的理性思考是形式上的思考而不是较真的思考,还没有想透本质,这种情况下设计的主线是假主线,需要重新思考其本质; 第二种可能,明知道需要完成主线却无法去完成,那么是处于失控状态; 第三种情况,在强为不可成之事。在当初设计的时候存在未考虑到的因素,或者某些地方有差错,设计的事情本身就不可能实现,所以不可能做到。 无论其他支线如何有趣,都应该保证推进主线进度的速度。支线兴趣不能成为不执行主线的理由。 自己设计的主线所要求的进度正是“该做什么”这个问题的目前最理性思考结果,目的在于规避已知的最坏结果、规避特定危险、规避陷于落势。如果不一点一点地推进主线,那么当落势形成的时候就难以挽回了。 只是要求优先完成设计好的每日主线进度要求,并不意味着就要放弃支线。如果投入大量时间做主线,并不意味着就会完全没有多余时间。主线任务之外的空隙时间总是会有的,这些时间才可以用来做兴趣支线。(也就是说,兴趣支线应该认真地玩出名堂来,但是,必须限定时间,不能“捡了芝麻,丢了西瓜”。) 如果经过理性论证,有必要花大功夫去深入探索支线,那就应该想办法把支线换成主线,或者融入主线。(从而在某个阶段创造资源,而不是持续消耗资源。) 输入法 并击除了考虑编码出现频率以外,还应该考虑同时并击的键数。这正好与连击所要求的均衡目标相反,应该重新为并击专门设计编码分布(,把26个键位根据频率分5+10+10+1四档来安排,把三键击和四键击的并击划分到低频20%里,并借助现有的双拼连击设计工具进行评测。码表则借助小鹤双拼的词表,写相应的脚本进行批量转换。) 第一版和第二版的并击之所以失败,主要是因为既要学山人全息码,又要连并击键位,同时又还需要手指做大距离移动,所以训练难度极高。长期训练依旧训练不下来。无法实现的方案,就只能具备理论意义。只有能实现的方案才能产生现实的力量。 最终,第三版的并击方案还是回归了20键音形码的设计。手指几乎不需要移动,而且使用音形码,训练量大幅缩小,这次的设计非常具有现实性。并且初步训练的效果不错。 只不过,这件事不能心急,做成这件事,必须要设计匹配时间的量级,有耐心地一点一点推进度。 《追寻》之击键篇 - 知乎 【图片】新的双拼评测工具_双拼吧_百度贴吧 双拼方案评测和优化 可能适合并击的轴体:凯华Choc猪鼻子粉色矮轴、Keychron光轴白轴、凯华Choc蓝色矮轴、Skyloong冰川-静音机械黄轴","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【17】过往经历与记忆【2023-01-17】","slug":"日知录/【17】过往经历与记忆【2023-01-17】","date":"2023-01-16T16:00:00.000Z","updated":"2023-01-17T15:34:56.370Z","comments":true,"path":"日知录/【17】过往经历与记忆【2023-01-17】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9017%E3%80%91%E8%BF%87%E5%BE%80%E7%BB%8F%E5%8E%86%E4%B8%8E%E8%AE%B0%E5%BF%86%E3%80%902023-01-17%E3%80%91/","excerpt":"","text":"丢失记忆,也是丢失自我感知的生命。 如果不回顾,不记录,不以某种方式反复出现(比如与他人述说),那么记忆就会慢慢丢失。 有必要对各事件进行记录。但同时需要降低记录成本,所以有必要训练速录、时间数字记忆宫殿。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【16】《Essentials of Programming Languages》-数据抽象【2023-01-16】","slug":"日知录/【16】《Essentials of Programming Languages》-数据抽象【2023-01-16】","date":"2023-01-15T16:00:00.000Z","updated":"2023-01-16T15:47:27.708Z","comments":true,"path":"日知录/【16】《Essentials of Programming Languages》-数据抽象【2023-01-16】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9016%E3%80%91%E3%80%8AEssentials%20of%20Programming%20Languages%E3%80%8B-%E6%95%B0%E6%8D%AE%E6%8A%BD%E8%B1%A1%E3%80%902023-01-16%E3%80%91/","excerpt":"","text":"Data Abstraction 1.2.1 Specifying Data via Interfaces 1 意识到自己正在隐式地定义数据类型了吗? Every time we decide to represent a certain set of quantities in a particular way, we are difining a new data type(无论你意识到了还是没有意识到,每当你想要用某种特定方式表达某组特定的“量”的概念,就意味着你已经开始定义新的数据类型了。) 1|这句话暗示这样一个事实:你可能“正在定义某种数据类型”,但是却没有意识到,所以并没有按照定义数据类型的方式去做这件事。 1a|例如,随意地把Cpp里的类成员都设置成public的做法就是没意识到这一点。 2 用“类型”语法定义数据类型的时候,是“类型”的语义吗? 1|理解data type的语义本质,在隔离抽象设计和具体实现的时候才能更准确地使用诸如class这种关于“类型”的语法 2|values和representations,应该选择什么样的representaion。 3|operations和procedures,应该怎么设计配套的procedures。 4|有一种常见说法是,确定下怎么表示和怎么解释就是定义了一种数据类型。(相同的表示是byte还是char。)这种说法是前一种说法的特例。 5|在Cpp里用struct或class,可能只是“封装”,通过打包来管理数据组织结构的复杂程度,通过“隐藏细节”来降低心智负担。但这并不一定完成了data abstraction,因为还应有配套的procedures,这样才能完成“隔离”。 应该采集并积累实际案例来学习如何权衡“隔离”与“性能” 3 如果需要不断改进底层表示,应该考虑数据抽象 1|高效的数据结构表示,可能底层复杂并且实现起来困难。 2|想从简单的数据结构表示开始逐渐过渡到复杂的,那么也需要能定位程序里每一处依赖该数据表示的地方。 , 4 抽象数据时优先考虑什么,又该如何做到 The interface tells us what the data of the type represents, what the operations on the data are, and what properties these operations may be relied on to have. 1|这意味着,操作集合要优先于属性集合来考虑。首先要先想清楚这个数据类型的含义,想要代表的、想要表达的是什么“量”。而后,考虑操作集。再次,则考虑为了支撑操作(、功能、函数、变换、运算、可执行代码、方法、修改状态)而应该有什么属性。 1a|注意,这里的“属性”其实还可以(递归地)是接口,并不一定要是“数据”,也可以全是lambda。或者说,代码即数据,数据即代码。 1b|示例,操作file和操作int,我们其实更关心“可以执行特定操作”,而不是它们底层如何表示。 2|representation-independent (the code does not rely on the representation of the values in the data type):the client manipulates the values of the data type only through the procedures in the interface. 2a|接口和实现隔离,隔离的意思是二者之一的变化不会影响另一个 2b|底层表示独立,独立的意思是底层表示可以自由修改和演化。 3|go语法中的interface就暗示了这种“操作之集合”的思维。 5 示例,定义自然数时的三种潜在表示 1|constructor和observer 2|opaque与transparent 3|关键在于,在操作的前后,通过observer去观测都能满足自然数的性质。 自然数接口 Unary representation (bools) Scheme number representation Bignum representation 1.2.2 Representation Strategies for Data Types Environment准确定义 extend-env使用方式 Environment相应的grammar 数据结构版本的表示方式 Procedural表示方式 1|environment,用于把值和变量给关联起来(变量绑定),extend-env的过程就像一层一层给垒起来。 2|environments的接口设计 3|Data Structure Representation 3a|The Interpreter Recipe 3b|Defunctionalization,允许不使用高阶procedure来实现接口 4|Procedural Representation,借助构造器和“apply-”访问器,“包裹”在各处构造、使用的变量,从而实现“底层表示独立” 1.2.3 Interfaces for Recursive Data Types lambda表达式grammar 为lambda表达式引入接口 occurs-free?仅依赖接口的新版本 为递归数据结构设计接口:constructor, predicate, extractor 1.2.4 A Tools for Defining Recursive Data Types 递归数据结构lc-exp 相互递归的数据结构s-list,节点s-exp视角的定义 相互递归的数据结构s-list,链表s-list视角的定义 1|define-datatype关键字,定义数据类型以及类型检查 2|cases关键字 3|domain-specific language 3a|定义递归数据结构的DSL 1.2.5 Abstract Syntax and Its Representation 1|concrete syntax/abstract syntax/tree/define-datatype 2|production name, nonterminal occurrence, terminal 3|parser和parser generator","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【15】自主时间1【2023-01-15】","slug":"日知录/【15】自主时间1【2023-01-15】","date":"2023-01-14T16:00:00.000Z","updated":"2023-01-15T16:24:02.428Z","comments":true,"path":"日知录/【15】自主时间1【2023-01-15】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9015%E3%80%91%E8%87%AA%E4%B8%BB%E6%97%B6%E9%97%B41%E3%80%902023-01-15%E3%80%91/","excerpt":"","text":"时间幻觉 过去一周,主线推进的进度极少。花了大量的时间在研究怎么做笔记、打印各种资料、搜集资料……这类事情上。相对于这些时间,出行时间与参加活动的时间其实只占小头。 钟表陈述的事实与知觉上所传达的情况并不相同:看上去出行的时间很长,其实吃饭的时间也很长;看上去参加活动的时间很长,实际上一次可能也就4小时左右,而一天剩下的时间完全有8小时以上来完成设定的小目标……这也是从自学cs计划开始到现在之日常生活的缩影,只不过之前有着种种幻觉,而如今通过柳比歇夫的方法将这些事实明显地揭露出来了。被打破以及得到解答的各种认知包括但不限于“到底花了多少时间在学习上”的认知、自己是否真的在推进主线、为什么感觉花了很多时间去做事而实际上进度却只有一点点…… 所以应该继续强化柳比歇夫的方法。 时间自主的可预期主线 下一周,只做一件事:一周推进700页主线计划的书(平均每天硬性8小时左右+弹性4小时整理笔记)。完成了这件事,剩下的时间再自主安排去做别的。 每天尽早完成100页阅读,具体计划都在前一天计划好。 预计过年的时候,每天早上6点半到9点以及下午可能会有2小时半左右的学习时间,即,一天5小时左右,并不少! 实际上,即使参加了活动,在心理上感觉一天都没空,而在实际上仍然有大量可支配时间!所以,该学习的时间并没有借口。真想学习,那么一天就有时间学习,而且并不少。如果没有推进学习进度,那么就是并不想学习。 为了平均每天100页,必然有数天的进度要大于100页(150x3+100+50x3)。越早往前推进度,可能因预料外事件而导致失败的可能性就会越少一些。所以,自己可完全使用的时间非常珍贵,如果每过半小时而没有学习,那么计划失败的风险就会累积! 主线之外事情,要做到克制单日,重点在于确保可持续,用好时间的力量。比如plover与今日设计的inplace输入法,每天投入1小时并做好笔记(有效积累)即可。 想用上暗时间?注意是不是无效的平行行动。 平行行动如果过于复杂,基本上不会有效果。比如,公交车上看书,效果会比较差。但是像算法思考、复习回忆这种不依靠感官直觉的平行行动则可以取得好效果。 以时间的方式积累笔记,还是以逻辑的方式积累笔记? 以时间周期推动输出(总量持续地有规律增长),以逻辑主题积累整理(高质量)。 怎么实现自主可控?有效计划应当具备的性质? 设计一系列可行的小阶段。比如抓码的训练过程就是步子迈得太大了,以至于难以完成…… 可控。细细地理解生命与时间,重新理解“所在”。细细思考这两类人的区别:一类人认为自己的意志存在于某一时刻点,而另一类人认为自己的意志分布在某一时间段。各取所长,取前者把握当下的能力,取后者面对“确定性”的心境以及长时掌握力,学会“预先”将自己的意志注入到特定时间段里的每一个时刻点,并在真实到来的时刻完成,主动承接确定性,减少对“随机精彩”的错误认知。 可预测。通过时间数据逐渐提高预测精度,让猜测能力进化成预言能力。 可持续。不破坏下一次的行动条件,拒绝过度疲劳。 进度可测量。比如看书就是好测量的一件事。而写代码的总进度则不方便估计进度。这种事情就要每天限定时间总量,尝试在这个有限的时间总量里全力做出最好效果。 把握主线。不因贪心支线进度而挤占主线的时间资源。支线部分应该让时间来发挥作用,只要确保真实有效积累并且可持续即可。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【14】《Essentials of Programming Languages》-递归程序写法【2023-01-14】","slug":"日知录/【14】《Essentials of Programming Languages》-递归程序写法【2023-01-14】","date":"2023-01-13T16:00:00.000Z","updated":"2023-01-14T15:29:52.300Z","comments":true,"path":"日知录/【14】《Essentials of Programming Languages》-递归程序写法【2023-01-14】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9014%E3%80%91%E3%80%8AEssentials%20of%20Programming%20Languages%E3%80%8B-%E9%80%92%E5%BD%92%E7%A8%8B%E5%BA%8F%E5%86%99%E6%B3%95%E3%80%902023-01-14%E3%80%91/","excerpt":"","text":"《Essentials of Programming Languages》 【1】 Recursively Specified Data contract and comments,写递归程序时应该清楚在操作的类型、所写程序的语义 Inductive Specification,递归定义数据的三种方式 2a) top down 2b) bottom up 2c) rules of inference 示例,list of integers 【2】 Defining Sets Using Grammars 示例s-list, binary tree, lambda expression context-free与context-sensitive:是否可以在符号出现的任意处做替换?某些nonterminal symbol所在位置是否存在特定的约束,会使得替换操作并不合法?(比如binary search tree) bound variable of lambda expression,简单而言,就是参数部分的变量,可以绑定或捕获在函数体部分出现的同名变量 grammar的含义,看《计算理论导引》会理解得更清楚一些。 【3】 Induction 证明的关键在于 1a) 拆分未证明命题时,拆分出的子结构比要证明的结构更小,从而能够满足归纳假设,进而可以用上已证明的结论。 1b) 不断分解问题,分解到最后的问题可以直接解决。 在inductive definitions的基础上,可以挖掘性质证明定理 2a) 对于没有子结构的结构,命题是正确的。 2b) 如果s的子结构满足命题,则s本身也满足命题。 或者根据inductive definitions的结构特点去写递归程序。 【4】 Deriving Recursive Programs If we can reduce a problem to a smaller subproblem, we can call the procedures that solve the problem to solve the subproblem. (用来解决原问题的过程,可以在分解出来的子问题上调用,从而解决子问题。) 有效的关键:每次调用过程的时候,问题的规模都会变小一点,直到足够小得可以直接解决。 这里和原文描述不太一样,因为过程其实不一定只有一个。 【5】 Follow the Grammar 示例list-length, nth-element, remove-first, occurs-free?, subst (对比SICP)可以从计算模型(替换模型)的角度理解这种程序设计方法 【6】 设计递归程序-grammar五步走找出递归结构 When defining a procedure that operates on inductively defined data, the structure of the program should be patterned after the structure of the data. 核心想法:nonterminal之间的语法规则关系意味着程序结构的分支和替换(函数调用),terminal则意味着递归出口。如果能(用grammar rule)理清楚递归数据结构,那么就找到了大体上合理的递归程序结构。 得先把数据的递归结构给定义清楚。怎么定义清楚?用之前的三种定义方式之一试着定义。 每条grammar rule左边的nonterminal,意味着某种有待替换的结构,那么也就需要有procedure来处理 出现在grammar rule右边的每个nonterminal应该由自己的逻辑分支来处理,如果独立开来设计procedure,可以每次只思考一条,从而想清楚问题。(对比SICP的wishful thinking,也是每次专注在一个问题上思考。) 出现在grammar rule右边的每个nonterminal实际上还需要继续替换处理,所以也就需要继续调用对应于该nonterminal的procedure。这样就自然地完成了递归程序(多个递归过程)的设计。 terminal意味着某种递归出口 这种设计方式相比知乎上一众递归条件、递推式、递归出口之类的描述要更精确得多。而且点出了特别关键的一点:想要描述出递归程序的递归结构,得先描述出递归数据的递归结构! 【7】 设计递归程序-由 Auxiliary Procedures转化问题 复杂grammar的分解方式可以参考《计算理论导引》。 (目前为止只能处理正则语言) 例子,为无法分解的vector中每个元素标序号、vector上求和。由这些例子理解“怎么正确思考递归程序中的初值”。 when defining an auxiliary procedure, always specify what it does on all arguments, not just the initial values. 从设计递归程序的角度来理解:某些常量、对象的属性值其实是问题的“隐藏变量”,应该抽象成变量,将元素的角度转移到集合的角度思考,将定义域内每个实参取值纳入考虑范围,去思考更泛化的问题。 3a) 抽象出变量后,可能可以在内部建立归纳结构。再进一步,可能可以将这些结构用于设计procedure,那么相应的变量还可以考虑设计为函数参数。 3b) 整个定义域内可能会有可实现的归纳基础。 3c) 如果能完成归纳,就可以将原先的常量当做已解决问题的特例。 从如何理解别人设计的递归程序的角度来理解:对于使用特定初值的递归程序,如果只从每个初值的角度去思考是不可能想清楚的。(比如在头脑中跟踪执行点,不断地进入更深层的调用,但每次都只是以某个初值的角度来思考递归程序。)必须将其抽象成一个变量,从整个的定义域去思考。 【8】 设计递归程序-怎么理解Context Arguments 设计参数的时候肯定要能表达要处理的数据,这是常规的参数 常规参数代表的问题,会在递归过程中不断缩小规模,最后解决 所谓的context argument或inherited attribute,就是用来描述那个要递归缩减规模之问题的context 3a) 例如,vector标序问题中,索引n用来描述sublist in the original list这个子结构的所在位置,这个变量并不是sublist这个规模正在缩减的子问题,而是间接地以可用局部变量的方式辅助表达sublist。(”tell us the position of the sublist in the original list.”) 3b) inherited attribute的含义则是,这个属性在过程的递归调用中不断地传递,从一个过程的执行环境继承到另一个过程的执行环境里。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【14】源码学习能力1【2023-01-14】","slug":"日知录/【14】调试大型项目源码的能力1【2023-01-14】","date":"2023-01-13T16:00:00.000Z","updated":"2023-01-14T15:07:23.501Z","comments":true,"path":"日知录/【14】调试大型项目源码的能力1【2023-01-14】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9014%E3%80%91%E8%B0%83%E8%AF%95%E5%A4%A7%E5%9E%8B%E9%A1%B9%E7%9B%AE%E6%BA%90%E7%A0%81%E7%9A%84%E8%83%BD%E5%8A%9B1%E3%80%902023-01-14%E3%80%91/","excerpt":"","text":"首先要有高质量源码。比如,业界最新工程实践的源码,可能只能在大厂内部看到,而外部看不到,那么也就没法学源码。不过,其实开源项目的代码就很够学了。 visual studio的一些简单配置 先找Tools下的Options 看Microsoft的在线文档,熟悉各种基本功能,比如:在文件中查找 - Visual Studio (Windows) | Microsoft Learn 在Solution Explorer中追踪正在浏览的文件:How to Show the Current Active File in Visual Studio Solution Explorer | Matt Ferderer File Path On Footer - Visual Studio Marketplace visual studio 放大字体 - Google 搜索 一些问题,像是“长字符串打不开viewer”,网上的答案不一定正确。可能就是vs的版本过新,需要往回退一退。 常规项目在windows平台上编译 C以及C++、编译、链接的基本功得练扎实,而且必须至少是实验驱动的训练方式,只看书是远远不够的。(尤其是各种问题组合起来,如果只看过书而没有练过,难度就会以乘法方式组合飙升。)之后则是熟悉project属性里的各种设置。 无比详细的例子:如何在 Visual Studio 编译调试 Windows 版本的 Nginx 源码? - 知乎 添加过滤器有点小坑,最新版本不一定支持递归地把文件夹添加成过滤器,得一个一个手动加…… visual studio add directory tree - Google 搜索 如何在Visual Studio中“添加现有项”整个目录结构?_asdfgh0077的博客-CSDN博客_visualstudio 显示根目录内容 编译的一些操作 熟悉project属性里的各种设置 熟悉Build菜单下的各种选项,比如visual studio 清除文件重新编译 - Google 搜索 一些简单的快捷键,比如ctrl+pause 报错怎么处理 先看是否有定义,通过everything搜索源码目录,在vs的工程配置中添加各种文件,或者可以自己写一些脚本。(一些外部的依赖库还需要下载。) 搜索引擎搜一搜,比如c++ - Unresolved external symbol LNK2019 - Stack Overflow能知道Ws2_32.lib这样的静态库,Link errors in 1.1 Windows static build: unresolved external symbol __imp_CertOpenStore · Issue #1061 · openssl/openssl能知道crypt32.lib。(用everything在电脑上搜一下,其实是Crypt32.lib。) 依旧无法编译通过,就删除,但是删除的时候应该记录删了什么东西。如果模块划分得好,想学的部分作为相对独立的模块其实不一定会受到影响。 vs调试 重点在于积累场景。什么场景s应该采用什么思路t去进行什么操作组合ops来探查什么信息info,最好专门开文档积累(s,t,ops,info)。 Debug窗口一个一个看熟悉。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【13】无效笔记之危机6【2023-01-13】","slug":"日知录/【13】无效笔记之危机6【2023-01-13】","date":"2023-01-12T16:00:00.000Z","updated":"2023-01-13T15:12:24.311Z","comments":true,"path":"日知录/【13】无效笔记之危机6【2023-01-13】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9013%E3%80%91%E6%97%A0%E6%95%88%E7%AC%94%E8%AE%B0%E4%B9%8B%E5%8D%B1%E6%9C%BA6%E3%80%902023-01-13%E3%80%91/","excerpt":"","text":"速度与精加工度的权衡 通过近段时间的试验,发现如果要做极致精细的笔记,阅读速度将会下降到1小时4到5页。这意味着,980页左右的书,可能需要240小时左右才能看完,这个速度极度不合理。 这意味着相对于常规阅读80小时阅读,要多出160小时。 如果一天8小时,10天可以看完的书,变成要30天才能读完。 如果一天12小时,7天可以读完的书,要20天才能读完。 对于C++的书而言,这只是一个读书时间,并没有包含写代码的时间! 额外的160小时时间完全可以重新设计,用来做一些小的C++项目,效果肯定比只读一本书要好 但是,之所以要做笔记的那些真实需求也并没有消失,因而必须重新设计验收标准,在不同的策略之间权衡。 验收标准 能力1:能解决实际问题。 难点在于不知道“不知道”。所以很多问题虽然可以通过搜索引擎解决,但是困难的问题就没法这样做了。这也是为什么要看书 能力2:用更精确描述(专业名词)定向搜索。(“知道存在”。) 知识脉络的覆盖率。覆盖量和结构都应该合理。 知识脉络的粒度。“一念知”则可以放入同一个概括节点中。一种可能的合理粒度是,一页用大概四到五个短语概括,只在书本目录的基础上再加一级细节。 能力3:主动检索,借助自己的知识脉络减少特定内容的反复无效学习次数。 能按逻辑默写这个主题的某种知识脉络。可以是自己思考后整理的,也可以是别人的书籍目录。 能力4:快速全面检验知识掌握情况。 重点在于足够快地去查漏补缺。 能力5:精确复述关键内容。(特别高信息密度的内容。) 比如,定义、定理。 比如,关键示例。 能力6:无法精确记忆但是需要精确记忆的内容可以快速查找。 做精确摘录并集成。 能力7:遗忘的知识在重看的时候可以快速唤醒。 针对困难内容所做的调查、思考,应该整理出某种对应书页顺序的索引文档。 再次尝试设计一种方案 每次针对当下的需求和未来的潜在需求,有针对性地设计验收标准。比如,容器那一章看完需要掌握什么能力、产出什么东西。 先调查与寻找足够实际的需求、高质量的需求。 如果找不到,应该自己创造需求。比如,学rust用来写os的lab。 看书的时候只找“新信息”,快速浏览看完,然后默写。再对比缺漏的信息。 关键点在于,之前的内容扎实地掌握,这样不需要在作者每次顺便提到之前某些的时候都感觉模糊、感觉需要精确记录。 看书的同时,每一页看完后,每一个逻辑块用一个短语总结,并记到笔记中。内容可能是一段或数段。总体上而言,一页里可能有4到6个逻辑段。 关键点在于,不强迫自己去尝试记忆每一个细节……强记每个细节的做法,可能适合数学,但是不适合那些信息密度低的文本。 将学习过程均摊到未来。像画画一样一层一层地渲染,而不是像零件一样一个一个地制造。 用关键词组合生成问题。比如C++的各种特性之间的交叉解释。 看完一章之后,尝试默写自己知道的内容,从解决问题、实际使用的角度写一篇博客。然后再和原文对比,看遗漏的什么点,哪些地方并不知道。 关键在于,掌握本质,针对特定问题能有精确思考的能力,并且在新场景下也能解决问题。 根据滤网精确摘录特定内容,并尝试找到本质从而易于记忆和记忆。 “短期内不可能记住,将来需要反复查阅的内容”,比如定义和定理、浓缩的总结表格、接口列表、Cpp关系之类的。 “从长远时间来看,有可能模糊但是却需要精确记忆的内容”。 待探索内容、有疑问的内容。 加工浓缩。比如,简单的代码示例可以合成复杂的。也可以从网上找一些高质量的,再自己改造。 高频使用的。 经常出错的。 总结一下 看书之前找到真实需求。 页内分逻辑段,用短语总结。 每章看完尝试默写,完成比目录更细一些的索引。 每章按滤网摘录,加工。 全书看完后默写自己做的目录。 全书看完后默写自己根据滤网整理并且需要精确掌握的摘录材料。 检查时候真的能完成需求。 从明天开始以博客的形式整理。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【12】无效笔记之危机5【2023-01-12】","slug":"日知录/【12】无效笔记之危机5【2023-01-12】","date":"2023-01-11T16:00:00.000Z","updated":"2023-01-12T16:10:03.218Z","comments":true,"path":"日知录/【12】无效笔记之危机5【2023-01-12】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9012%E3%80%91%E6%97%A0%E6%95%88%E7%AC%94%E8%AE%B0%E4%B9%8B%E5%8D%B1%E6%9C%BA5%E3%80%902023-01-12%E3%80%91/","excerpt":"","text":"三难 看书原本就没法多快。要让学到的知识具有活力,则会进一步放慢进度推进速度。要是还想让活知识可以被主动检索,直观速度又要再降一个层次。但是…… 莽冲而不管将来的学习策略,并不一定有问题。如果能接触到未来的使用需求。则可以逆向分析依赖链,有重点地学。并且借助自然需求来高频提取头脑中的知识,增强记忆和理解。例如HTML与CSS这些的学习。 平行地实践,识别不重要内容的能力变强了,则在细学的时候也能减少学习内容,加快学习速度。 为阅读做复杂的周边工作,(比如制作笔记、回忆材料、纸材料电子化这些,)不一定能很好地管理复杂度,所以也不一定最终学习质量、容量上限。 时间切切实实花出去了,这也意味着机会成本。如果这部分时间用于莽冲,有可能可以提前覆盖更多的技术点,进而吸引更多的资源,然后以更快的速度成长。但也有可能因为无法管理复杂度,最后卡在一个更低的天花板下。 精读材料的学习策略,在有界竞争内可以表现得好。但是可能败在未知边界竞争中,因为成本过高,但是在有限时间下覆盖率低、完成度低。 注意《驾驭Makefile》和《和我一起写Makefile》的区别,以及技能书提升能力的上限。 制定学习策略? 在尝试设计最优策略时,可以去尝试考虑的变量很多。但是,应该选用哪些来思考? 真实的可用时间量(以及暗时间) 所选的学习材料序列 学习材料能提供的能力点 验收标准(真实需求) 学习操作(比如搜索、看书……?) …… 重点一是打开视野,在此基础上可以组合思考,也可以模仿。 其二是实打实地花足够的时间总量。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【11】无效笔记之危机4【2023-01-11】","slug":"日知录/【11】无效笔记之危机4【2023-01-11】","date":"2023-01-10T16:00:00.000Z","updated":"2023-01-11T15:16:08.532Z","comments":true,"path":"日知录/【11】无效笔记之危机4【2023-01-11】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9011%E3%80%91%E6%97%A0%E6%95%88%E7%AC%94%E8%AE%B0%E4%B9%8B%E5%8D%B1%E6%9C%BA4%E3%80%902023-01-11%E3%80%91/","excerpt":"","text":"看书同时做记录的速度不可接受 内容复杂之后,如果直接边看书边做记录速度会非常非常慢,慢得不可接受。 未完成理解时就做记录,如果要记逻辑链,要么是记录各个单独的词,要么是记录整句话。前者在慢速情况下会导致逻辑断裂,进一步降低速度,后者则夹杂太多冗余信息。 在未理解的情况下,头脑的检索能力也非常有限,必须将头脑中的想法缓存到外部。 阅读并标记 在书上标记的第一目的在于增强理解,不是替代笔记。最终依旧要做笔记,因为书上的标记虽然可以加速检索,但是无法做到将检索速度从线性变为对数。所以标记的第二目的在于,为笔记做预处理。 为标记和笔记设计映射关系。 对应标记用[]<>__轮换。 标记x.y代表理解顺序。选择的首个词需要是重组之后句子的主语,方便于其他内容链接起逻辑。 用□△○标记行“一扫知”的核心想法用于在块内连贯逻辑。 书上标记的顺序要按逻辑顺序重排,不应该按书上出现的顺序标记。 在看完数页之后,页内分块的关键词直接记录到笔记中,因为如果在书上,无法呈现在同一页里,增强理解的效果有限。 标记与笔记方法 找天然的行内容,[]<>__择一,标记各部分的词。 找出行内容逻辑核心,标记为首词x.1。 以首词为主语,重组句子,标序x.y,理解行内容。 循环[1-3],构建块内容,串联行内容首词x.1。 循环[4],整理出1到2页上的块内容,跨块串联行内容首词x.1。理解跨块逻辑,此时已无法用原文词汇概括,需要用自己的语言概括。每块整理出一个点出本质的短语。 如果短语的信息容量不够,可以尝试用句子。最好是问句。因为陈述句是静止的,问句有运动方向,适合连贯逻辑。 其余层级参考标题的组织结构进行自底向上的递归构建。 方案暂定如此,实际效果需看测算的具体速度。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【10】无效笔记之危机3【2023-01-10】","slug":"日知录/【10】无效笔记之危机3【2023-01-10】","date":"2023-01-09T16:00:00.000Z","updated":"2023-01-11T14:28:52.968Z","comments":true,"path":"日知录/【10】无效笔记之危机3【2023-01-10】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%9010%E3%80%91%E6%97%A0%E6%95%88%E7%AC%94%E8%AE%B0%E4%B9%8B%E5%8D%B1%E6%9C%BA3%E3%80%902023-01-10%E3%80%91/","excerpt":"","text":"又一次开始设计笔记方式。昨日的思考结合今日设计的笔记模板,想必已经可以满足未来的需求了。(大容量、递归索引、易于打印、标记醒目……)阅读笔记性质的认知+合理建构方式+可用软件工具,似乎即将能够最终解决这个问题了。 虽然整体理解程度大幅提升,但仍旧存在阅读速度大幅下降的问题。(不过,精读一遍快于两次急读。)具体速度还有待测算,还需积累更多的统计数据。 一个可能的提速方案是掌握单手盲打,按7页1200字笔记量来算,每页是170字左右的笔记。如果单手盲打能达到每分钟40~60字,那么做笔记将不是阅读的障碍,因为技术书的平均阅读速度大致在5分钟/页。 单手盲打用自己之前设计的抓码应该可以解决。可能还需要30小时的左手训练量。 在尚未训练出左手抓码之前,可以先用普通的输入法输入。 虽然大型材料不太可能用记忆宫殿,但是在短文本上或许可以用一用小型记忆宫殿来缓存记忆。从5~10个临时词拓展到50+或许是有可能的。需要注意的是,用记忆宫殿的记忆效果实际上不一定比得过直接尝试去理解。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【9】无效笔记之危机2【2023-01-09】","slug":"日知录/【9】无效笔记之危机2【2023-01-09】","date":"2023-01-08T16:00:00.000Z","updated":"2023-01-09T16:01:53.262Z","comments":true,"path":"日知录/【9】无效笔记之危机2【2023-01-09】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%909%E3%80%91%E6%97%A0%E6%95%88%E7%AC%94%E8%AE%B0%E4%B9%8B%E5%8D%B1%E6%9C%BA2%E3%80%902023-01-09%E3%80%91/","excerpt":"","text":"危险状态 小心似懂非懂的危险状态:看到原文的时候记得看过,但是独立思考的时候、要解决问题的时候却像没有看过一样,无法准确地回忆足够多的推理所需细节。这种情况下可能会误认为自己懂了,但是实际只懂了浅层,因为只能验证记忆,却无法主动提取。 小心表面上的进度:看了几百页,但是无法主动有序检索自己看过了内容。 现实条件 在看书之前难以分辨哪些是重点、哪些不是重点。比如,某页里一句话带过的内容,里面的逻辑知识点有可能会在后边被引用到。 无法确保首次阅读完一本书之后能完全记得里面内容的细节。 不理解的细节往往却更容易被遗漏以及遗忘掉。 随着时间推移,首次看书所得记忆的有效性会逐渐衰减。里的细节会逐渐变得模糊。 完整地以线性方式看一遍书,要非常长时间。如果大量遗忘,从头到尾完全重看一本书的时间代价太大。 尽可能避免重新以线性复杂度查找特定文本。 书看了很多之后再做笔记,会思绪过多,歧路亡羊。 回看时会觉得自己熟悉了、知道了,反而会不想读。(实际上知识结构已经变成了筛子。) 笔记目标 定量地验证/度量在看完一本书之后掌握了多少内容。能检测覆盖率,能快速地自己考察自己细节。(思想的TDD。) 预处理,降低之后检索的时间复杂度。从O(n)降低到O(logn)。 缓存记忆。 怎么阅读和做笔记? 按使用频率筛选。根据使用现实使用频率筛选出重点内容。注意,不应该凭印象,应该有一些初步的统计。 后面内容依赖前面内容。 消化加工。 卡住时,就应该合理应用草稿。在信息密度非常大的地方应该展开内容。 加工完的内容需要用某种方式保存(比如放到笔记中,或者制成卡片),要能对应到原文的位置。 笔记精炼。主动提取,建立一组不同层级的笔记。每看一遍能增强一点理解,此时就可以剔除更不重要的辅助内容。 关键想法:努力的方向不是去确保让相同的内容只需要做一次笔记,而是在每一层笔记中筛选出更重要的内容。在不理解细节的时候就下降到更低层的具有更多细节的层级。 类比:跳表的结构(多层)、B树结构(二分查找、大结点缓存) 第一层级的初筛确保不会遗漏掉重要细节。因为量比较多,用语音做笔记会比较合适。 初筛需要确保相同的分章结构,因为有可能要用于定位原文。如果打乱了就不好定位原文了。 初筛的笔记并不是在所有地方都是信息压缩。在不好理解的地方实际上需要信息解压,缺失的阐释需要自己查阅其他资料来补足,另外自己也可能添加一些串联对比的内容,又或者点出一些隐藏信息(使其在阅读时可检索)。 笔记总量比较大,合理的方式是自底向上构建递归结构。注意均摊。如果没有均摊,很可能因为心理压力、思绪混乱、遗忘等原因导致无法完成更大量级的笔记。(会觉得又要重读……) 每5页做一次笔记(思考理解,归纳出问题+纯回忆来解答),会比较合理。(每半小时里做一次简单笔记,按照番茄钟的节律来检索记忆。) 初筛笔记非常重要,与原文是一种互补关系,不同的地方相互参照。(补足一些未仔细说明的地方。)在二层笔记发现不理解的地方,去找原文的话可能还是非常难以理解的形式,此时就要去找初筛笔记。 二层笔记的每一条内容要对应一部分“一扫知”的消化好的理解成品。 高层可以采用信息分解来压缩。分出独立块,每块里有数个独立因素。独立块之间做笛卡尔积,因素之间也做笛卡尔积。还可以递归建构。(例子,C++语法特性。)在思考的时候用推理来生成内容。 不同的层级意味着不同的知识分辨率。分辨率的信息可以在其他筛选方法里做额外的记录。如果结合时间信息,还可以观察念头变模糊的过程。 遗忘筛选。根据自己的记忆效果,在每次遗忘的时候额外记录。注意按某本书的特定逻辑结构来组织,或者按自己的想法来组织。 结合番茄钟的周期进行前向检测。 疑问点筛选。自己提出自己的问题集,从开放的问题到开放的问题。(不止于“验证”。) 高级架构。比如精确摘录出所有定理用于快速参考。(一张纸压缩。) 思考本质,并写文章。所得的文本与检索用的笔记不同。检索用的笔记是专门针对特定书籍的。 假想出题。可以分辨哪些比较重要,哪些不是很重要。(如果要出题,哪些东西没意思,哪些东西值得去考察读者。) 定下了计划,分配了时间,就抓紧读。纠结的时候时间最快过。 看书就问自己"讲什么?“,找着看、猜着看、跳着看。不是所有内容都重要,从出题考读者的角度来观察这一点。快速地问自己"理解/不理解”,理解的就快速跳过看下一个点,不理解的就解读。(领会念头的瞬间,就闪进下一个念头。)二者都需要做笔记。 注意,番茄钟在执行观念上的精髓,就是在还没有疲劳的时候提前合理休息。所以,不断地往前推进度直到头脑疲劳的做法并不会提高全局吞吐量,因为不可持续。 书上标记的误区 想在书上标记的动机:书是信息最全的上下文,直接在线性文本上做标记,组织起树结构,再看的时候如果不理解就可以直接看原文。 实际会产生的问题:初筛的内容信息密度太低,不集中,需要一直翻页。或者内容太多,相当于需要看原文。或者逻辑不连贯,无法直接理解。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【8】暗时间与计划预判【2023-01-08】","slug":"日知录/【8】暗时间与计划预判【2023-01-08】","date":"2023-01-07T16:00:00.000Z","updated":"2023-01-08T16:32:47.370Z","comments":true,"path":"日知录/【8】暗时间与计划预判【2023-01-08】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%908%E3%80%91%E6%9A%97%E6%97%B6%E9%97%B4%E4%B8%8E%E8%AE%A1%E5%88%92%E9%A2%84%E5%88%A4%E3%80%902023-01-08%E3%80%91/","excerpt":"","text":"日知录 今天从《C++20高级编程》的第13章C++I/O揭秘看到第16章C++标准库概述,大概过了110页,用时9.5小时。在本质条件相同下循环做一件事,这件事的平均速度大体是个定值,那么也就可以做预测。放在看书这件事上,所谓的本质条件相同大概就是“时间分布在一天之内;平常的精神状态;没有显著的方法突破;每次循环的起始条件依旧适用”诸如此类的条件,当然其中有些是无关变量。所以,当满足特定假设的时候没,看书的时间可以用线性方式估算。100页就是大概满打满算的9小时左右。(25分钟看+5分钟休息的循环过程。) 但是存在暗时间。也就是因为各种原因没有执行主线行动的时间。这些时间,自己以为自己拥有,但实际上却与推进主线无关。或者,其实这些潜在时间可以提取出来用。 今天的暗时间就在于,早上的时候去找做笔记的方式,中午的时候看了点英语的东西和计算理论的东西。以后应该优先完成计划内的时间,再用自由时间去做别的感兴趣的事,这样的话,计划才能估计得准。 很多年前就知道了柳比歇夫的方法,但是当时没有什么效果。现在回看,是当时的心境不满足条件。从今年开始的情况来看,这个方法确实很好。 整周推进主线情况 日知录实际上用均摊的方式完成了一周的记录。但是如果不进行递归建构索引树,未来只能进行线性复杂度的搜索。所以有必要做“周知录”之类的东西。 就本周而言,仅最后一天的主线推进速度达标,即《C++20高级编程》看了110页,超过100页。整周实际上只从113页看到了489页,效率只有预计的55%左右,呈不及格状态。还有一大问题是笔记做在书上,这可能也并不方便。实际上,如果每天读了100页,应该做一些简单的小结,这样才能方便全书看完后做完整的整理。所以,读的质量也不太达标。 不过,好消息是,状态慢慢起来了,就像热身完成了一样。希望下周能补上进度:按每天100页的速度,下周日应该将计划书单看完1400页。如果要追上这个速度,可能要超负荷地以一天145页的速度阅读技术书,并不明智。所以还是每天稳扎稳打读100页,做好笔记,并按合理的标准来检验自己。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【7】睡眠和起床习惯【2023-01-07】","slug":"日知录/【7】睡眠和起床习惯【2023-01-07】","date":"2023-01-06T16:00:00.000Z","updated":"2023-01-07T16:06:48.414Z","comments":true,"path":"日知录/【7】睡眠和起床习惯【2023-01-07】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%907%E3%80%91%E7%9D%A1%E7%9C%A0%E5%92%8C%E8%B5%B7%E5%BA%8A%E4%B9%A0%E6%83%AF%E3%80%902023-01-07%E3%80%91/","excerpt":"","text":"前一天熬夜,导致早上看《C++20高级编程》的效率下降到每小时6页,下降50%(相对于今日正常的效率而言) 前一天熬夜是因为深夜的时候开始写作,正好有灵感,于是写了太长时间,一下就凌晨两点多了。 与写作相比,整体的效率吞吐量更重要,所以应该置换时间,优先让作息保持规律。 为了确保作息规律,应该按睡觉时间逆推做各种事的时间,并想办法防止意外。时间的预判与计算应该从日常活动中采集,类似《奇特的一生》中的时间记录。同样地,应该尝试设计最优睡眠方案,做实验,并记录详细信息从而辅助优化。 每次的动心起念都会影响思维的习惯。所以对于沾床就睡和闻鸡起舞这两种习惯,把握住动心起念的瞬间,可以减少行动阻力,毕竟大多时候并非身体觉得需要,而是心智认为需要。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【6】无效笔记之危机【2023-01-06】","slug":"日知录/【6】无效笔记之危机【2023-01-06】","date":"2023-01-05T16:00:00.000Z","updated":"2023-01-06T18:13:47.491Z","comments":true,"path":"日知录/【6】无效笔记之危机【2023-01-06】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%906%E3%80%91%E6%97%A0%E6%95%88%E7%AC%94%E8%AE%B0%E4%B9%8B%E5%8D%B1%E6%9C%BA%E3%80%902023-01-06%E3%80%91/","excerpt":"","text":"典型的无效笔记 一段里每句话都标记一个词。书内标记是为了再看的时候方便索引。如果原文标记过于密集,将失去索引的功效。密集标记的做法浪费了两遍时间,第一遍是看的时候额外做标记浪费的,第二遍是再看的时候标记无效而浪费的。所以应该重新设计学习流…… 所定目标中存在的问题:害怕错过细节、遗忘细节 本质上,“完全记住就等于完全学到”的想法只是一厢情愿的错误认知。若真知也,则当不为不可为。 **书亦并非完备,细究则知其缺。**总有地方要自己再去追踪调查思考深挖:或是内容互相矛盾而逻辑不一致的地方,或是觉得其阐述浅薄而未点出本质的地方,或是其内容过于浓缩晦涩难以理解的地方……一种信息不充分的经典情况是操作系统书,看多少书都不如自己去看源码找调用链,根据特点需求写功能。这种情况下,学习材料没有选对就不可能建构其所需的能力。 **就算内容全面,脚手架细节没必要记,记住理解的本质即可。**完成认知的状态和未学习状态的任务不同,一个重在基于(已理解的)记忆去思考,一个重在一小段一小段地逐渐解读原文并理解掌握。所以,通过脚手架完成知识建筑之后,没有必要再保留。完成解读之后,不应该认识不到自己已经完成了第一阶段的文字解读任务。更不该在意识到已过阶段之后,再徘徊和迷恋于低阶任务,尤其不应该屡次返工。所以解读阶段的成果应该保留下来比如,当时的整体推理链及其核心动机。比如,认知焦点聚焦在关键细节的状态。也不一定要复现,只要能掌握本质即可。在“对比”、“联想类比”、“提问调查”、“能实际生产”、“换说法多角度理解”、“向他人传授”、“设计习题”、“基于细节的理解进一步改造或设想创造”……等诸多检验方案中能过几种即可。 **时间有限,有学习效果的高密度信息部分应该加大时间比例,无学习效果的低密度信息应该快速略过。**比如,有项目的书或视频应该找源码;有练习的书应该选做练习(从高阶的后续项目中逆推应该做什么练习);每个词都有必要存在的定义应该集成整理并反复推敲……;先看工作需要用到的或者感兴趣而有动力看的部分,不怎么想看的部分分散开来一点一点蚕食消化…… **书中组织内容的方式并不一定合理,也不一定点出了本质。**书中内容并不一定全是高质量内容,完全记下原始内容只会让降低理解的质量。其中有些局部可以替换得更本质,整体内容的组织和安排方式也可能有其他更优的可能。另一方面,也意味着不应该平均用力。至少能分出“知道存在,打开视野”、“理解本质及变式,能判断与认识”、“精确记忆”、“深度掌握,能在实践中生产创造或灵活玩转”…… **再来一本同主题的书,有必要在大量重复的信息上使劲下功夫吗?**想尝试完整记书就要记大量重复的细节,浪费时间。重点应该转换到“怎么融合出匹配实际需求的完备认知”。看过一本书之后,就应该建立脉络结构并积累足够的本质细节。再看一本书的时候,时间应该用来研究整体逻辑脉络、观察视角、思维观点。那么细节呢?固然每个细节都对整体脉络的建构有重要作用,但是有必要每个都使劲吗?真正要积累的细节呢?只有局部里相对于上一本书的新细节有必要下功夫。而且下的功夫除了解读还有融合,也就是说在细节层面和脉络层面都需要对比与整合。 仔细思考,看书的一组相对合理的目标是, 能对知识进行递归全局检索,大致知道自己知道什么,也有足够的视野来看到该领域的大体知识分布如何。在需要的时候能找到对头的方向深入细节进一步探索。 对于局部细节,每段解读活动都保留了最核心的本质成果,能够快速唤醒“理解时刻”的头脑状态。 在自己理解的方面有多种可选的逻辑结构,同时也有一个自己融合的核心逻辑。 在从各类材料不断学习的过程中可以从各个方向进化认知,或是精炼本质,或是明白解释…… 实际操作中存在的问题:看书及做笔记的效率焦虑与认知空白 效率焦虑:做笔记时觉得浪费时间,在效率方面有着错误的贪婪和焦虑心态。 认知空白:一、看多少之后再做统一整理?二、用什么方式整理? 这需要考虑到认知规律、心理规律。 **一本好书不应该预设“只会看一遍”,所以要制作自己的再探索工具。**信息密集且需要精确记忆的内容,只看一次是记不下来的,所以需要反复重看,但是原始内容分散在各页中并不好快速查阅。那么,第一,应该在反复问自己而发现想不明白的时候,至少能找到原出处在哪。第二,可以快速根据需求定向翻阅和查找。查阅如果是线性扫描就太慢了,要找的具体细节内容应该作为次级检索内容,而不该在检索知识时直接面对未浓缩的原文。如此分析,首选方案是浓缩摘录出参考手册,并制作大缓存且能快速翻阅的纸质材料。注意不能过于依赖临时记忆。应该假设下一次有可能要很久之后才看,中间不大可能会反反复复复习,所以要梳理出精准的本质,一看就能回忆起当时的理解过程。(比如,一句话概述本质。)或者根据通用特征总结出可用于推理的核心理解。次选方案则是通过反复看的方式来熟悉全书脉络,或者在看完内容后去背全书脉络。为了快速搜索印象中的要点所在位置,可以基于原书目录专门制作自己的索引,但这种索引要有合理的数据结构并且足够简略。如果要缩略,那就要自己压缩,或者找别人的笔记来融合。 选择在哪里专门停下来制作什么样的查阅材料呢?要点是小递归、批处理、大缓存。第一种划分是依照理解情况来划分,一旦发现自己无法理解,应该做好标记,然后在两个小时内或者30页内停下来整理。依据后置知识依赖前置知识的程度也可以提早停下来梳理。具体形式可以很灵活,比如在信息松散的地方可以做标记,在信息密集的地方用自己的话旁注概括,也可以写自己的递归索引文档(自底向上建构索引)。第二种划分是按知识结构里某些高内聚低耦合的节点进行递归划分,并在一定程度上进行批量处理,(量级大致是?10小时?阅读量或者?120页技术书?依赖紧密的内容,比如数学书,每一到三天的时候统一整理,或许是一个比较好的周期。或者连续看了几章主题联系紧密但是理解内容所要求的依赖不紧密的内容之后,再整批地整理,比如《C++20高级编程》第8到10章约120页讲类与继承的内容。)按最小可理解模块制作直观卡片,每个小单元都是直观的两级索引树或三级索引树(充分利用记忆缓存能力),再递归构建每个节点是这种单元的索引结构。可以参考数据库管理系统设计数据结构,同时应该简要标注引用以方便未来回溯。 还有一种形式是自己浓缩出题,并准备好提示思路的简略答案。整理方式可以是“阐述题”。例如,代码相关的书,可以集成一组复杂代码,然后要求解释实际上发生的事情,也可以自己设计并编写测试代码来验证知识;或者将书中的小例子合成为复杂例子,或者自己构造一组具体的典型例子,避开纯文本描述,尽可能用符号来压缩内容,在其中以序列标记要点。 **针对细节掌握过程自然规律设计并优化学习策略。**首先得点出,关键在于能解决问题,而不是复述每一个写作细节,也就是说要针对“解决问题”来设计检验学习效果的标准。在有了这个标准的基础上,还要点出,其实建构解决问题的能力其实也有一系列细节。就掌握细节的自然规律而言,容易自然留存下来的是粗线条的整体记忆,而精确的细节则难以留存。如何逐步掌握解决能力的实践细节?回环学习或许可以逐渐掌握每一个问题该如何解决,但是制定计划定时复习在操作上过于复杂,应该找到一种低成本的方案。 可用方案1:反复不断地向自己提问,可以问“他本质上要解决什么问题”,也可以是想前面的细节,可以想象自己在讲台上会怎么讲,总之就是不断地自我检测,一遇到不理解的就思考并根据文本找答案。要注意有筛选地自己搜寻并组织答案,而不是害怕遗漏要点的线性扫描阅读。这时候只要有一个大概的印象,能按图索骥找到原始内容就行了。另外,应该把做全文笔记的时间置换出来做自我测试。在什么时候测试?根据内容量及其结构来判断,找到知识结构高内聚低耦合的划分节点来自我检验。比较合理的方式是顺着索引本身的内在结构纹理来划分阶段小递归。这里有一个难点在于,需要在知觉上直观认知到“逐渐掌握的合理过程在时间上如何分布”,知道具有真实学习效果的学习过程就需要这么长时间,再短也有一个下确界,从而在避免贪心的同时持续稳定积累。最忌讳的就是因为贪心而追求表面上的高速完成,不及时做索引,这样只会欲速则不达。 可用方案2:通过高阶内容来驱动低阶内容的回环学习,因为高阶内容需要高阶理解,高阶理解又依赖各种前置低阶理解,所以这样能产生对于低阶知识合理的自然需求。(或者根据要解决的问题逆推应该精确记录什么内容,应该理解什么内容,应该知道什么内容。)而且每次回环学习的时候也可以在高视角下重新理解低阶知识。比如,在知道了全局脉络之后,再看某本书的前几章能否发现先前未发现的联系。 **有意识地选择策略来处理难理解的复杂内容。**有三种基本策略:一个是自己综合理解然后举出非常细节的例子,之后每次见到这个例子就可以正向抽象归纳,那么就通过浑然一体的例子以及其中相互联系的线索记住了本质;另一个则是分治再融合(大化小,小合大),先化到可理解的最小单元,再逐层级建构理解,并且尽可能积累不同的观察视角、描述视角、理解方法、索引逻辑树;还有一个是推理性质增加线索量(小化大,难化易),某种意义上是把压缩的信息给解压还原成容易吸收消化的信息。 **简单知道的内容,制作一个简略的关键词树,能索引就差不多了。**某些描述文字,甚至按自己的思路来想可以比作者想出的东西更好,完全可以提出自己的变式,也可以按自己的逻辑来重组内容,或者也可以自己拓展。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【5】健康基于正确习惯【2023-01-05】","slug":"日知录/【5】健康基于正确习惯【2023-01-05】","date":"2023-01-04T16:00:00.000Z","updated":"2023-01-05T15:56:52.011Z","comments":true,"path":"日知录/【5】健康基于正确习惯【2023-01-05】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%905%E3%80%91%E5%81%A5%E5%BA%B7%E5%9F%BA%E4%BA%8E%E6%AD%A3%E7%A1%AE%E4%B9%A0%E6%83%AF%E3%80%902023-01-05%E3%80%91/","excerpt":"","text":"健康基于正确习惯。更有指导意义的说法是,错误习惯累积于时间,会导致疾病。 某种意义上来说,养成习惯、改变习惯的能力,即是积累健康的能力。能发现错误习惯,并且在苗头阶段就处理掉,即是圣人治未病的境界。 除了健康之外,错误习惯在同一时空中的数量累积、在跨时间上的累积,破坏力惊人。这种破坏力,源自时间的积累放大。微小的错误经过时间的放大就成了巨大的错误。 怎么改造错误的习惯?有一种巧妙方案:同样借助时间的力量。每次只做微小的改造,在时间中积累放大,最终完成改造。比如,每个月养成一两个小习惯,每个季度专门养成1组小习惯,1年下来足以在特定方面产生巨变。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【4】耐心与心理时间【2023-01-04】","slug":"日知录/【4】耐心与心理时间【2023-01-04】","date":"2023-01-03T16:00:00.000Z","updated":"2023-01-04T15:20:24.907Z","comments":true,"path":"日知录/【4】耐心与心理时间【2023-01-04】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%904%E3%80%91%E8%80%90%E5%BF%83%E4%B8%8E%E5%BF%83%E7%90%86%E6%97%B6%E9%97%B4%E3%80%902023-01-04%E3%80%91/","excerpt":"","text":"沿着时间拉长的意识流 如果对于时间缓流可以静虚以待,那么就相当于拓展了意识流的长度。这样看来,科幻中的子弹时间、超音速行动等超能力幻想,实际上就存在于生活中的看书等活动里。然而,在看专业书的时候,常人对于时间变速的“效率倍乘”幻想就会暴露其虚妄与过度自信:一词一词地看了二三十页却只过了两小时,时间何其漫长!“效率倍乘”的幻想,成了“心耗倍乘”的现实,是为无法承受之煎熬。 若能承受,则相对于常人而言,便是在起于10小时及以上的时间量级中拥有子弹时间的超能力。 在时间缓流中学习 如果早上6点起,看3小时共40页,时间才9点,此时一天才刚刚开始,会有满满的成就感与动力。 如果已经到了晚上7点,还没有做事,此时常见的心理是“算了,一天都快结束了,也做不了什么了”。但是,这只是心理时间感知的误导。7点到10点,虽然是一天的收尾,实际上有3小时。如果用来看书,也可以看40页。 无论在早上,还是在晚上,钟表上的时间总量不会变。但是存在心理效应的差别。怎么发挥夜晚时间的作用?耐心,能够一点一点地度过漫长的时间,就像青铜编钟一样冷静。 25分钟里尽全力去一页一页地看,绝不往后翻页(这通常意味着不耐烦了),然后在5分钟里完全放空。如此循环,平均速度稳定且可持续拓展时间规模。 慢方法1:不计时,只是一直往下看。这种方式不够积极,没有紧迫感。实际上,一眼能看懂的地方就应该快速往后看,一眼看不懂的才需要缓一缓细致地看。不计时会导致简单地方看太长时间。 慢方法2:计时了,全力往后看,但是到休息时间不休息,继续看。这种方式在1小时的量级上可能可以多看1到2页。但是不可持续,无法拓展到3小时。心理疲劳的厌烦情绪、客观的速度下降都会拖累效率。 准备可快速还原的工作台之逻辑构造以及文档。这样随时可以快速工作的最小条件集,切换耗时更少。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【3】动车上看书【2023-01-03】","slug":"日知录/【3】动车上看书【2023-01-03】","date":"2023-01-02T16:00:00.000Z","updated":"2023-01-03T15:30:36.707Z","comments":true,"path":"日知录/【3】动车上看书【2023-01-03】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%903%E3%80%91%E5%8A%A8%E8%BD%A6%E4%B8%8A%E7%9C%8B%E4%B9%A6%E3%80%902023-01-03%E3%80%91/","excerpt":"","text":"看书 看书用实体书,字大,任何地方都方便看,也便于笔记。 建立全局脉络,9合1打印更合适。首看与再看是不同的过程,首看时要字大,再看时要大缓存,方便快速回忆。 封闭于动车上,无他事,看书反而更快。 看书看累了,怎么办?什么都不做。即,不看短视频、不搞“休息活动”、不娱乐、拒绝无限时刷微信,只是最简单地趴着什么也不做,过一会儿休息好了重新继续看。这种方式,在长时间尺度上的吞吐量最大。关键在于,各种所谓的娱乐与休息只会消耗精神力,如果失控则会整块整块时间地耗散。 . 类似地,吃饭不看Bilibili等短视频平台上的视频,这样的时间段在心理感知上慢,在钟表上快。 看书做笔记,不贪图首次看就建立笔记体系。那种建构的体系是虚的,因为现实里,总是过一段时间后回看的总结更能把握要点、核心,从而能建立更合理的认识体系。 所以,第一次看只需要做脚手架笔记,非永久的,仅用于辅助临时的快速检索。 脚手架笔记,用5×5或者6×6的索引数即可。注意临时记忆的容量限制,该断则断。 每一页重计索引数,足矣。首看不需要花时间考虑怎么样划分与建构体系,每一页有索引数即可。 不应该立即把笔记做到机器上,即,不应该看几页就做笔记。看书的时间应该用来不断拷问自己,不会就回翻重看,最后能心有脉络。由于有索引数,所以可以快速定位。 不吝啬时间来在稿纸上做简易笔记。比如梳理图表。 不想看了或累了,就不看。可以在不同的书之间换脑。足够明智的人会选择追求最大吞吐量,而不是“最快刷完一本书”的兴奋感。 一两章内容看完后,再给自己出一张高浓缩度的试卷,比如代码解释题。或者做一个总结图。这时候也可以考虑扫描草稿。另一种方式就是通过后面的课程来驱动前面知识的应用、复习。 建立自己的综合认知框架。这样的话才敢在看同一个主题的不同书时,能够有所取舍,这样速度才会快。例:C++不同的书重复的内容很多。 看书实速与心理时间感知 10分钟量级,看2到4页,觉得快。 1小时量级,通常则12页到15页。慢则6页,快则18到20页。觉得慢。 2小时,通常25页到30页。慢则12页,快则35到40页。心理上觉得超慢。别人可能出去一趟回来了,或者过了半个上午,自己却只推进了不到一章。 10小时一整天,常速可以125页。感觉是正常速度,因为一整天其他什么事也不干,全用在看书上了。 两个整天,250页。心理感觉是,真快!因为这意味着,一个周末的时间,小书直接就看完了,大书的话也能看个半本,厚书也算接近完成1/4 第一道难关,在于看了2小时感觉没进度的沮丧。但如果马上就要用、带着问题与好奇去找知识,就能度过漫长的2小时。但是要2天20小时,就有点难了。进度表+番茄钟间隔休息+换脑换书+不按特定顺序看+先看感兴趣的和要用的+笔记标记+只看当前页而不一直往后翻,则2天20小时也很有可能。 在不同时间量级上,心理时间感知效果与实际的看书积累量存在着微妙的错位匹配。眼光长远的人会追求最大吞吐量,而不是最快响应时间(“我看完了一本书”)。 看书挑战 是否有可能做到每天稳定看100页书呢?如果心有内耗,则难。如果像周末午后般闲适喜乐,或可。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【2】观测能力制约认知水平【2023-01-02】","slug":"日知录/【2】观测能力制约认知水平【2023-01-02】","date":"2023-01-01T16:00:00.000Z","updated":"2023-01-02T14:42:29.552Z","comments":true,"path":"日知录/【2】观测能力制约认知水平【2023-01-02】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%902%E3%80%91%E8%A7%82%E6%B5%8B%E8%83%BD%E5%8A%9B%E5%88%B6%E7%BA%A6%E8%AE%A4%E7%9F%A5%E6%B0%B4%E5%B9%B3%E3%80%902023-01-02%E3%80%91/","excerpt":"","text":"观测能力如何制约认知水平? 调试内核代码有感:对gdb调试掌握不熟练,会极大地阻碍“观测-思考-行动-反馈”循环,在正确性、速度、心理动力等一系列维度阻碍写代码。 仔细一想,“观测-思考-行动-反馈”循环起于观测、回于反馈,而常言中以强调思考和行动者居多。 这重要却模糊的地方,该探索思考 控制理论,可以提供一套更复杂的类比。而且看得见摸得着的物理结构似乎更有可操作性。 eval和apply循环,在环境中实现自身的递归定义、自我解释。“观测-思考-行动-反馈”也是在环境里递归构造自我。eval/apply构建的解释器多种多样,相比之下,“观测-思考-行动-反馈”的描述则模糊得异常。 这样的异常,在人生其他维度里还有多少?视而不见,听而不闻,或许是因为无法有意识地识别信息流里的模式。假如有意识地改造,要如何才能改得足够敏锐? 先用“观测-思考-行动-反馈”循环来改造“观测-思考-行动-反馈”循环。重点方向:写代码、学习方式、关于人的认知。 改造“观测-思考-行动-反馈”循环的启示 使用 调研-设计-写码-调试。启示:如果知道可用的工具有哪些,那么在没有发明新工具的情况下,工具的选择与使用能力也是一大要事。 定理证明。启示:知道不等于理解、不等于会用。即使知道同样的基础操作,并不意味着能想到怎么解决问题。 知识索引与组织。启示:知识无法检索和提取,就像钱不知道借给了谁,这种情况下的钱不会在交易中被认可。 产业实际问题、源码、博客、教科书、lab与demo。启示:从创生、流动、噪声等角度思考,很有意思。 改造方向 望远镜。启示:可以改造精度。另一启示:牛顿与胡克的望远镜之别,说明工具本身的制作也很重要。 监控。启示:自动化观测。 性质与意义 中医与胃镜、肠镜。启示:多一种观测工具,则可以多一条反馈验证循环的通路。另一启示:成本制约。 显微镜、化学试剂、高精度天平。启示:新的工具可能意味着知识新世界。另一启示:一些论断需要高精度的观测工具提供证明。 双缝干涉。启示:观测与事实的相互影响。 考古文物与历史。启示:文物中提取的历史信息和文字构建的历史,二者在认知真实世界的重要性上差别极大。 诈骗的信息流。启示:系统偏差、相互印证、自恰与体系排斥。又想到《语言、真理与逻辑》所言,以及科学共识的变化方式。 他山之石,可以攻玉。启示:每一种额外的知识储备,在找到沟通点之后,可以成体系地转换出启发思路。 其他有意思的问题 人如何发现未知的他人?人如何观测他人?有什么观测方法? 人如何观测自己?有什么观测方法? 潜在的论域? 如何观测一个组织? 抽象世界的观测如何改造精度?已有多少通路?习惯与机器自动化? 观测如何影响事实本身? 是匮乏还是超载?怎么探寻、选择与加工……? 在溯源工作结束后,已形成的认知体系还会有哪些性质浮现出来? 观测怎么导向行动?正确的观测能否导向正确的行动?系统偏差的观测如何导向系统偏差的行动? 是否存在锁死困局?人是否可能意识到自己在何种意义上被锁在了某个困局?如何清醒? 提问时怎么发现不知道的应该知道之事?行动如何带来变数?事实是以何种方式打破“提问-自己解决”循环的?* 怎么样是一个封闭的运算系统? 一些行动思路 现有的各种学习方法中的信息流以及其间的“观测-思考-行动-反馈”循环,需要系统地改造优化。 了解行业历史,可能有比想象中更丰富的途径。 尽早参与多个领域的实际工作,这样才有实际的问题来练手如何解决。从局势创生与变化的角度而言,接触到行业高手或许更容易发现变局中的有效变量、格局运转背后的规则或规律。有空可能还需要看一些管理学的书。 可能最好补充一点抽象代数的知识。整理一下科学技术史、科学哲学世界观的知识。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"【1】兔年开启修行【2023-01-01】","slug":"日知录/【1】兔年开启修行【2023-01-01】","date":"2022-12-31T16:00:00.000Z","updated":"2023-01-02T14:31:59.070Z","comments":true,"path":"日知录/【1】兔年开启修行【2023-01-01】/","link":"","permalink":"https://longguzzz.github.io/%E6%97%A5%E7%9F%A5%E5%BD%95/%E3%80%901%E3%80%91%E5%85%94%E5%B9%B4%E5%BC%80%E5%90%AF%E4%BF%AE%E8%A1%8C%E3%80%902023-01-01%E3%80%91/","excerpt":"","text":"日知录 一年半了,时间无情,已是2023。2023是兔年,联系一下现实,恰如龟兔赛跑。 兔子的第一弱点:无法理解乌龟究竟在什么层面、什么意义上更快。这是观察能力在一整个维度上的缺失。糟糕的是,缺失的不仅是对他者的观察能力,还有对自我的观察能力:兔子不仅仅是不知道一起比赛的乌龟比自己快,而且还不知道自己其实很慢。更严重的是,在缺乏自我观察能力的同时,还滋生了幻觉,并且让幻想影响了决策:兔子还不知道自己不仅很慢,而且误以为自己很快。在这种自以为速度快的幻觉下,兔子已经深深地自我催眠,被自我给反锁在了白日梦中:“我一旦醒来,就能追上。”这样的自我麻醉已经深入脑髓,侵入到了中枢神经系统的每个角落。时间再长下去,恐怕就连肌肉也要开始萎缩了。 “假如兔子醒来,而且变得比乌龟更疯狂?”这就是典型的兔子幻想。切记,这类想法有毒。自以为是兔子的人,总会幻想自己有了乌龟的稳定输出能力会发生什么。而乌龟并不反向幻想自己会如何蹦蹦跳跳,它只是在堡垒中一步一步前进。对于兔子而言,只有当兔子明白:“我跑不了那么快,我实际上只能跑……,所以我应该……,然后要……”的时候,只有兔子认真考察“用30天的尺度来看,自己的速度究竟如何?快吗?慢吗?”的时候,兔子才算刚刚启程。 总而言之,认真做好有效的事。踏实才能稳,稳才能由时间来积累效果。典型的例子就是,每天稳定积累8小时胜过一次发作14小时后中断数天。900页的书,每天稳定看60页比一天看120页然后休息四五天要更好。 所以,日知录,关键在于没有借口地稳定持续前进,关键在于时间的力量。 什么叫“认真做事”? 《张一鸣:我遇到的优秀年轻人的5个特质》 “工作前两年,我基本上每天都是十二点一点回家,回家以后也编程到挺晚。确实是因为有兴趣,而不是公司有要求。” “当时我负责技术,但遇到产品上有问题,也会积极地参与讨论、想产品的方案。很多人说这个不是我该做的事情。但我想说:你的责任心,你希望把事情做好的动力,会驱动你做更多事情,让你得到很大的锻炼。” 《张一鸣:成功与否并非创业的根本原因》,2014年,张一鸣做客财视传媒《超级脱口》节目的讲话 其实,我并非从大学毕业后就一直创业,2008年,我曾入职微软。在很多人眼里,微软是一个很不错的公司,也是很多年轻人梦寐以求想进去的公司。所以,我选择离开就更难让人理解了,他们会猜测是不是在微软有一些东西束缚了我,或者说是我在微软有过不愉快的工作经历? 实际上,我在微软并没有什么不好的东西,大家真的是想多了。我只能说不同的人有不同的追求,对公司的期望值也是不一样的。所以,无论多么好的公司都会有人选择留下来,有人选择离开,我觉得这是正常的。至于我为什么离开微软,可以简单得用两个字概括一一无聊。 我在微软工作期间,基本上是半天看书,半天工作,并没有很多具有挑战的事情去做。很多时候都是比较清闲的,而这种工作状态却不是我想要的。有很多想做的事我并不能去做,因为我不能在工作的时间做大量自己的事情,而在这种情况下,我就会感到很无聊,做事没有挑战性,没有激情。 不过,幸好有那段比较清闲的时间,我才有机会看了很多书,像稻盛和夫的《活法》、《The Seven Habits of Highly Effective People》,还有《TheFive Dysfunctions of a Team》等等,前两本书对我影响很大。 除了爱抠手机,我的本职工作就是对着电脑写代码。我是一个技术宅男,幕后工作是我的强项,我也很享受这个过程,直到现在也是这样的。以至于我给员工们的印象都是“一个没什么爱好的‘码农宅男’”,每当他们这样说我时,我就感到很委屈:我有爱好的,我的爱好是获取信息! 创业以后,因为工作需要,我必须从台后走到台前,对于这个转变,我有些不习惯、不适应,我仍然喜欢做默默无闻的角色。一般对于采访,我都有点逃避。前些天,我还跟几个同事讨论技术问题,一直讨论到十二点半,我好久都没有参与讨论技术问题了,我想念这样的状态。技术攻坚的好处,是你可以把想法到实现更完整地贯通,从你提出想法开始,到设计编码上线,整个过程你都可以非常惊喜地参与,非常惊喜地把你的想法实现。这个过程对我来说,是一种享受,是一种惊喜,更是一种成就。但是,我不能总沉浸在这种惊喜和成就感之中,随着公司发展得越来越大,我需要更多的人来配合做这件事,只有这样,我才能腾出时间跟外界有更多的交流,获得更多的信息输入,这对我来说非常有帮助,对公司的发展也有利。所幸,我拥有一个非常棒的团队,来和我一起工作。 《南开校友、今日头条创始人张一鸣在2016级新生开学典礼上的讲话》 但我没沮丧很久,就慢慢地从安静朴素的校园和踏实努力的氛围中,找到了自己的节奏:我决定换专业,去软件工程。原因是,我发现相比于在面包板上做正弦波信号发生器,我对计算机更感兴趣。大一的时候,我就泡在“我爱南开”BBS网页开发技术版,用现在话来说,算小网红了。转专业第一天,发现软件工程的老师也都知道我。 我是想告诉大家,也许对你们其中的一些人来说也是一样,兴奋感褪去后,渐渐发现,大学生活不如自己想象的那般丰富和刺激。大学以前,我们按部就班的生活,没有太多自主选择。但大学开始,个人选择开始变得格外重要,越早认识到这一点,大学阶段的收获就越大。 说回到我的大学生活。其实,转院后,生活也没多大变化,依然是日复一日,图书馆啊,实验室啊。怎么面对枯燥的生活? 看书。寂寞的大学生活,给了我人生最安静的阅读时光。不论是幽静的老图,温馨的泰达学院图书馆(我觉得是世界上最好的校园图书馆,真的很棒,你需要哪本书,只要在BBS上留个言,他们就会买回来,而且会买很贵的书,按美元计价的书),还有高大上的泰达开发区图书馆(因为就在附近所以也常去蹭)。我用别人打游戏、打牌的时间,阅读了各种各样的书,或者说乱七八糟的书,包括各个专业的书,包括人物传记,也有各种境内外的报刊杂志。 看书看累了,我就到新开湖畔发个呆,或者在泰达公园散步,给自己列出各种各样与短期目标无关的问题来思考。这些问题对短期确实没有影响,但有这样的环境,去思考长期问题挺好的。 当然,那时候,我也有困惑,觉得看的这些东西和思考的问题都很有意思,但在生活中没什么用。直到后来我进入互联网行业并开始创业,各种各样的知识才发挥作用,帮我理解行业、理解管理,更快地掌握不熟悉的领域。 另外,不得不说,人物传记是非常好的心灵鸡汤。我读了很多人物传记,如果说有收获,就是发现那些伟大的人,在没有成为伟大的人之前,也是过着看起来枯燥的生活,每天都在做一些微不足道的事情,但这些事情最后从点连成线,成就了他们。 我毕业后参与创立了酷讯、饭否、99房、到现在的今日头条,每一段创业经历,都挺寂寞的,尤其在苦闷纠结的时候。前些年,创业环境还不像今天,一堆公司都在五道口华清嘉园、东升园创业,平时在居民楼里查资料,研究用户需求,敲代码,谁也不认识你,也可能你的想法都不错,但不会马上转化到产品上,你必须要承受那样的漫长时光的煎熬。现在回想,耐心非常重要,不仅是等待的耐心,还要有耐心做深入思考,还要有耐心地找到更多更好的合作伙伴。 所以我觉得,有些心智,确实需要在南开这样安静的环境里才能培养,比如耐心,比如踏踏实实做事,做事情不讲捷径,尽可能基于长期来做思考。创办今日头条至今,每天都面对很多诱惑,包括来自巨头很好的offer、天价的并购,我们都坚持住了。这离不开南开的熏陶,我时常想南开那么漫长的寂寞我都熬过来了,还怕什么,对吧。 《还好,张一鸣不是个书呆子》 张一鸣小时候特别喜欢看书,读初中那会儿,没有手机、互联网,他回忆说:“我初中时一周要读二三十份报纸,从本地报纸到《人民日报》,每一个字都不会放过。”从初中到刚工作那段时间,每周四下午他就有点高兴,因为能买到《南方周末》。 2006年3月,大学毕业折腾过短暂创业的张一鸣加入当时知名的公司酷讯。面试者认为,眼前的这个小伙子说话虽然结巴,会脸红,但技术不错,是个聪明人。张一鸣最开始只是个普通工程师,但工作第二年,他就开始管理四五十人的团队,成为技术委员会主席。至于为什么升职这么快,张一鸣给的理由是工作不分份内份外,啥都做。他经常加班,看了公司所有人提交的代码,搞定了其他人搞不定的bug,还跟着销售员一起见客户,学营销。 但到了2008年,张一鸣对酷讯的印象却是管理混乱和方向不明。公司就搜索业务争执不下,失去转型的机会;招聘的数量和质量都跟不上。福建老乡王兴抛出橄榄枝,但他不干,说是要先到大公司去学管理。2008年的春天,他加入了微软。在微软,这位技术工程师像个老干部,每天改改模块,工作只需要3、4个小时。几个月后,他觉得工作太无聊,离职,以技术合伙人身份加入王兴的饭否。 2008年的中国经历了5.12地震和奥运会,2008年的张一鸣从酷讯到微软再到饭否,连换了三个工作。在微软,为打发无聊,他看了不少书,等遇到超爱看书的王兴,他的阅读量大概有了一次飞跃。也就从2008年开始,他开始将自己的阅读痕迹留在豆瓣上。那年春天,他想读的一本书是《像外行一样思考,像专家一样实践》,那年的12月2号,他标记的已读图书就有8本,这些大概就是他大学读过的书。这些书里,有提升效率的《SEVEN HABITS OF HIGHLY EFFECTIVE PEOPLE》(高效能人士的七个习惯),有冯仑、王石、联想的企业传记,还有为饭碗镀金的专业教材。 2009年8月,饭否关闭,9月,张一鸣离开王兴,创立了九九房。跟王兴合作的一年时光,老大哥总会列书单给他。 那时,他26岁,想知道成功能否复制,就问王兴,有没有人同时做成两家世界500强的公司。王兴说,有个日本的企业家叫稻盛和夫。张一鸣在地摊上买了稻盛和夫的《活法》,书上说,人活着是修炼自己的灵魂。张一鸣觉得这话太虚了,看到中间,稻盛和夫认为努力工作、精进是一种修炼方式,他才感到认同。 离开王兴,张一鸣又读了一遍《UNIX环境高级编程》。之后任九九房CEO的两年多时间,他读了33本书,除了他一贯爱看的心理学书籍,大多是创业以及商业管理类。 去年,《财经》记者问张一鸣,对他个人影响最大的书是什么。他列了《活法》、《少有人做的路》、《高效人士的七个习惯》、《基础生物学》几本书。这些书,都是他在2022年以及之前看的书,后来都成为张一鸣的演讲灵感。去年媒体圈流传的《张一鸣10年面试2000个年轻人:混得好的都有这5种特质》跟《活法》的中心思想很类似。 几个特点 大可以一口气搜来所有的文章,罗列分析上数十个特点。这种猛冲的行为便是兔子急躁的表现。宁愿一次只分析两三点,每个月牢牢把握住一两点。这样的行为才是兔子虚心学习的表现。 【特点1】一年如果看了33本书,一个月是看3本左右。10天一本。一天在有大量工作,并且把工作做好的前提下,仍然能看40页左右的书。 【特点2】因为兴趣而编程,整个过程是成就感驱动的享受。比如,“技术攻坚的好处,是你可以把想法到实现更完整地贯通,从你提出想法开始,到设计编码上线,整个过程你都可以非常惊喜地参与,非常惊喜地把你的想法实现。”比如,“工作前两年,我基本上每天都是十二点一点回家,回家以后也编程到挺晚。确实是因为有兴趣,而不是公司有要求。”比如,“至于我为什么离开微软,可以简单得用两个字概括一一无聊。” 【特点3】耐心。“踏踏实实做事,做事情不讲捷径,尽可能基于长期来做思考。” 这个月就一个目标 无他。不走捷径,下功夫磨炼系统编程、网络编程方面的技术。有点时间闲了,就享受阅读的过程。","categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"}]},{"title":"信息行业发展简史","slug":"前端/000 信息行业简史","date":"2022-07-31T16:00:00.000Z","updated":"2022-08-02T03:22:10.036Z","comments":true,"path":"前端/000 信息行业简史/","link":"","permalink":"https://longguzzz.github.io/%E5%89%8D%E7%AB%AF/000%20%E4%BF%A1%E6%81%AF%E8%A1%8C%E4%B8%9A%E7%AE%80%E5%8F%B2/","excerpt":"(本文为0.1版,尚未完成,写偏的部分、混乱的部分待未来修改。时间紧迫,得先干别的事去……) 本文目标: (作者才接触后端一小段时间,入门前端也不久,尝试以有限的经验,尽可能)搜集网络上对前端发展趋势的看法,并做出自己的思考。 结合历史发展的角度思考前端,以及,思考当新手完成基本技能训练之后,还可以有什么样的上升空间。","text":"(本文为0.1版,尚未完成,写偏的部分、混乱的部分待未来修改。时间紧迫,得先干别的事去……) 本文目标: (作者才接触后端一小段时间,入门前端也不久,尝试以有限的经验,尽可能)搜集网络上对前端发展趋势的看法,并做出自己的思考。 结合历史发展的角度思考前端,以及,思考当新手完成基本技能训练之后,还可以有什么样的上升空间。 互联网发展历史 首先要问这样一个问题:历史上的Web浪潮与变化究竟是怎么样的?不同的人从不同的角度去理解Web的变化。在这里根据维基百科,结合前端开发 20 年变迁史 - 知乎做一个简单的梳理。 切入点一:技术 万维网 - 维基百科,自由的百科全书构想起源(1989之前): 1980年英国科学家蒂姆·伯纳斯-李 (Tim Berners-Lee) 构建ENQUIRE项目。这是一个类似维基百科的超文本在线编辑数据库。 蒂姆·伯纳斯-李于1989年在《关于信息化管理的建议》一文中提及ENQUIRE并且描述了一个更加精巧的管理模型。 万维网技术基础搭建(1989~1995): 1990年他在瑞士CERN的工作期间编写了第一个网页浏览器。 1991年1月,网页浏览器向其他研究机构发行,并于同年8月向公众开放。 1991年底蒂姆·伯纳斯-李在一个名为HTML Tags的文件中提及**HTML**。 1993年,CGI(Common Gateway Interface)出现了,人们可以在后端动态生成页面。但是非常慢,所以人们从多方面着手改进:编写语言的升级、浏览器的升级、HTML的升级(1993年中期互联网工程任务组(IETF)发布首个HTML规范的提案)。 1994年,网景公司成立,发布了第一款商业浏览器Navigator。 1994年,PHP诞生。PHP能将动态的内容嵌入到HTML中,提升了编写页面的效率与可读性。 1994年10月,W3C小组成立开始制定一系列标准,并督促网络应用开发者和内容提供者遵循这些标准。 1994年,哈肯·维姆·莱和伯特·波斯合作设计CSS。他们在1994年首次在芝加哥的一次会议上第一次展示了CSS的建议。 1995年,JavaScript诞生了。JavaScript只用了10天设计,充满缺陷和瑕疵,其两大任务就是完善语言特性与提高性能。 1996年,微软发布VBScript的第一个版本1.0。只有IE浏览器能用VBScript。 1996年12月发表的CSS1。 1997 年,W3C 颁布CSS1.0版本 ,CSS1.0 较全面地规定了文档的显示样式,可分为选择器、样式属性、伪类 / 对象几个部分。随即微软和网景公司的浏览器均能支持 CSS1.0。 1998年5月,W3C发表了CSS2 早于1999年, CSS3已经开始制订。 2001 年,微软发布了 IE6,在 Windows 普及的年代 2002年,IE6 浏览器占据了高达 80% 的市场 2003年,IE6 浏览器占领 95% 的市场 2006年10月推出了IE7 2006年,jQuery发布 2008年,Chrome发布,在最初的激增之后,使用率下降,直到2008年10月跌至0.69%的低点。然后再次开始上升,至2008年12月,Chrome再次超过了1%的门槛。 2009年3月推出了IE8 2009年5月28日,Node.js诞生 2009年,jQuery将Sizzle选择器引擎引入核心,取得压倒性的优势 2010年1月,一款名为npm软件包管理系统诞生 直到2011年6月7日,CSS 3 Color Module终于发布为W3C Recommendation。 W3C于2011年9月29日开始了设计CSS4。但直至2022年只有极少数的功能被部分网页浏览器支持 切入点二:商业 思考这样的问题:中国互联网在信息行业发展的不同时代有哪些大佬? 张一鸣在2008年从南开软件工程专业毕业的时候,互联网行业是什么大环境? 王兴2001年于清华大学无线电专业毕业,2003年中断美国特拉华大学博士学业回国创立校内网的时候,互联网行业是什么大环境? 李彦宏 马云 马化腾 黄峥 谁被清理出了历史舞台?谁将会被清理出历史舞台?为什么? 各个竞品之间的相互竞争历史?比如微视和抖音? 不同创业者的重大决策? 哪些当年很火的东西现在已经消失了? 政策对互联网发展的影响? 从这个历史变化的角度,对于前端的技术选型、应该学什么,有什么样的启示? 大厂的思考方向、技术应用场景、历史。 HTML入门写法 待办 [ ] 在万维网诞生前的互联网历史以及行业状态 [ ] 在互联网诞生前,信息行业的发展 [ ] 中国互联网历史 [ ] 大厂的技术公众号 [ ] 一些技术方面的重大事故 参考资料 互联网 - 维基百科,自由的百科全书 万维网 - 维基百科,自由的百科全书 HTML - 维基百科,自由的百科全书 层叠样式表 - 维基百科,自由的百科全书 VBScript - 維基百科,自由的百科全書 前端开发 20 年变迁史 - 知乎 Node.js - 维基百科,自由的百科全书 2022 年前端趋势的 6 个预测 万维网联盟 - 维基百科,自由的百科全书 css发展历史 - Google 搜索 CSS 二十年发展简史 - 掘金 Internet Explorer 6 - 维基百科,自由的百科全书 jQuery - 维基百科,自由的百科全书 Google Chrome - 维基百科,自由的百科全书 移动互联网 历史 - Google 搜索 中国互联网25年变迁:两次跃迁,四次浪潮,一次赌未来 | 人人都是产品经理 1994-2018年,中国互联网发展历程! - 知乎 中国互联网20年简史(1998-2018):其中的规律与本质是什么?-T媒体 全球互联网50年:发展阶段与演进逻辑 - 安全内参 | 决策者的网络安全知识库 本文历史轨迹 2022-08-01 0.1版本 内容从技术的角度观察了1990到2010的万维网发展历史。稍微看了一下互联网大佬的情况博客写作小结:往大的方向写的话,太耗时间,不是很值得。以后写作前要用SMART法则限定一下,尤其要限定时长、字数。时间是有限的。另一个方式就是,把主题限定一下,大主题分成几个小主题来完成。文章给出参考的资料集就可以了,事实的部分没有必要摘抄太多,只需要给出必要部分。只输出有价值的部分,节约时间。有价值的部分,指的是:提出并思考自己感兴趣的问题。比如,非常理的奇异点。推理所依据的事实信息出处。推理判断的逻辑。难获取的思考材料,主要是自己的整理和思考结果。比如,没有人思考过的内容就无法被搜索到。一些整理性质的内容,如果有人想到并做过但是没有发表,那么也无法被搜索到。诸如此类。需要更有效地采集、聚合、管理信息。2个小时,阅读和写作,才写了大约1500字的内容,速度偏慢。需要重新设计写作方式。写到后面写偏了,从前端和技术开始往信息技术和全行业概况的方向上偏……可能需要专业人士的一些交流。","categories":[{"name":"技术-前端","slug":"技术-前端","permalink":"https://longguzzz.github.io/categories/%E6%8A%80%E6%9C%AF-%E5%89%8D%E7%AB%AF/"}],"tags":[{"name":"历史-技术","slug":"历史-技术","permalink":"https://longguzzz.github.io/tags/%E5%8E%86%E5%8F%B2-%E6%8A%80%E6%9C%AF/"},{"name":"行业-互联网","slug":"行业-互联网","permalink":"https://longguzzz.github.io/tags/%E8%A1%8C%E4%B8%9A-%E4%BA%92%E8%81%94%E7%BD%91/"},{"name":"商业-创业","slug":"商业-创业","permalink":"https://longguzzz.github.io/tags/%E5%95%86%E4%B8%9A-%E5%88%9B%E4%B8%9A/"}]},{"title":"前端技术初步","slug":"前端/010 前端技术初步","date":"2022-07-31T16:00:00.000Z","updated":"2022-08-01T14:56:44.040Z","comments":true,"path":"前端/010 前端技术初步/","link":"","permalink":"https://longguzzz.github.io/%E5%89%8D%E7%AB%AF/010%20%E5%89%8D%E7%AB%AF%E6%8A%80%E6%9C%AF%E5%88%9D%E6%AD%A5/","excerpt":"HTML+CSS+简单的JS 基础入门,包含一些学习方案的想法和基础知识点小结","text":"HTML+CSS+简单的JS 基础入门,包含一些学习方案的想法和基础知识点小结 前端入门学习方案 (以下为个人观点,正确性有待商榷) 知识点相对零散,逻辑关联弱,体系性弱。(至少不像操作系统开发那样系统,也不像计网一样有那么多层层层层层层层)。由于直接面向用户,其变化背后的逻辑是应用需求的快速变化。人们产生了什么应用需求,前端工程师就做一种相对直观的开发,浏览器厂商就在相应需求上抽象出什么样的功能,W3C就往相应的方向设计标准。知道HTML标签数量的历史变化,显示中使用频率的分布情况,就会明白正确的学习大方向。根据amdahl法则,应该把主要的时间用来学主要部分。切忌买HTML的书,对于非职业前端开发来说更是如此…… 写太长了,没必要花太多时间写这么长,之后写短一些…… 学习方式: 时间有限,不学没必要学的内容,不做没必要做的事情。 怎么高效动手:基本编辑方法,如何在一些编辑器里,用Emmet快捷写代码,snippet快捷写码 怎么专业地解决问题:专业参考资料如MDN等,chrome的调试方法 怎么有效地积累项目经验: 预估掌握技能点需要学什么,做好计划和安排 找到合适的项目,上手 内容重点: HTML和CSS的效果直观,效果传递的逻辑链短。 关键在建立知识分类框架、视觉直观经验、足够的间隔练习。整体上,刻画一个正确的大致轮廓,而后应靠动手在框架中补细节,再依靠间隔重复慢慢累积经验。 从应用的需求匹配学习的内容,术语和专业表述的部分通过MDN学。 不要深入旧东西的细节。比如,像是IE兼容性这些,花时间弄这些不如研究一下历史。 html基本数据结构。树的各节点及属性是什么,以及表达的语法。 html和CSS,积累视觉效果和代码的对应关系经验,积累相应特性可以应用在什么场景的认知。 写写写。这部分的开发主要依靠肌肉记忆、感知能力,对正确性的要求不像算法、并发编程这些。所以关键是写到熟。(看到熟也不行。) JS开发。 JS的整体设计缺陷臭名昭著,虽然语法简单上手快,坑会很多。JS部分不错。或许可以整理一份“怪异表”,然后在需要排错的时候参考。通过反复练习,学会这些边边角角的东西。 JS应该尽量按现代的方式使用,这样相对而言不会太痛苦,。旧的糟粕部分应该淘汰,只使用js的一部分子集。JS的新标准语法,正确使用姿势,在项目中练主流框架,熟悉基本的开发流程。 关键点在于,怎么样通过React, Vue和NodeJS减少开发的复杂度。 往深一点,学会依据框架背后的设计思想正确使用框架,提高开发速度,提升性能效果。 越快进入React, Vue, NodeJS项目的开发越好。 HTML基本内容 内容框架:(Emmet一个感叹号) 123456789101112<!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title></head><body> </body></html> (概念过一遍后,用自己的话默写练习一遍,再纠正一遍,熟悉概念:) 整个文件的元数据:title标题,style直接写样式表,link引入外部资源。base设置根基址,meta是其他元信息,细节之后看。 整个文件的结构:html根,base根URL,head配置元信息、body放内容。 给内容划分结构方面语义的标签: header、main、footer和aside分出和视觉匹配的逻辑结构; article、section、nav分出内容结构; div、span圈定或者分隔出内容整体; hr水平线、br换行进行分割; 文本内容,配合整体语义标注: p段落、ol有序列表、ul有序列表、li列表项、dl描述列表、dt术语、dd描述项; blockquote块引用、quote引用;table表格、tr行、th表头、td是table data;colgroup列组、col列、caption标题; pre保留空格、code代码显示 内容细节标注的语义:h1~h6标题、a可跳转、em强调、strong重要、s删除线 图像和多媒体内容:audio音频、img或picture图片、video视频、svg矢量图、math数学公式 数据和交互 脚本:canvas画布,script主要是JS脚本 数据交互的表单:form整体表单、input提交的数据项、label说明提交数据项的标签、button提交按钮;select和datalist选择列表、option选项、optgroup选项分组;textarea一大块写文本区域 1、2、6主要是文件、交互相关的内容,适合web的场景,换一块地方可能就失效了;3、4、5偏内容资源,就内容的层面上来说,这些资源可以转移到其他桌面应用中。 所有标签都有的属性: 样式相关的class, style, hidden 控制相关的 id, contenteditable, tabindex 还有一个方面的 title 参考资料 HTML 元素参考 - HTML(超文本标记语言) | MDN 本文历史轨迹 2022-08-01 0.1版本 接下来一段时间怎么学前端。加入初级的HTML内容","categories":[{"name":"技术-前端","slug":"技术-前端","permalink":"https://longguzzz.github.io/categories/%E6%8A%80%E6%9C%AF-%E5%89%8D%E7%AB%AF/"}],"tags":[{"name":"HTML","slug":"HTML","permalink":"https://longguzzz.github.io/tags/HTML/"},{"name":"CSS","slug":"CSS","permalink":"https://longguzzz.github.io/tags/CSS/"},{"name":"JavaScript","slug":"JavaScript","permalink":"https://longguzzz.github.io/tags/JavaScript/"}]}],"categories":[{"name":"日知录","slug":"日知录","permalink":"https://longguzzz.github.io/categories/%E6%97%A5%E7%9F%A5%E5%BD%95/"},{"name":"技术-前端","slug":"技术-前端","permalink":"https://longguzzz.github.io/categories/%E6%8A%80%E6%9C%AF-%E5%89%8D%E7%AB%AF/"}],"tags":[{"name":"2023-01","slug":"2023-01","permalink":"https://longguzzz.github.io/tags/2023-01/"},{"name":"历史-技术","slug":"历史-技术","permalink":"https://longguzzz.github.io/tags/%E5%8E%86%E5%8F%B2-%E6%8A%80%E6%9C%AF/"},{"name":"行业-互联网","slug":"行业-互联网","permalink":"https://longguzzz.github.io/tags/%E8%A1%8C%E4%B8%9A-%E4%BA%92%E8%81%94%E7%BD%91/"},{"name":"商业-创业","slug":"商业-创业","permalink":"https://longguzzz.github.io/tags/%E5%95%86%E4%B8%9A-%E5%88%9B%E4%B8%9A/"},{"name":"HTML","slug":"HTML","permalink":"https://longguzzz.github.io/tags/HTML/"},{"name":"CSS","slug":"CSS","permalink":"https://longguzzz.github.io/tags/CSS/"},{"name":"JavaScript","slug":"JavaScript","permalink":"https://longguzzz.github.io/tags/JavaScript/"}]}