最近读了一本书，名字叫《微习惯：简单到不可能失败的自我管理法则》。书很薄，内容也不复杂，不过感觉蛮有意思。书名非常概括，从书名我们也能大概猜到书中就会讲什么。

作者叫史蒂芬盖斯，是个名不见经传的普通宅男。起因是在2013年新年伊始，由于对过去的一年自我表现不太满意，作者打算在新的一年要提升锻炼的目标。于是打算花30分钟锻炼，可是刚开始一会就想要放弃了。于是作者就改变策略：”今天就做1个俯卧撑就行吧。“ 结果作者发现，非常轻松就完成了，甚至还想多做几个。如此反复几天下去，没想到反而达成的健身的目标。
于是作者发现通过微小的一步步养成习惯的策略非常有效，便把这段经历写成了一篇文章放到博客上，引起了热烈的反响。作者也从一个个的微习惯中培养出了真正的习惯， 某种程度上来说实现了对自己的逆袭。

微习惯是什么

总的来说，微习惯就是你强迫自己每天做的微不足道的积极行为。比如你想培养写作的习惯，你可以给自己设定目标，每天只写个50字；如果想培养阅读的习惯，可以给自己设定目标每天翻2页书。
微习惯策略行动，就是运用少量的意志力强迫自己做一件事情。 因为太小而不至于无法完成，因此，你不会有机会体验未完成目标导致的常见消极情绪 。

作者认为，很多时候人们无法让改变的效果持久下去时，会认为原因是在自己身上。其实，不一定是他们自己本身的问题，可能只是他们采取的策略不对而已。研究表明，人们总是会过高地高估自己的自控力。很多时候我们总陷入自己没有什么进步的自责之中，却没意识到可能是自己的策略出了问题。
而微习惯非常小，小到不可能失败。正是因为这个特性，它不会给你造成任何负担，并且具有超强的“欺骗性”，它也因此成了一种极其有效的习惯养成策略。

微习惯是如何起作用的

习惯形成的第一个信号是抵触情绪减弱。
行为要变成习惯，需要有一个过程，而变成过程之前，我们需要有两个途径来支撑我们的行为： 动力和意志力。

动力 & 意志力

动力跟意志力都可以让我们养成一个习惯，但动力和意志力不是非此即彼的，二者之间存在重要的关系。当你做事缺乏动力时，意志力的消耗量就会猛涨。意志力消耗量较高时，你会难以长期维持一个行为并将其培养成习惯。

动力并不靠谱

俗话说，一鼓作气，再而衰，三而竭。我们都经历过一种热情递减效应，比如吃第五块比萨时的愉悦感会略低于吃第四块时的，吃第四块时的又略低于吃第三块时的。再比如，可乐的第一口往往是最好喝的，越往后肥宅快乐水带来快乐效果会越减少。我们在进行重复行为时也存在同样的现象。
人们在做计划的时候经常性忽略了动力和精力水平可能会出现波动，以为在实际过程中能够一直保持当时的精神和精力状态。所以常常制定了一些实际上可能完成不了的目标。
所以，依靠动力的策略并不靠谱。不是说有动力不好，相比，如果我们想持久去改变，单靠动力并不是一个很可靠的策略。

意志力

比起动力来说，我们更应该依赖意志力，因为意志力有三个特点：

1. 意志力可靠。当然，前提是我们能强迫自己
2. 意志力可以被强化。和动力不一样，意志力可以像肌肉一样得到强化
3. 意志力策略可以通过计划执行。如果你依赖动力，严格执行时间计划是很困难的。没人知道你执行的时候是否还有动力了。

所以，我们应该更多地去依靠我们的意志力。当然了，如果动力越足，我们越会消耗更少的意志力。但是，有一个问题，意志力是会损耗的。

微习惯为什么效果

引起意志力损耗的5大主要因素是：
• 努力程度
• 感知难度
• 消极情绪
• 主观疲劳
• 血糖水平
采用微习惯的方式，对这5点的损耗都非常低。书里举了一个生动的例子，微习惯像是习惯的一只特洛伊木马，悄悄潜入我们的大脑，让我们在比较低耗能的情况下，不知不觉把习惯给养成。

如何行动

既然微习惯有效，那我们应该如何去使用微习惯呢？书中给了几个步骤让我们培养微习惯

八大步骤： 培养成你的微习惯

1. 选择一个微习惯，制定每天的计划

鉴于微习惯对意志力的消耗很小，我们可以同时制定好几个微习惯。但是微习惯数量不要超过四个，因为那样太多了。数量越多，你的精力就会越分散，就越有可能忽略或者忘记其中一个。

作者提供了三种微习惯计划：一周弹性计划、单一微计划和多项微计划，以适应不同人的需求和能力。一周弹性计划建议从一个习惯开始，一周后根据个人感受调整计划。单一微计划专注于一个重要的习惯，适合意志力较弱或情绪低落的人。多项微计划则适合那些想同时培养多个习惯的人。

对于不适合每天执行的习惯，作者建议以周为单位来培养，这可能需要更长时间，但最终会形成稳定的模式。他还提出了混合微习惯的概念，即在两个选项之间选择，比如去健身房或者在家做一些简单的锻炼。这种策略提供了灵活性，同时鼓励每天都有所行动。

2. 挖掘习惯找到内在价值

