不多说了，直接贴代码吧，也是从别人的配置上拿到的，在他的基础上加了一些功能（支持了搜索、刷新）。这就是emacs之道吧，看了别人的菜谱，自己也可以方便地抄过来改吧改吧，希望可以帮助到有需要的人。 依赖了helm 和markdown-mode ;;; outline-wiki.el --- Outline Wiki tools for Emacs -*- lexical-binding: t; -*- ;; Copyright (c) 2019 Abhinav Tushar ;; Author: Abhinav Tushar <[email protected]> ;; Version: 1.0.1 ;; Package-Requires: ((emacs "26") (helm "3.7.0") (markdown-mode "2.4") (request "0.3.2")) ;; URL: https://github.com/lepisma/outline-wiki.el ;;; Commentary: ;; Outline Wiki tools for Emacs ;; This file is not a part of GNU Emacs. ;;; License: ;; This program is free software: you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation, either version 3 of the License, or ;; (at your option) any later version.

硅基生命 人类发明了机器，机器又开始不断地演进，发展。一开始我们觉得这些机器很简单，其中不可能蕴含任何所谓“生命”的气息,但是技术的演化速度是指数级别增长的，现在这些机器的结构已经不是人类能够轻易理解的了（而且这一切还在继续）。我们无法确定是否在某一天开始意识也在其中悄悄萌芽。 人类与机器 我们已经无法离开机器了，他是我们工作生活的巨大助力。人类和机器的关系更像是自然界的共生关系；像人类和我们肠胃中的肠道菌群一样相互需要，只是不知道最终我们是菌群还是机器是菌群😀 。 冲突与矛盾 大多数科幻电影中畅想的硅基生命是另一个物种一样的存在，和外星人降临地球类似—–一山不容二虎。两种生命追求的是同一种有限的资源么？我想不是。硅基生命维持基本生存的基础是能源和算力，人类生活的基础是空间和食物（当然我们也需要能源），可是这两者几乎是互补的，硅基生的出现也加速了我们的生产效率本身也创造出了更多的资源，这是1+1>2的，为什么其中一方一定要消灭另一方呢？