通过多思考”为什么“，找到我们目标的来源。只有知道这个目标的价值，我们才能找到坚持下去的意义所在。
作者提出使用“为什么钻头”方法，即不断追问“为什么”直到找到行动背后的核心动机。这要求诚实地回答，直到找到核心理由。其实就是5Why分析法

3. 明确习惯依据，将其纳入日程

习惯依据通常有两种：时间和行为方式。对于日程规律的人，基于时间的习惯设置可能更有效；而对于日程灵活的人，基于行为方式可能更适合。我个人比较推崇的方式是基于时间的日程方式。

4. 建立回报机制，以奖励提升成就感

人们在感到满足和获得回报时更容易做出积极的决定，同样，如果一个行为没有明显的回报，大脑可能会抵制这个行为。这就是有时候一些重复的活动会让我们觉得很枯燥的原因。所以，每当我们有一点进步的时候，不妨给自己来点儿奖励，吃顿好的或者是其他娱乐形式放松一下。

5. 记录与追踪完成的情况

虽然不推荐流于形式，但是我个人还是推荐采用打卡的方式来记录。特别是以一个日历的形式来打卡，因为那样很直观。我个人就会以一份日历来记录自己的运动计划，曾经我在公司的健身房看过一个同事随手拿着一本小册子，每次练完卧推之后写点东西，应该是在记录自己的组别和次数。
总之，记录载体并不重要，只要能够直观与方便记录我们在慢慢变好就可以。

6. 微量开始，超额完成

微习惯不会让你有失败的借口，不会让你感觉到愧疚。既然定的目标轻而易举，我们能够很轻松或者是在不知不觉中就把任务给完成了。
设定小而易于实现的目标，这样做有几个好处：

1. 强化意志力：通过频繁地完成小任务，我们可以逐渐增强意志力，就像健身房里通过多次举起较轻的重量来训练肌肉的持久性一样。
2. 立即取得进步：微习惯策略允许我们立即看到进步，这本身就是一种激励。一旦开始行动，动力就会接管，减少对意志力的依赖。
3. 避免耗尽意志力：微习惯的任务要求低到即使在意志力几乎耗尽的情况下也能完成，这样就避免了失败的借口和内疚感。

7. 服从计划安排，摆脱高期待值

从潜意识层面来看，在我们超额完成任务后，大脑的期待阈值可能会不知不觉被提高。作者不建议这样，不断提高期待值不是我们的目标，目标应该是放在能够长久坚持下去。

8. 留意习惯养成的标志

如果能够长期坚持微习惯，那么它将会在不知不觉中变成我们真正的习惯。变成真正的习惯的信号：

1. 没有抵触的情绪
2. 认同自己的拥有这个习惯的身份
3. 对该行动不再考虑以及焦虑
4. 已经将该行为常态化了
   当你的行为符合上面几点的时候，我们就成功培养了一个习惯。

总结

个人认为，这个微习惯有点另辟蹊径。我们自古有句话叫“取法乎上，仅得乎中” 。意思就是我们一开始定一个很高的目标，即使最终不能达成，也能得到一个中等的效果。而微习惯却走的是一个”取法乎下“的打法，但也可以让我们取得超预期的成果。但两者其实不违背，一种是鞭策的方式，而一种是激励的方式。

无论如何，培养一个习惯是长期坚持下来的结果，书中给了我们达成培养习惯目的另一种途径。如果你有过想培养一个习惯但是迟迟不能成功的经历，不妨试试书中提供的方式。
总而言之，微习惯，微量开始，超额完成，形成习惯，持之以恒。

参考

• Take The One Push-up Challenge
• 微习惯

什么是Server Side Includes

我们来看看维基百科是怎么解释的:

服务器端内嵌（Server Side Includes，亦简称为SSI）是一种大多数仅应用于互联网上的简单解释性服务器端脚本语言。
SSI最常见的用法是将一个或多个文件的内容包含在网页服务器的页面上。例如，一张包含每日报价的页面可以通过下面一段代码将报价单包含在页面中：

1

<!--#include virtual="../quote.txt" -->

SSI 简称代码片段，通过特殊的语法糖，服务器在响应的时候遇到相关指令，会发起另外的请求（subrequest）去请求对应的代码片段之后嵌入到父页面中，从而实现页面在服务端拼接

SSI 的运作机制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

  [Client]
     |
     | HTTP Request
     v
[NGINX Server]
     |
     |--- [SSI Parser]
     |        |
     |        |----- [Include Header.html] // SSI 片段
     |        |
     |        |----- [Include Menu.html] // SSI 片段
     |        |
     |        |----- [Include Footer.html] // SSI 片段
     |
     v
[HTML Page]
     |
     | HTTP Response
     v
  [Client]

如何使用Server Side Includes

使用nginx ssi指令即可开启服务

1
2
3

http {
	ssi on;
} 

我们以nginx为例实现一个ssi 服务, 使用nginx 代理到 nodejs(这里我们称为upstream服务), 然后在nginx上面开启ssi 服务。

链路如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

[Client]
    |
    | HTTP Request
    v
[NGINX Proxy]
    |
    | HTTP Request
    v
[Upstream Server (Node.js)]
    |
    | HTTP Response
    v
[NGINX Proxy]
    |
    | HTTP Response
    v
[Client]

nginx设置代理

nginx 设置代理并开启ssi

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

error_log logs/error.log debug;

events {
    worker_connections 10;
}

http {
    ssi on; # 这个指令表示开启ssi

    upstream to_node {
        server localhost:3000;
    }

    server {
        listen 8080;
        server_name localhost;

        # proxy all request to node server
        location / {
            proxy_pass http://to_node;
        }
    }
}

upstream 服务直接响应html内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<!-- index-static.html 内容 -->
<!DOCTYPE html>
<html>
<head>
    <title>Hello World</title>
</head>
<body>
    <!--#include virtual="./header-block.html" -->
    <h3>Hello world!</h3>
    <!--#include virtual="./footer-block.html" -->
</body>
</html>

<!-- header-block.html 内容 --> 
<header>
    <h1>footer block from ssi</h1>
</header>

<!-- footer-block.html 内容 --> 
<footer>
    <div>footer block from ssi</div>
</footer>

然后打开页面

是不是很简单？

异常的出现

那么，对于SSI的使用数量，是否有上限呢？让我们往页面里面再添加SSI

修改如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<!DOCTYPE html>
<html>
<head>
    <title>Hello World</title>
</head>
<body>
    <!--#include virtual="./header-block.html" -->
    <h3>Hello world!</h3>
    <!--#include virtual="./footer-block.html" -->
    <!--#include virtual="./footer-block.html" -->
    <!--#include virtual="./footer-block.html" -->
    <!--#include virtual="./footer-block.html" -->
    <!--#include virtual="./footer-block.html" -->
</body>
</html>

访问结果

oops 发生了什么事？

在nginx 的 error log里，我们发现问题所在

1
2
3

2024/06/24 19:41:34 [warn] 67237#15146903: 10 worker_connections are not enough, reusing connections
2024/06/24 19:41:34 [alert] 67237#15146903: *82 10 worker_connections are not enough while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET /html/index-static.html HTTP/1.1", subrequest: "/html/./footer-block.html", upstream: "http://127.0.0.1:3000/html/./footer-block.html", host: "localhost:8080"
2024/06/24 19:41:34 [alert] 67237#15146903: *82 10 worker_connections are not enough while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET /html/index-static.html HTTP/1.1", subrequest: "/html/./footer-block.html", upstream: "http://[::1]:3000/html/./footer-block.html", host: "localhost:8080"

worker_connections are not enough while connecting to upstream

小结

这里体现了ssi 的第一个特性: subrequest 同样也会消耗worker的数量
所以，ssi同样也会跟我们的父请求抢占worker资源，每个页面的SSI数量也需要严格进行限制。

对upstream的挑战

既然父请求与SSI都会占用worker数量的话，我们很容易想到，使用SSI的技术，对后端的流量会造成放大

实验

假设我们在页面里面请求m个SSI，而upstream server的最大支撑请求数为n, 且m > n, 这个时候会发生什么事？

我们按照下面的表格对服务进行改造

如上面的请求，我们在一个父文件里面设置10个ssi，而upstream服务我们设置限流3个请求，请求父文件之后看看会发生什么：

在html文件上设置多个SSI片段

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<!DOCTYPE html>
<html>
<head>
    <title>Hello World</title>
</head>
<body>
    <h1>Hello world!</h1>
    <!--#include virtual="./block.html" -->
    <!--#include virtual="./block.html" -->
    <!--#include virtual="./block.html" -->
    <!--#include virtual="./block.html" -->
    <!--#include virtual="./block.html" -->
    <!--#include virtual="./block.html" -->
    <!--#include virtual="./block.html" -->
    <!--#include virtual="./block.html" -->
    <!--#include virtual="./block.html" -->
    <!--#include virtual="./block.html" -->
</body>
</html>

对upstream server增加限流逻辑，使得SSI请求触发限流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 我们在node服务里面进行一个限流
const ratelimit = require('koa-ratelimit');
const db = new Map();
const app = new Koa();
app.use(logger())

app.use(ratelimit({
    driver: 'memory',
    db: db,
    duration: 10000,
    errorMessage: 'Oops! 你被限流了!',
    id: (ctx) => ctx.ip,
    headers: {
      remaining: 'Rate-Limit-Remaining',
      reset: 'Rate-Limit-Reset',
      total: 'Rate-Limit-Total'
    },
    max: 3,
  }));

响应结果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

HTTP/1.1 200 OK
Server: openresty/1.21.4.1
Date: Mon, 24 Jun 2024 12:07:27 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Rate-Limit-Remaining: 2
Rate-Limit-Reset: 1719230857.668981
Rate-Limit-Total: 3
Cache-Control: max-age=0

<!DOCTYPE html>
<html>
<head>
    <title>Hello World</title>
</head>
<body>
    <h1>Hello world!</h1>
    <div>ssi from block content</div>
    <div>ssi from block content</div>
    <div>ssi from block content</div>
    <div>ssi from block content</div>
    <div>ssi from block content</div>
    Oops! 你被限流了!
    Oops! 你被限流了!
    Oops! 你被限流了!
    Oops! 你被限流了!
    Oops! 你被限流了!
</body>
</html>%

小结

使用SSI 会对源站请求的数量放大，对源站产生更大的压力挑战

同一个请求, SSI subrequest是并行还是串行的