这是一种整理和记录笔记的方式，将笔记作为自己的外脑，最大化地利用起来，希望可以产生出新的理念和想法，发生思维的碰撞。发明这个方法的是一个卢曼的社会学家，他也是（据说）使用了这套方法，自学并成为了以为杰出且高产的社会学家。 先把本书的目录结构整理如下 绪论，关于写作 要知道的 一般的笔记记录方法是什么？ 一般大家都会在文献边上记录下自己的一些想法，还有的人可能会摘抄下来。笔记存在的价值一般就只有一段时间，过一段时间之后往往这样的笔记价值就大大降低了。 记笔记其实有两个目的： 记录有价值的信息和自己的思考 为后续的思考，整理加工提供素材 笔记作为我们的外脑的价值就在于此 什么是卢曼卡片法呢? 第一点，将所有的笔记记录在小卡片上，记录完成之后会有对应的分类：文献类、思考类。文献往往是现有资料在自己咀嚼之后的记录，思考是自己的想法。每张卡片都有一个自己的编号，不一定按照主题分类，只是用来做一个唯一的标志。 第二点，定期整理和回顾。卡片的好处是小，不是一本书一大份笔记，不同的笔记之间会有相互链接，整理的时候也可能发现新的连接关系。这样的定期回归就会将认知之间的关系，网状图构建起来，还有可能发展出新的认知。 要做的 要具备的能力 要注意的问题 基本原则 写作是唯一重要的事情 简洁最重要 没人完全从0开始 写作不是一个线性的事情。重点在于平时的积累和阅读，有了足够的输入才能有足够的输出。没有人是确定好选题，找资料，阅读然后再选择输出的。合理的流程是跟随自己的兴趣去了解，阅读，积累，笔记。在需要写作的时候从卡片中整理灵感和写作的主题，将他们整理成一片文章。写作不是一个线性的过程，而是一个循环过程。 这里有些类似代码的编写，往往合理的开发流程不是一蹴而就的流程，设定好需求，开发，上线。往往是一个慢慢迭代的流程，但是大多的开发流程设计中认为这是一蹴而就的过程，一旦上线需求就结束了，并不是这样的。windows的开发流程中也会设计这种tik tok的过程，需求实现一版本，优化一版本，不停地循环往复，在迭代中改进现有的逻辑和质量，也反思以往的不足。这才是一个合理的流程逻辑。 让工作推动你前进 寻找更加及时的反馈，可以让你更加爱上一件事情，学习和笔记也是。 卡片笔记法还有个好处是：随着卡片越来越多你能获得的链接数量是指数级别上升的（理论上）可以让你更加及时地获得反馈，这就能让你更好地爱上这件事情。 成功写作的六个步骤 明确区分独立又相互关联的任务 一次只做一件事情,不要一心多用 保持专注一次只做一件事情,不要并发地去做事情，来回的上下文切换会导致效率低下，这个和计算机的处理方式有点像，上下文的切换是有成本的。协程、线程、进程之间切换的时候会涉及到context的保存和导出，成本太大了。 每种任务需要的关注程度不一样 有些需要专注的思维，有些需要漫不经心地执行。例如编写大纲、草稿、校对等需要的专注程度都是不一样的 写作不一定有明确的计划 我的理解是可以有一个大致的计划，作者原文是完全不要有计划，专家是不按照计划来的。 专家应该是说已经对一件事情了如指掌了，所以不需要一个细化的计划，但是这就是胸有成竹的专家。作为新手可以有一个大致的计划，防止自己找不到方向，但是也不要被这个计划给束缚住了。朝着专家的方向发展，做到胸有成竹。 把写作作为自己的外脑，节省自己的精力 人的大脑是一个有限的机器，有限的存储，有限的记忆能力，有限的专注力。把笔记作为自己的外置硬盘，存储长期有价值的东西，cache中保存当前的工作上下文。一个长期合理的笔记流程可以让大脑不做那么多的决策，有助于把重要的事情放在第一，而不是被流程性的东西消耗太多的时间和精力。 下面是我自己的一些理解 阅读和理解 阅读的时候需要能够理解自己文献和输入，用自己的语言翻译内容，而不是照搬和copy原文 记卡片盒笔记 笔记的形式是卡片，内容体量不宜过大，简单但是精炼就行 发展想法 因为卡片之间是相互联系的，所以想法可以相互碰撞，可以发展出新的想法 分享你的洞见 从卡片盒里面发现了新的想法之后可以整理成完整的文章并将其分享出来 养成习惯 总结 卡片盒笔记方法的核心思路是将笔记的篇幅缩小，不要记录一本书一份笔记。而是一个想法一个笔记。让这些笔记之间可以相互链接，碰撞，成为思考时候的工具。