有没有发现，上述的SSI subrequest ，前面的请求都是好的，而被限流的ssi subrequest ，都是排在后面。

这里我们有个疑问：SSI的请求是串行的吗？

其实从前文worker connection限制来看，这个行为应该是倾向于并行请求。如果是串行请求的话，那么worker connection应该没有那么容易就消耗完。我们推测：

1. 先请求完父请求
2. 解析html之后，收集所有的子请求
3. 并行所有的子请求。

上面仅仅只是猜测，真实情况下，到底是并行请求，还是串行请求，还是要实验了才知道。

设计实验

对于我们的node server，我们进行如下改造，设置动态路由

1
2
3
4
5
6
7
8

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

router.get('/dynamic/sleep/:time', async (ctx) => {
    const { time } = ctx.params;
    await sleep(time);
    ctx.type = 'text/html';
    ctx.body = `Hello, world! your path is /dynamic/sleep/${time}`;
})

如果请求upstream 服务，/dynamic/sleep/1000 则会等待1s才响应，/dynamic/sleep/2000 则是2s才响应

接着设置我们的主html

1
2
3
4
5
6
7
8
9
10
11
12

<!DOCTYPE html>
<html>
<head>
    <title>Hello World</title>
</head>
<body>
    <h1>Hello world!</h1>
    <!--#include virtual="/dynamic/sleep/10000" -->
    <!--#include virtual="/dynamic/sleep/8000" -->
    <!--#include virtual="/dynamic/sleep/5000" -->
</body>
</html>

如果请求index.html文件，则会解析到3个server-side include file, 3个子请求加载时间分别为10s, 8s, 5s.

如果是串行，那么时间应超过 10 + 8 + 5 = 23s;
如果是并行，时间应该接近10s

请求页面，我们看看会发生什么
在浏览器请求的timelime上我们可以很清楚的看到，请求的时间约为10s

在node server的日志

1
2
3
4
5
6
7
8

<-- GET /html/index.html
--> GET /html/index.html 200 15ms 271b
<-- GET /dynamic/sleep/10000
<-- GET /dynamic/sleep/8000
<-- GET /dynamic/sleep/5000
--> GET /dynamic/sleep/5000 200 5,002ms 46b
--> GET /dynamic/sleep/8000 200 8,003ms 46b
--> GET /dynamic/sleep/10000 200 10s 47b

我们可以看到：

1. 服务端接受到了父请求, 并成功响应
2. 同时接受到了3个子请求，并按照响应时间先后返回

小结

所以，我们可以得出以下结论

1. subrequest 是并发请求的
2. 即使是并发请求，子请求也会按照引入的顺序从先到后进行请求。

总结

SSI在实际应用中可以帮我们解决一些页面内容共用的问题，但是

1. SSI技术会让用户得到请求的时间更长（父请求时间 + 页面解析时间 + SSI 请求时间 ）
2. SSI subrequest会占用worker connection数量，需要我们对代理服务器的worker数量进行合理评估
3. 采用SSI 技术，也会对upstream server带来成倍以上的压力挑战

总而言之, SSI是一把双刃剑，在带给我们便利的同时，也要谨慎使用！

4月

买车记

买了一辆车，其实现在感觉不怎么需要，因为出行周边的交通比较发达的。眼看摇到号半年的有效期快到了，最终决定还是买一下吧。也没怎么花时间在挑车上，最终买了丰田的亚洲龙，销售环节基本是妹夫帮忙电话谈的。当时人在老家，跟深圳的4S通了电话，问了两三家可以开到多少，如果合适的话就上深圳提车。可能这里给4S有“外地的单，赚一单是一单”的感觉，价格比在老家便宜了不少，最终直接全款拿下。

家人的身体健康

事情的起因是母亲过年的时候感冒之后就一直在咳嗽，拖了很久之后在老家拍了片子，发现双肺肺炎，于是治疗。等到好了以后去复查，CT提示有结节，并且在结论里面写可有可能的是原位Ca(Ca即是 Cancer，也就是癌症。一些医院为了不引起病人的恐慌，特地写了Ca)。
看到这情况，果断安排了广州的检查，心里想着可能是病症的早期，到时候可能要做个手术活检定性。
好在最终重新做了增强CT结果是没有什么问题，而老家那里说是照CT的机子有点旧可能不是很准（这都行）。

那几天着实有些担心，幸好最终结果是很好，把时间线捋了出来，这些年经历下来，感觉健康真的是太重要了

运动

运动打卡日： 11/30
跑步km: 50/50

读书

背景

2024-03-29晚上使用vs code, 发现我的copilot一直不起作用了。

分析

一开始想着可能我配置错了，尝试了各种方法，都不行：

1. 切换更早版本的copilot（一年前的版本）
2. 换一台笔记本
3. 用其他的IDE

copliot 的终端报错显示

1
2

[INFO] [auth] [2024-03-29T14:22:41.063Z] Invalid copilot token: missing token: 403 
[ERROR] [default] [2024-03-29T14:22:41.065Z] GitHub Copilot could not connect to server. Extension activation failed: "Contact Support. You are currently logged in as derycktse."

琢磨了一下看着像是被封了

处理

于是在官网找到客服提ticket实锤被封。
GitHub回复检测我的账号有部署服务的嫌疑，不能解禁。

因为我在公司使用了，而公司出口IP走的腾讯云。于是被github 的安全机制扫描出来给封禁了。

于是我质疑他们只看来源不看使用量的策略，毕竟我个人使用的话，这个量还是微乎其微的。

最终客服成功给我解封了

3月

整一个3月还是比较忙的，毕竟整个3月是公司的一个季度考核末期，所以本着deadline 是第一生产力的原则，大伙都在冲刺。加上3月也病了一场，所以回顾了一下，3月份并没有做太多的事情。

运动

3月中上旬一直在咳嗽，运动从过年后也歇息有一段时间了。到了中下旬咳嗽才好了，于是恢复了跑步。整体运动量：
运动打卡日： 6/31
跑步km: 30/50

读书

主要流程

出于安全的考虑，目前在微信小程序端，是无法直接拿到用户的手机号。需要几步安全校验。整体流程大概是：

1. 在微信后台生成appid & secret
2. 用户登录微信小程序授权访问手机号，获得手机号获取凭证code
3. 调取使用appid & secret，获得接口调用凭证 access_token
4. 使用接口调用凭证 access_token 与手机号获取凭证code调用微信服务获得用户手机号信息
   简单讲即：用户授权 & 调用两次微信服务

小程序端

使用微信的内置组件 <button/>，设置open-type 的值设置为 getPhoneNumber, 当用户点击并同意之后，通过 bindgetphonenumber 事件获取回调信息；
代码如：

1

<button open-type="getPhoneNumber" bindgetphonenumber="getPhoneNumber"></button>

1
2
3
4
5
6
7
8

Page({
  getPhoneNumber (e) {
    console.log(e.detail.code)  // 动态令牌
    console.log(e.detail.errMsg) // 回调信息（成功失败都会返回）
    console.log(e.detail.errno)  // 错误码（失败时返回）
  }
})

获取用户小程序服务端流程如下

sequenceDiagram
    participant user as 微信小程序客户端
    participant api as 后端服务
    participant wechat as 微信服务
    user->>api: 授权手机号获取凭证code
    rect rgb(255, 255, 200)
    api->>wechat: ask access_token
    wechat->>api: access_token
    end
    rect rgb(255, 150, 230)
    api->>wechat: access_token
手机号获取凭证code
    wechat->>api: 用户手机号信息
    end

其他

在开发微信小程序过程中，我们可能需要涉及到以下相关的凭证

参考

• 小程序登录
• 获取接口调用凭据
• 获取手机号

这一两年一直在obsidian记录东西，感觉非常不错。不过有一个问题就是，如果只是一味的记录给自己看，可能失去了和别人交流的机会。考虑到这个层面，还是决定以后得多写一些博客。记录自己在生活以及学习上的一些所得所悟，如果能有人看到我的文字有所共鸣或者收获，那将是非常有意义的事情。
考虑到博客使用hexo 生成，托管在github page 上，hexo有自己的一套文件夹命名格式，我还是比较喜欢在obsidian里面写东西。所以最简单的办法就是在obsidian里面写好文章直接同步到hexo 文件夹里面就行.

目前我的obsidian跟hexo文件夹的位置大概是这样：

每次写完之后，直接使用rsync 同步一下我的文件夹，再部署到github page 上即可

1
2

rsync -r --delete ~/my-obsidian-folder/blog/_posts/ ~/my-hexo-folder/myname.github.io/source/_posts/
hexo clean && hexo g && hexo deploy

当然还有很多更好的办法，比如使用软链等形式，不过觉得现在这个阶段已经够用了。毕竟写blog的频率当下还达不到非常高频。还是先让自己培养多写作的习惯，等习惯养成之后再进一步优化。

来自2024-08-17 补充，发现每次rsync后，未修改个文件，同样也被重新覆盖了，这里体现在文件的修改时间上，自然而然想到可以使用对比摘要不同再同步的方法，发现rsync已经有参数支持。可以基于摘要进行比对后再决定是否更新

1

-c, --checksum              skip based on checksum, not mod-time & size

修改版

1

rsync -r --checksum --delete ~/my-obsidian-folder/blog/_posts/ ~/my-hexo-folder/myname.github.io/source/_posts/

关于“双拼输入法” 其实很早就听过了，只不过之前一直没去了解它是什么。记得以前用电脑打字，有时候会不小心将输入法切换到了双拼，因为不知道双拼输入法到底是怎么运作的，所以一下子就不会打字了。

年前刷博客的时候无意看到有博主在极力推荐双拼输入法，称其大提高了打字的效率。
作为一个追求效率的人，我对能提升效率的事情都是很感兴趣的。日常的工作交流也经常需要去打字，提升一下打字效率也是一件很有收益的事情。

趁着过年期间，抽空学了一下双拼输入法，现在已经将日常输入法切到了双拼输入法了。

什么是双拼输入法

双拼是一种基于拼音的输入法。拼音的发音可以简单分由声母和韵母组成。
比如 买(m ǎi )、卖(m ài)。

所有的声母和韵母都在键盘上对应一个按键。这样一来，任意一个汉字都可以用两个按键来定位，从而提升打字的速度。

举个例子，“梦想”这个词，全拼需要敲键盘9次，而双拼只需要敲4次，这就是双拼提高打字效率的关键之处。

• 全拼输入法: mengxiang
• 双拼输入法：mgxl (基于小鹤方案)

如何上手