成长经历 “1959年12月6日出生于北海道。 毕业于东京工业大学工学部情报工学科。 大学毕业的同时，就职HAL研究所。 1993年，就任HAL研究所董事长。 2000年，成为任天堂株式会社董事、经营企划室长。 2002年，就任任天堂董事长、社长。 作为开发者， 他手中诞生了许多游戏杰作； 作为任天堂社长， 他策划推出了任天堂DS、Wii等革命性的游戏机， 并将自己所倡导的“游戏人口的扩大”付诸现实” 名人名言 “On my business card,I am a corporate president. In my mind,I am a game developer. But in my heart,I am a gamer.” “在工作中与人合作， 要让对方说出‘下次也想跟那家伙一起工作’。” 总结 聪哥的出生年代正好赶上了个人电脑和家用游戏机的快速发展的年代，他本人又是一个非常好奇、上进、有天赋的程序员。作为一个高中生，谁能拒绝一台可以编程的机器呢（笑）。合适的环境 加上个人的兴趣是聪哥进入这个行业的敲门砖，当然呢，他也找到了合适他的一个团队（一帮兴趣相同的人）。 组件了HAL实验室，除了做好本职工作之外，聪哥也随着hal实验室的业务发展从一个程序员学习并成为了一名优秀的管理者：没有架子，如果觉得只能是自己干就义不容辞坚决去做好一件事情，和公司成员进行一对一的面谈。 和宫本茂，技术加创意的组合，和系井重里那里学习，能难得地找到知音。 任天堂和苹果公司的设计逻辑很类似：他们都是产品和拥有用户视角的公司。乔布斯曾经被人质疑他不懂class是什么，但是指挥着一帮程序员在工作。老乔的回答大概是，我们也试过从技术出发，看看我们能造出什么东西来，但是造出来的东西不一定是用户需要的。任天堂也曾经为了游戏更好的画面投入了大量的财力来堆积游戏机的机能，但是最终的反响并不非常好，现在老任的游戏设计思路是先设计一个好玩的玩法，然后再丰富游戏的故事，剧情等等。苹果也是先找用户的诉求，明白用户需要的到底是什么，然后再来推动技术的落地。 先有问题，然后找解决方案；不要拿着锤子再来找钉子。

利用touch ID 免去 每次sudo都需要输入密码的烦恼。 修改sudo配置 sudo vim /etc/pam.d/sudo 在最上面添加一行 auth sufficient pam_tid.so 完成后结果如上。请强制保存。 修改Iterm配置 Iterm2上可能不会生效，Advanced > Session > Allow sessions to survive logging out and back in设置为No 试试看吧 问题 每次系统更新完成之后这个文件都会被覆盖，需要重新操作一次。 一个可行的解决办法是密码不要设置得那么复杂，但是如果密码太简单，又非常不安全，这真是一个两难的方案。所以我们需要在安全性和便利性之间做一下决断。

一起来画画 假如说我们有一些画画的能力。这里使用JS来举个例子 drawPoint({x: 0, y: 1}, 'yellow') drawLine({x: 0, y: 0}, {x: 1, y: 1}, 'blue') drawCircle(point, radius, 'red') rotate(shape, 90) ... 我们可以画一个点，画一条线，可以画圆，可以将图形旋转90度。 新的挑战 一般而言我们的这些能力我们都希望可以复用起来，不能开发一次就丢了，那就太浪费开发小哥哥的头发了。我们希望支持配置化，这意味着我们希望读取一些配置然后把不同的参数给不同的函数去执行，并得到一个结果。我们有个文件输入流，我们假定他叫stream 。 stream.on('data',data =>{ //TODO }) Eval 选择JS来举例子是因为JS可以使用eval，如果我们想偷懒的话可以直接使用eval来满足我们的需求。 stream.on('data',data =>{ eval(data) }) 我们只要在配置里面写上"drawLine({x: 0, y: 0}, {x: 1, y: 1}, 'red')" 就可以画一条线了。 但是。。。只要稍微有点经验的程序员就会建议你不要这么做，因为你不知道data里面具体是什么，这么做就相当于让你的系统在配置面前裸奔，天晓得他会调用什么方法，会发生什么。 看来我们不能用eval了，但是我们还是需要解决我们的问题，我们想让用户可以自定义到底要怎么画画（毕竟要赋能业务嘛 🐶） 简单的想法 我们可以用JSON来做一个简单的配置，配置好要执行的函数，这个函数对应的参数是什么就可以了呀。假定我们设计好我们的配置格式如下： { instructions: [ { functionName: "drawLine", args: [{ x: 0, y: 0 }, { x: 1, y: 1 }, "blue"] }, ]; } 我们拿到配置之后要做的就是将其翻译成对drawLine({x: 0, y: 0}, {x: 1, y: 1},"blue") 的调用就可以了。 感觉还是挺简单的。