双拼输入法有好几种方案，主要的区别就是键位不同而已。
我选择的是小鹤双拼的方案，为什么选择这个方案。主要原因有两点：

1. 小鹤方案把音节都放在了字母键上，规避了符号按键（有一些双拼方案使用了”;” 这个按键），使得我们能记住更少的键位。
2. 小鹤双拼把使用频率较高的声韵母放在了比较易于发力的食指和中指上（我个人的小指不是很灵活）

学的过程还是比较顺利的，对着键位，我尝试着把它们记下来。这里分享一个个人小技巧：把每一个按键选一个比较熟悉的汉字作为代表来记。甚至你可以代入你熟悉的人，这样的话你会更容易记得每一个字的位置。
举例

• Q键：q + iu = 球
• W键：w + ei = 喂
• P键：p + ie = 撇
• Z键：z + ou = 走
• R键：r + uan = 软
• M键：m + ian = 棉

只需要在心里将熟悉的字与按键对应并记下来，后续如果打其他的字，只需要将我们熟悉的字单独摘出来声母与韵母组成我们需要的字即可。一般我打字都是按词来打，结合着输入法的联想，大部分情况下都能直接联想到我需要的词。

记住了按键之后，我们只需要多加练习即可，这里推荐一个在线练习网站: https://api.ihint.me/shuang/

当然了，切换输入法总会有一段时间的不应期，因为之前的输入法已经让我们形成了肌肉记忆。但是，一旦你习惯了一个字只需要按两个键就能定位到，那么双拼的好处就会显现出来，打字速度也会逐渐提高。

我们可以在日常的练习中熟能生巧，找我们的朋友聊聊天拉拉家常，写写日记，只要练习多了，形成肌肉记忆，打字速度自然就会提高。

总结

从全拼切换到双拼虽然需要一段适应时间，但总体来说并不太难，只需要记得声母和韵母的位置在哪里，剩下的就是花时间熟悉。
目前虽然打字还谈不上飞快，但基本上来说已经够用了，后续如果习惯了速度也会进一步提升上来。
有意思的是，切换输入法后，和别人聊天会有一种重新组织语言的感觉，好像讲话的风格都不是原来自己的样子。
当然了，目前的输入法基本都具备了强大的联想能力，其实使用全拼的速度对大部分人来说已经够用了。

参考

• 二〇二二年，来试试双拼输入法吧
• 让双拼不再是只属于少数人的输入方式
• 辅音、元音与声母、韵母的关系是怎样的？
• 普通话辅音、元音与声母、韵母的关系，两大系统详解

笔记

这本书的观念好像跟之前说的脑科学的书讲的不太一致。
主要是说多巴胺的作用，之前读书的认知是，多巴胺是降级机制，而且是即时奖励。但是这本书讲的说是，多巴胺是动机，而快乐的感觉是享乐热点，这个跟之前有什么区别呢？
这本书里说的是多巴胺关联的是动机，而非快乐，多巴胺越浓，动机越强

“上瘾”就是一个典型的高动机低快感的现象。当我们沉迷于某一事物时，我们可能并不感到快乐，但就是控制不住自己，原因就在于这些奖励刺激的是我们的奖赏回路，而不是享乐热点。我们内心深处知道它们并不重要，只是在浪费时间，但就是控制不了大脑的天性。

• 杏仁体
  • 愤怒、焦虑、恐惧这三种情绪都跟杏仁核有密切的关系
  • 那些行动力比较弱，遇事习惯瞻前顾后、犹豫不决的人，杏仁核的体积往往较大，活动也较为活跃。
• 前额叶皮层
  • 主要负责决策、计划、抽象思考、推理和策略等高级功能。
  • 抑制
• 在“杏仁核-前额叶”通路中，前额叶与杏仁核是互相抑制、动态平衡的关系。

如果你总是把一件事情丢给别人决定，或是总是拖延，直到没有余地时才做决定，那么它就会潜移默化地强化“我无法做出决策”的信念，降低你的自我效能感，以及面对威胁时的抵抗力。但反过来，如果你能够做到靠自己的力量果断地做出决策，哪怕结果并不是最好的，也能在潜意识中强化你的内隐自我，让你感受到：我是有能力做出决策的，我是有能力决定和改变外在世界的。那么，当你再次遇到困难和挑战时，当你的内心再一次进入“我究竟能不能做好”的负面情绪时，这些正面信息和内隐自我，就会成为你对抗这种心态的“弹药支撑”，为你源源不断地提供动力。

我发现我就有这样个毛病，特别是对于重大的决策，我自己不会做决策，总是会把问题抛给别人。

我们做的很多事情，很多计划，都只是定量而不是定性，比如读书运动健身，重要的不是打卡我运动了多少或者是我读了多少本书，而更多应该是按结果我养成了一个什么样的生活习惯或者说是习得了什么知识，如果都只是落实动作，那其实也没什么作用。这些都是充分不必要的条件

基于“自驱“的”自律“才能持久，过去我们总是觉得自己意志力不足，需要靠意志力让自己变得自律，约束自己，其实是很低效的，更高的是我们要能让自己进入一个健康的循环之中。这让我想起我一直听的一个节目齐俊杰懂财经的作者，说他每天都五六点钟起来，一天写接近一万字，但是自己都不觉得累，如果是单纯靠意志力，肯定是完不成，真正要靠自己愿意，自己喜欢，能驱动自己，才能达成正循环。

文摘

《打开心智》
李睿秋
30个笔记

◆ 第一章 大脑的底层原理：心智模式四大支柱

大脑有一个内在的、固定的倾向，那就是对绝大多数事物，都希望采取走捷径的方式快速理解和处理它。因为这样是最省力、最节能的做法。

而焦虑的本质其实就是对于不确定性的恐惧。一件事情，如果我们明确知道它会顺利，我们不会焦虑；如果我们明确知道它不会顺利，我们也不会焦虑（取而代之的可能是恐惧或沮丧）。

1.预设立场：我们的行为和认知往往会为我们预设下一个个立场，让我们带着立场去获取信息；
2.证实偏见：在预设立场的基础上，我们会更容易接受跟立场一致的信息，忽略不一致的信息，从而强化我们的立场；
3.合理化：一旦我们接触到不一致的信息，我们也会倾向于把它往一致的方向解释，尽可能强化我们的立场。

要想养成良好的习惯，改掉自己的坏毛病，绝不能指望在短时间内一蹴而就，因为那相当于在跟大脑的适应性做斗争，注定是徒劳无功的。你要做的是通过缓慢的、日复一日地微调，去改变自己的基线，让大脑一步步适应新的模式，用它去代替旧的常态。

因此在生活管理中，我设置了一个“15%可能性”的项目，也就是抽出大约15%的时间去尝试和探索自己没有做过的事情，为生活引进一些新鲜感。

“上瘾”就是一个典型的高动机低快感的现象。当我们沉迷于某一事物时，我们可能并不感到快乐，但就是控制不住自己，原因就在于这些奖励刺激的是我们的奖赏回路，而不是享乐热点。我们内心深处知道它们并不重要，只是在浪费时间，但就是控制不了大脑的天性。

一旦我们习惯了这种“不劳而获”的多巴胺获取模式，就更加难以适应需要付出努力才能获取多巴胺的模式了。因为相比之下，后者能够为我们提供的奖励变得更少，能够激发的多巴胺浓度也相对来说变低了。一边是你什么都不用做就可以获得稳定的多巴胺，另一边是你必须先付出努力，经过一定的时间，才能获得的并不确定的多巴胺，大脑自然会更倾向于选择前者。

在这一章中，我们讨论了大脑的四种基本原理。
第一种：节能。它是大脑运作的最基本原理。大脑总会倾向于走捷径、抄近道，用最简单的方式去行动，以节省更多的能量和资源，确保我们能更好地趋利避害。
第二种：稳定。它是大脑的定位系统。大脑总会倾向于维持现状，希望一切是确定的、已知的、可控的，这样才能获得安全感，维护现有的心智秩序。
第三种：预测。它是大脑的导航系统。大脑每时每刻都在完善自己，我们的一切信息输入和行动输出，都是对它的一种训练，把它往对应的方向一步步推动。
第四种：反馈。它是大脑的动力系统。大脑以完成任务、获得奖励的方式来强化我们的行动，为我们提供动力，让我们知道什么事情是可以做、应当做的。
这四条基本原理，彼此组合，可以演绎出非常复杂的规则。生活中的种种现象，大脑的种种规律，都可以归结到这四点。
同样，许多自我提升、自我完善的思维和方法论，也必须基于这几条原理，才能更好地落实，取得成效

◆ 第二章 掌控情绪：如何与情绪做朋友

尽管杏仁核的名字很普通，但它在大脑中却有着举足轻重的作用，它是我们的“情绪中心”，是许多情绪相关通路的核心。

综上所述，愤怒、焦虑、恐惧这三种情绪都跟杏仁核有密切的关系。它们的本质，就是杏仁核出于“威胁识别”功能，对我们的一种警告和提醒。

实际上，许多研究发现：那些行动力比较弱，遇事习惯瞻前顾后、犹豫不决的人，杏仁核的体积往往较大，活动也较为活跃。这就导致他们遇到问题时，总会下意识地夸大风险和后果，自己把自己吓倒，以致寸步难进。

前额叶皮质是大脑皮质中至关重要的一部分，顾名思义，它位于额叶的最前部，大致在额头的位置，主要负责决策、计划、抽象思考、推理和策略等高级功能。在这些功能中，有一个非常基础、重要的功能：抑制。前额叶皮质相当于整个大脑的调度中心，它能够抑制我们各种各样的念头、冲动和行为，让我们冷静下来，为理性思考留出空间，避免被自己的冲动和天性所支配。

我们为这些事情耗费的精力，耽误的时间，造成的内耗，很可能都是白费功夫。你真正要做的是让自己保持良好的状态，不断地强化心态，以便于当那3%的问题真正发生时，能够更好地去处理，而不是把注意力停留在那毫无意义的97%上。

如果你总是把一件事情丢给别人决定，或是总是拖延，直到没有余地时才做决定，那么它就会潜移默化地强化“我无法做出决策”的信念，降低你的自我效能感，以及面对威胁时的抵抗力。但反过来，如果你能够做到靠自己的力量果断地做出决策，哪怕结果并不是最好的，也能在潜意识中强化你的内隐自我，让你感受到：我是有能力做出决策的，我是有能力决定和改变外在世界的。那么，当你再次遇到困难和挑战时，当你的内心再一次进入“我究竟能不能做好”的负面情绪时，这些正面信息和内隐自我，就会成为你对抗这种心态的“弹药支撑”，为你源源不断地提供动力。

◆ 第三章 自我驱动：如何长期坚持做一件事

很多人之所以能够自律，并不是他们喜欢苦行、喜欢逼迫自己，而是因为他们从中获得了乐趣。这种乐趣，可能是解决一个问题的快感，可能是成功证明了自己的成就感，可能是朝目标又近一步的愉悦感……总而言之，他们认同自己所做的事情，并能从中感受到价值。

重要的不是你刻意去做什么，而是一点一滴改变整个生活模式，整体地、系统地，让自己进入一个更好的状态。

这种“给自己设定一个数值，再努力去达到这个数值”的思维，只是看起来很美好，但实际上用处不大。因为你的生活不是计数器，我们要做的，是对自己的生活负责，而不是简单粗暴地去规范它。

许多人认为，自律就是要用意志力去约束自己，坚持良好的习惯。如果做不到，就需要锻炼意志力，让它变得更加坚毅。只有这样，才能实现自己的目标。
但这一做法其实是低效的。基于意志力的两大假说“延迟满足”和“自我损耗理论”，已经被证明是无效的。并没有一种“意志力”在控制着我们。只要我们认为意志力是无限的，它就可以是无限的。

基于“自驱”，让改变发生，这才是有效的、真正的“自律”。

◆ 第四章 果断行动：如何摆脱懒惰、拖延和畏难

日常生活中，一个人DMN的时间越长，整体的幸福感往往也就越低。

如果你的自信和自尊水准不够高，还可能导致一个更严重的结果：抑郁性反刍。它指的是思维不由自主地聚焦在负面想法上，无法自主地把注意力转移开，既难以去思考“有没有别的可能性”，也无法去想“我可以做些什么，来改变这种现状”，而是一遍又一遍地反刍那些不愉快的经历和念头，导致自我怀疑和自我否定。

DMN本来就是一个“默认”的状态，它才是大脑的常态。我们能做的，是让自己去接纳这些负面想法，但要把主导权抓在自己手里，而不是任由它们主导我们的思维。

行动力=（期望×价值）/（分心×延迟）。

行动力越高，一个人就越不容易拖延。

可以看出，在什么情况下，我们才会充满行动力去做一件事情呢？要么，这件事情非常简单，立刻就能做完（延迟小）；要么，这件事情的价值非常高，高到可以克服分心和延迟。换句话说，也就是低投入、高回报的事情。

许多人之所以不敢去尝试新事物，就是因为害怕失败，害怕“能力不足”这件事被别人发现，但成长思维告诉我们：不用怕。人的能力永远不是静态的，而是不断变化的。你在一件事上的失败只能说明一件事，那就是你将要变得更厉害了。

从短期来看，人们更容易为“做错”的事情感到后悔，并会想办法去补救、纠正；但一旦把时间拉长，不论程度上还是数量上，“没做”的后悔程度，都会远远超过“做错”。“做错”的后悔可能持续几周、几个月，但“没做”的后悔，可能持续许多年，乃至于成为记忆里一个永久的遗憾

◆ 第五章 高效学习：如何打造终身受用的学习系统

我们学习的效果和省力的程度基本是成反比的。

也就是先通过积累形成若干个主题，再从这些主题出发，想清楚自己缺少什么，需要去弥补什么，然后有意识地去获取知识来填充这些主题，完善这些主题。简言之：先建立框架，再填充框架。

◆ 第六章 深度思考：如何成为更聪明的人

很多时候，决策的本质并不在于选择，而是舍弃。懂得舍弃什么，愿意舍弃什么，是一种勇气，也是一种尤为可贵的能力。

笔记

提到些交友择人之道，还是不错的，可学习。提到一个交友要看人家如何对待自己的老婆，因为老婆是他最亲的没有血缘关系的人，如何对待老婆某种程度上来说能够决定对待朋友的上限。这个观点还是蛮有意思的。

文摘

绝大多数执行力差的人，特点是一模一样的:但凡 觉得自己做的事情不 值得显摆，或者有可能被别人鄙视，就 马上不 做了— 进步对他们来说根本 不重要，维持所谓“形象” (面子)才是他 们真正的刚需……而一旦遇到可 以用来显摆自己的东西，他们就会一生只关注 那一个东西——非常“专注”。 于是，进 步对他们 来说 天然就是不可能 的。

若你不再需要通过出售 自己的时间 去满足 自己的生活所 需， 那你 就 已 经 实 现财 富 自 由

听 大 多 数 人 的话，参考少数人的意见，最终 自己作决定

表 现 型 人 格 的 物种 最在 意 自 己 当 下 的 表 现 。
进 取 型 人 格 的 物 种 最 在 意 自 己 未 来 的 表 现

我 很 早 就 想 明 白 了 这 个 道 理 。 于 是 ， 我 提 炼出 一 个 策 略 :
无 论 做 什么 事 情 ， 在 开 始 之 前 ， 都 要 想 尽 办 法 为 这 件 事 情 赋 予 极 其 重 大 的 意 义 ， 甚 至 多 重 重 大 的 意 义。 ( 为什 么 我 能 想出 这样 的 策 略? 原 因 你早就知道了 吧!)