选择那个版本的系统？ 不要过高的估算树莓派的性能，最好不要选择那些具有漂亮界面的ubuntu或者manjaro, 因为当你使用这些带桌面的系统时，很大概率界面能让你卡的想把树莓派砸了。 所以优先选择不带图形界面的lite版本的系统，如果确实需要的话，可以再安装lxde 网线插了，还是无法联网 插了网线，网口上的绿灯也是在闪烁，但是eth0就是无法联网成功。真是气人。 解决方案： 编辑 /etc/network/interfaces, 将里面的内容改写成下面的，然后重启树莓派。 这个配置文件的涵义是：在启动时就使用eth0有线网卡，并且使用dhcp给这个网卡自动配置IP auto eth0 iface eth0 inet dhcp iface etho inet6 dhcp source-directory /etc/network/interfaces.d 无桌面版本，如何手工安装桌面 首先安装lxde sudo apt update sudo apt install lxde -y 然后通过raspi-config, 配置默认从桌面启动 sudo rasip-config 选择系统配置, 按回车键进入 选择Boot/Auto login， 按回车进入 选择Desktop, 回车确认。保存之后，退出重启。 键盘无法输入| | 在linux中是管道的意思，然而我的键盘却无法输入。最终发现是键盘布局的原因。 在图标上右键，选择配置 注意这里是US, 这是正常的。如果是UK，就是英式布局，是有问题的，需要把UK的删除，重新增加一个US的。 如何安装最新版本的neovim? 树莓派使用apt安装的neovim， 版本太老了。很多插件使用上都会体验不好。所以建议安装最新版的neovim。 ...

关于js sdk的设计，这篇文档基本上详细介绍了很多的点，值得深入阅读一遍。https://github.com/hueitan/javascript-sdk-design 然而最近在重构某个js sdk时，也发现了一些问题，这个问题并不存在于上述文章中的。 js sdk在收到服务端的响应时，直接将server端返回的错误码给到用户。 这里会有一个问题，这个响应码，实际上是js sdk和server之间的消息交流。并不是js sdk和用户之间的消息交流。 如果我们将server端的响应直接返回给用户，则js sdk可以理解为是一个透明代理。用户将会和server端产生强耦合。如果server端有不兼容的变化，将会直接影响到用户的使用。 所以较好的做法是js sdk将这个错误封装为另一个种表现形式，和server端分离出来。

程序可能大部分时间都是按照正常的逻辑运行，然而也有少数的概率，程序发生异常。 优秀程序，不仅仅要考虑正常运行，还需要考虑两点： 如何处理异常 如何在发生异常后，快速定位原因 正常的处理如果称为收益的话，异常的处理就是要能够及时止损。 能稳定运行364天的程序，很可能因为一天的问题，就被客户抛弃。因为这一天的损失，就可能会超过之前收益的总和。 异常应当如何处理 如果事情有变坏的可能，不管这种可能性有多小，它总会发生。《莫非定律》 对于程序来说，避免变坏的方法只有一个，就是不要运行程序（纯粹废话😂）。 1. 及时崩溃 var conn = nil var maxConnectTimes = 3 var reconnectDelay = 3 * 1000 var currentReconnectTimes = 0 var timeId = 0 func InitDb () { conn = connect("数据库") conn.on("connected", ()=>{ // 将当前重连次数重制为0 currentReconnectTimes = 0 }) conn.on("error", ReconnectDb) } func ReconnectDb () { conn.Close() // 如果重连次数大于最大重连次数，将不在重连 if currentReconnecTimes > maxConnectTimes { return } // 如果已经催在重连的任务，则先关闭 if timeId != 0 { cleanTimeout(timeId) } // 当前重连次数增加 currentReconnectTimes++ // 开始延迟重连 timeId = setTimeout(InitDb, reconnectDelay) } 2. 如何快速定位问题 第一，代码的敬畏之心 第二，及时告警。日志，或者http请求 第三，编程时，就要考虑异常。例如程序依赖 MQ或者Mysql，当与之交互的链接断开后，应该怎样处理？ 第四，多实例问题考虑 第五，检查清单 ...

一般来说，监控pod状态重启和告警，可以使用普罗米修斯或者kubewatch。 但是如果你只想将某个pod重启了，往某个日志文件中写一条记录，那么下面的方式将是非常简单的。 实现的思路是使用kubectl 获取所有pod的状态信息，统计发生过重启的pod, 然后和之前的重启次数做对比，如果比之前记录的次数大，那么肯定是发生过重启了。 #!/bin/bash now=$(date "+%Y-%m-%d %H:%M:%S") log_file="/var/log/pod.restart.log" ns="some-namespace" echo $now start pod restart monitor >> $log_file # touch一下之前的记录文件，防止文件不存在 touch restart.old.log # 生成本次的统计数据 kubectl get pod -n $ns -o wide | awk '$4 > 0{print $1,$4}' | grep -v NAME > restart.now.log # 按行读取本次统计数据 # 数据格式为：podname 重启次数 while read line do # pod name name=$(echo $line | awk '{print $1}') # 重启次数 count=$(echo $line | awk '{print $2}') # 检查本次重启的pod名称是否在之前的记录中存在 if grep $name restart.old.log; then # 如果存在，则取出之前记录的重启次数 t=$(grep $name restart.old.log | awk '{print $2}') # 和本次记录的重启次数比较，如果本次的重启次数较大 # 则说明pod一定重启过 if [ $count -gt $t]; then echo $now ERROR pod_restart $name >> $log_file fi else # 如果重启的pod不存在之前的记录中，也说明pod重启过 echo $now ERROR pod_restart $name >> $log_file fi done < restart.now.log # 删除老的记录文件 rm -f restart.old.log # 将新的记录文件重命名为老的记录文件 mv restart.now.log restart.old.log 然后可以将上面的脚本做成定时任务，每分钟执行一次。那么就可以将pod重启的信息写入文件。 ...

本来我的目的是使用cluster模块的fork出多个进程，让各个进程都能处理udp消息的。但是最终测试发现，实际上仅有一个进程处理了绝大数消息，其他的进程，要么不处理消息，要么处理的非常少的消息。 然而使用cluster来开启http服务的多进程，却能够达到多进程的负载。 server端demo代码： const cluster = require('cluster') const numCPUs = require('os').cpus().length const { logger } = require('./logger') const dgram = require('dgram') // const { createHTTPServer, createUDPServer } = require('./app') const port = 8088 if (cluster.isMaster) { for (let i = 0; i < numCPUs; i++) { cluster.fork() } cluster.on('exit', (worker, code, signal) => { logger.info(`工作进程 ${worker.process.pid} 已退出`) }) } else { const server = dgram.createSocket({ type: 'udp4', reuseAddr: true }) server.on('error', (err) => { logger.info(`udp server error:\n${err.stack}`) server.close() }) server.on('message', (msg, rinfo) => { logger.info(`${process.pid} udp server got: ${msg} from ${rinfo.address}:${rinfo.port}`) }) server.on('listening', () => { const address = server.address() logger.info(`udp server listening ${address.address}:${address.port}`) }) server.bind(port) } 日志库如下： ...

对nginx的最低版本要求是？ 1.9.13 The ngx_stream_proxy_module module (1.9.0) allows proxying data streams over TCP, UDP (1.9.13), and UNIX-domain sockets. 简单的配置是什么样？ 例如监听本地53的udp端口，然后转发到192.168.136.130和192.168.136.131的53端口 注意事项 stream是顶层的配置，不能包含在http模块里面 proxy_responses很重要，如果你的udp服务只接受udp消息，并不发送udp消息，那么务必将proxy_responses的值设置为0 stream { upstream dns_upstreams { server 192.168.136.130:53; server 192.168.136.131:53; } server { listen 53 udp; proxy_pass dns_upstreams; proxy_timeout 1s; proxy_responses 0; error_log logs/dns.log; } } | Syntax: | proxy_responses number; Default: — Context: stream, server | This directive appeared in version 1.9.13. Sets the number of datagrams expected from the proxied server in response to a client datagram if the UDP protocol is used. The number serves as a hint for session termination. By default, the number of datagrams is not limited. If zero value is specified, no response is expected. However, if a response is received and the session is still not finished, the response will be handled. ...

6月书单回顾 《鳗鱼的旅行》刚读到92% 《Googler软件测试之道》100% 《软件测试之道微软技术专家经验总结》24% 《沉默的病人》100% 《一个人的朝圣》9% 《读懂发票》100% 《108个训练让你成为手机摄影达人》100% 《经济学通识课》5% 《楚留香新传》100% 7月书单 《鳗鱼的旅行》 《软件测试之道微软技术专家经验总结》 [KU]《一个人的朝圣》 [KU]《经济学通识课》 new 水浒传 [KU] new 围城 [KU] new 黄金时代 new 长安十二时辰 [KU] new 幻夜 new 软件开发本质论 [KU] new 苏东坡传 [KU] new 诡计博物馆 [KU] new 大师的盛宴 二十世纪最佳科幻小说 [KU] new 活出生命的意义

Google软件测试之道（异步图书）James Whittaker; Jason Arbon; Jeff Carollo 序标注(黄色) - 位置 361从根本上说，如果测试人员想加入这个俱乐部，就必须具备良好的计算机科学基础和编程能力。变革标注(黄色) - 位置 367招聘具备开发能力的测试人员很难，找到懂测试的开发人员就更难，标注(黄色) - 位置 368但是维持现状更要命，我只能往前走。标注(黄色) - 位置 388我们寻找的人要兼具开发人员的技能和测试人员的思维，他们必须会编程，能实现工具、平台和测试自动化。第1章 Google软件测试介绍标注(黄色) - 1.1 质量不等于测试 > 位置 573Google能用如此少的专职测试人员的原因，就是开发对质量的负责。标注(黄色) - 1.1 质量不等于测试 > 位置 574如果某个产品出了问题，第一个跳出来的肯定是导致这个问题发生的开发人员，而不是遗漏这个 bug的测试人员。标注(黄色) - 1.2.1 软件开发工程师（SWE） > 位置 593软件开发工程师（标注(黄色) - 1.2.2 软件测试开发工程师（SET） > 位置 600软件测试开发工程师（标注(黄色) - 1.2.3 测试工程师（TE） > 位置 612TE把用户放在第一位来思考。 TE组织整体质量实践，分析解释测试运行结果，第2章 软件测试开发工程师书签 - 位置 784标注(黄色) - 位置 787Google的 SWE是功能开发人员； Google的 SET是测试开发人员； Google的 TE是用户开发人员。标注(黄色) - 2.1.1 开发和测试流程 > 位置 864测试驱动开发”标注(黄色) - 2.1.3 项目的早期阶段 > 位置 908一个产品如果在概念上还没有完全确定成型时就去关心质量，这就是优先级混乱的表现。标注(黄色) - 2.1.14 测试运行要求 > 位置 1398每个测试和其他测试之间都是独立的，使它们就能够以任意顺序来执行。标注(黄色) - 2.1.14 测试运行要求 > 位置 1399测试不做任何数据持久化方面的工作。标注(黄色) - 2.1.14 测试运行要求 > 位置 1400在这些测试用例离开测试环境的时候，要保证测试环境的状态与测试用例开始执行之前的状态是一样的。标注(黄色) - 2.1.14 测试运行要求 > 位置 1404总之，“任意顺序”意味着可以并发执行用例。标注(黄色) - 2.3 SET的招聘 > 位置 1650在一些棘手的编码问题或功能的正确性上浪费时间，不如考核他们是如何看待编码和质量的。标注(黄色) - 2.3 SET的招聘 > 位置 1727测试不应是被要求了才去做的事情。标注(黄色) - 2.3 SET的招聘 > 位置 1728程序的稳定性和韧性比功能正确要重要的多。标注(黄色) - 2.4 与工具开发工程师Ted Mao的访谈 > 位置 1796要允许他们使用你无法预料的方式来使用你的工具。标注(黄色) - 2.5 与Web Driver的创建者Simon Stewart的对话 > 位置 1845我使用了一个被称为 DDD（译注： defect-driven development）的流程，缺陷驱动开发。标注(黄色) - 2.5 与Web Driver的创建者Simon Stewart的对话 > 位置 1859Chrome在使用 PyAuto，第3章 测试工程师标注(黄色) - 3.1 一种面向用户的测试角色 > 位置 1879我们说 TE是一种“用户开发者（ user-developer）”，这不是一个容易理解的概念。标注(黄色) - 3.1 一种面向用户的测试角色 > 位置 1880对于编码的敬意是公司文化中相当重要的一点。标注(黄色) - 3.2 测试工程师的工作 > 位置 1903在研发的早期阶段，功能还在不断变化，最终功能列表和范畴还没有确定， TE通常没有太多的工作可做。标注(黄色) - 3.2 测试工程师的工作 > 位置 1904给一个项目配备多少测试人员，取决于项目风险和投资回报率。标注(黄色) - 3.2 测试工程师的工作 > 位置 1906我们需要在正确的时间，投入正确数量的 TE，并带来足够的价值。标注(黄色) - 3.2 测试工程师的工作 > 位置 1908当前软件的薄弱点在哪里？标注(黄色) - 3.2 测试工程师的工作 > 位置 1909有没有安全、隐私、性能、可靠性、可用性、标注(黄色) - 3.2 测试工程师的工作 > 位置 1910主要用户场景是否功能正常？标注(黄色) - 3.2 测试工程师的工作 > 位置 1911当发生问题的时候，是否容易诊断问题所在？标注(黄色) - 3.2 测试工程师的工作 > 位置 1914TE的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、标注(黄色) - 3.2 测试工程师的工作 > 位置 1921TE擅长发现需求中的模糊之处，标注(黄色) - 3.2 测试工程师的工作 > 位置 1924TE通常是团队里最出名的人，因为他们需要与各种角色标注(黄色) - 3.2 测试工程师的工作 > 位置 1938下面是我们关于 TE职责的一般性描述。测试计划和风险分析。评审需求、设计、代码和测试。探索式测试。用户场景。编写测试用例。标注(黄色) - 3.2.1 测试计划 > 位置 1949如果软件深受人们喜爱，大家就会认为测试所作所为是理所应当的；如果软件很糟糕，人们可能就会质疑测试工作。笔记 - 3.2.1 测试计划 > 位置 1950测试背锅标注(黄色) - 3.2.1 测试计划 > 位置 1990读者可以用“ Google Test Analytics”关键词搜索到这个工具。标注(黄色) - 3.2.1 测试计划 > 位置 1991避免散漫的文字，推荐使用简明的列表。标注(黄色) - 3.2.1 测试计划 > 位置 1993不必推销。标注(黄色) - 3.2.1 测试计划 > 位置 1995简洁。标注(黄色) - 3.2.1 测试计划 > 位置 1996不要把不重要的、无法执行的东西放进测试标注(黄色) - 3.2.1 测试计划 > 位置 1998渐进式的描述（ Make it flow）。标注(黄色) - 3.2.1 测试计划 > 位置 2001最终结果应该是测试用例。标注(黄色) - 3.2.1 测试计划 > 位置 20091. A代表特质（ Attribute）标注(黄色) - 3.2.1 测试计划 > 位置 2010在开始测试计划或做 ACC分析的时候，必须先确定该产品对用户、对业务的意义。我们为什么要开发这个东西呢？它能带来什么核心价值？它又靠什么来吸引用户？记住，标注(黄色) - 3.2.1 测试计划 > 位置 20462. C代表组件（ component）组件是系统的名词，在特质被识别之后确定。标注(黄色) - 3.2.1 测试计划 > 位置 2049组件是构成待建系统的模块，标注(黄色) - 3.2.1 测试计划 > 位置 20633. C代表能力（ capability）能力是系统的动词，代表着系统在用户指令之下完成的动作。标注(黄色) - 3.2.1 测试计划 > 位置 2095能力最重要的一个特点是它的可测试性。标注(黄色) - 3.2.1 测试计划 > 位置 2098能力最重要的一个特点是它的可测试性。标注(黄色) - 3.2.1 测试计划 > 位置 2100一个能力可以描述任意数量的用例。标注(黄色) - 3.2.1 测试计划 > 位置 2130用一系列能力来描述用户故事，标注(黄色) - 3.2.1 测试计划 > 位置 2142确定 Google +的特质、组件和能力。标注(黄色) - 3.2.2 风险 > 位置 2193风险无处不在——标注(黄色) - 3.2.2 风险 > 位置 2202确定风险的过程称为风险分析。标注(黄色) - 3.2.2 风险 > 位置 22021.风险分析标注(黄色) - 3.2.2 风险 > 位置 2204这些事件发生的可能性有多大？一旦发生，对公司产生多大影响？一旦发生，对客户产生多大影响？产品具备什么缓解措施？标注(黄色) - 3.2.2 风险 > 位置 2206这些缓解措施有多大可能会失败？处理这些失败的成本有哪些？恢复过程有多困难？事件是一次性问题，还是会再次发生？影响标注(黄色) - 3.2.2 风险 > 位置 2209在 Google，我们确定了两个要素：失败频率（ frequency of failure）和影响（ impact）。标注(黄色) - 3.2.2 风险 > 位置 2214风险发生频率有 4个预定义值。罕见（标注(黄色) - 3.2.2 风险 > 位置 2217少见（ seldom）：标注(黄色) - 3.2.2 风险 > 位置 2221偶尔（ occasionally）：标注(黄色) - 3.2.2 风险 > 位置 2225常见（ often）：标注(黄色) - 3.2.2 风险 > 位置 2229测试人员确定每个能力的故障发生频率。标注(黄色) - 3.2.2 风险 > 位置 2230估计风险影响的方法大致相同，也是从几种偶数取值中选标注(黄色) - 3.2.2 风险 > 位置 2231最小（ minimal）：用户甚至不会注意到的问题。标注(黄色) - 3.2.2 风险 > 位置 2234一些（ some）：可能会打扰到用户的问题。一旦发生，重试或恢复标注(黄色) - 3.2.2 风险 > 位置 2237较大（ considerable）：故障导致标注(黄色) - 3.2.2 风险 > 位置 2240最大（ maximal）：发生的故障会永久性的损害产品的声誉，并导致用户不再使用它。标注(黄色) - 3.2.2 风险 > 位置 2267风险不大可能彻底消除。驾驶有风险，但我们仍然会开车出行；旅游有风险，但我们并没有停止旅游。标注(黄色) - 3.2.2 风险 > 位置 2285在软件开发中，任何一种可以在 10分钟之内完成的事情都是微不足道的，或是本来就不值得做的。标注(黄色) - 3.2.2 风险 > 位置 2323风险分析是一个独立的领域，在许多其他行业里被严肃地对待。我们现在采用的是一个轻量级的版本，标注(黄色) - 3.2.2 风险 > 位置 2325风险管理方法），这可以作为进一步学习这一重要课题的起点。标注(黄色) - 3.2.2 风险 > 位置 2328TE有责任理解所有的风险点，并使用他或她可以利用的任何手段予以缓解。标注(黄色) - 3.2.5 TE的招聘 > 位置 2668他们只是在试图破坏软件，还是同时在验证它能正常工作？标注(黄色) - 3.2.5 TE的招聘 > 位置 2717我们需要的是愿意持续学习和成长的人。我们也需要那些带来新鲜思想和经验的人，标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特（Lindsay Webster）的访谈 > 位置 3301对于一个新项目，我首先要站在用户的角度了解这个产品。有可能的话，我会作为一个用户，以自己的账户和个人数据去使用产品。我努力使自己经历完整的用户体验。一旦有自己的真实数据在里面，你对一个产品的期待会彻底改变。在具备了用户心态之后，我会做下面的一些事情。标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特（Lindsay Webster）的访谈 > 位置 3362遗漏到客户的 bug是一项重要指标，我希望这个数字接近 0。标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特（Lindsay Webster）的访谈 > 位置 3377或者用户场景无需编写、自动到位。 CRUD操作（译注： create、 read、 update、 delete）标注(黄色) - 3.3 与Google Docs测试工程师林赛·韦伯斯特（Lindsay Webster）的访谈 > 位置 3385团队在推出一个产品或新功能时难免感到提心吊胆，而我能带给他们镇定和信心，这使我感到自己是一种正面、有益的力量。标注(黄色) - 3.4 与YouTube测试工程师安普·周（Apple Chow）的访谈 > 位置 3416而 Google的 SET必须写代码，这是他们的工作。这里也很难找到不会写代码的 TE。标注(黄色) - 3.4 与YouTube测试工程师安普·周（Apple Chow）的访谈 > 位置 3426Google的测试与其他公司的相同之处呢？ Apple：在测试上难以自动化的软件，很难成为好的软件。标注(黄色) - 3.4 与YouTube测试工程师安普·周（Apple Chow）的访谈 > 位置 3493不管是测试框架还是测试用例都以简单为要，随着项目的开展再迭代的设计。不要试图事先解决所有问题。要敢于扔掉过时的东西。第4章 测试工程经理标注(黄色) - 4.8 搜索和地理信息测试总监Shelton Mar的访谈 > 位置 3989把测试推向上游，让整个团队（开发 +测试）为交付的质量负责。标注(黄色) - 4.8 搜索和地理信息测试总监Shelton Mar的访谈 > 位置 4025从那以后，我们把配置变更也纳入质量流程中，我们开发了一套自动化测试，每次数据和配置变更时都要执行。标注(黄色) - 4.11 工程经理Brad Green访谈 > 位置 4219Google聘用的都是有极端自我驱动力的家伙。“标注(黄色) - 4.12 James Whittaker访谈 > 位置 4339先虚心学习，再在一线作出成绩，然后开始寻求创新的方法。第5章 Google软件测试改进标注(黄色) - 位置 4398Google的测试流程可以非常简练地概括为：标注(黄色) - 位置 4398让每个工程师都注重质量。标注(黄色) - 位置 4398只要大家诚实认真地这么做，质量就会提高。代码质量从一开始就能更好，标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4408可是测试并不能保证质量。质量是内建的，而不是外加的。因此，保证质量是开发者的任务，标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4409测试成了开发的拐杖。我们越不让开发考虑测试的问题，把测试变得越简单，开发就越来越不会去做测试。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4415保证质量不但是别人的问题，它甚至还属于另一个部门。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4416出问题的时候也很容易就把责任推卸给修前草坪的外包公司。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4426第三个致命的缺陷，是测试人员往往崇拜测试产物（ test artifact）胜过软件本身。标注(黄色) - 5.1 Google流程中的致命缺陷 > 位置 4430所有测试产物的价值，在于它们对代码的影响，进而通过产品来体现。标注(黄色) - 5.2 SET的未来 > 位置 4447简单来说，我们认为 SET没有未来。 SET就是开发。就这么简单。标注(黄色) - 5.2 SET的未来 > 位置 4450SET直接负责很多功能特性，如可测试性、可靠性、可调试性， ...

沉默的病人（世界狂销300万册的烧脑神作！多少看似完美的夫妻，都在等待杀死对方的契机）亚历克斯·麦克利兹 第二部分 PAPT TWO标注(黄色) - 9 > 位置 1294选择自己所爱的人就像选择心理治疗师，”鲁思说，“我们有必要问自己，这个人会不会对我忠诚，能不能听得进批评，标注(黄色) - 9 > 位置 1295承认所犯的错误，而且做不到的事情决不承诺？”第三部分 PAPT THREE标注(黄色) - 位置 2577虽然我生来不是个好人，有时我却偶然要做个好人。——威廉·莎士比亚《冬天的故事》[

引言标注(黄色) - 位置 225人并不是住在客观的世界，而是住在自己营造的主观世界里。第一夜 我们的不幸是谁的错？标注(黄色) - 不为人知的心理学“第三巨头” > 位置 335但在世界上，阿德勒是与弗洛伊德、荣格并列的三大巨头之一。标注(黄色) - 再怎么“找原因”，也没法改变一个人 > 位置 377如果所有人的“现在”都由“过去”所决定，那岂不是很奇怪吗？标注(黄色) - 再怎么“找原因”，也没法改变一个人 > 位置 384您是说与过去没有关系？哲人：是的，这就是阿德勒心理学的立场。标注(黄色) - 再怎么“找原因”，也没法改变一个人 > 位置 389阿德勒心理学考虑的不是过去的“原因”，而是现在的“目的”。标注(黄色) - 心理创伤并不存在 > 位置 417任何经历本身并不是成功或者失败的原因。我们并非因为自身经历中的刺激——所谓的心理创伤——而痛苦，事实上我们会从经历中发现符合自己目的的因素。决定我们自身的不是过去的经历，而是我们自己赋予经历的意义。”标注(黄色) - 心理创伤并不存在 > 位置 423人生不是由别人赋予的，而是由自己选择的，是自己选择自己如何生活。标注(黄色) - 心理创伤并不存在 > 位置 443我们大家都是在为了某种“目的”而活着。这就是目的论。标注(黄色) - 你的不幸，皆是自己“选择”的 > 位置 599而是因为你认为“不幸”对你自身而言是一种“善”。标注(黄色) - 人们常常下定决心“不改变” > 位置 614某人如何看“世界”，又如何看“自己”，把这些“赋予意义的方式”汇集起来的概念就可以理解为生活方式。标注(黄色) - 你的人生取决于“当下” > 位置 706无论之前的人生发生过什么，都对今后的人生如何度过没有影响。”决定自己人生的是活在“此时此刻”的你自己。第二夜 一切烦恼都来自人际关系标注(黄色) - 为什么讨厌自己？ > 位置 780阿德勒心理学把这叫作“鼓励”。青年：鼓励？书签 - 一切烦恼都是人际关系的烦恼 > 位置 834标注(黄色) - 自卑情结只是一种借口 > 位置 936自卑情结是指把自己的自卑感当作某种借口使用的状态。标注(黄色) - 自卑情结只是一种借口 > 位置 943外部因果律”一词来进行说明。意思就是：将原本没有任何因果关系的事情解释成似乎有重大因果关系一样。标注(黄色) - 人生不是与他人的比赛 > 位置 1044健全的自卑感不是来自与别人的比较，而是来自与“理想的自己”的比较。标注(黄色) - 在意你长相的，只有你自己 > 位置 1071在意你长相的，只有你自己标注(黄色) - 人生的三大课题：交友课题、工作课题以及爱的课题 > 位置 1223交友课题、工作课题以及爱的课题标注(黄色) - 人生的三大课题：交友课题、工作课题以及爱的课题 > 位置 1224一切烦恼皆源于人际关系”标注(黄色) - 浪漫的红线和坚固的锁链 > 位置 1313当人能够感觉到“与这个人在一起可以无拘无束”的时候，才能够体会到爱。既没有自卑感也不必炫耀优越性，能够保持一种平静而自然的状态。真正的爱应该是这样的。标注(黄色) - 浪漫的红线和坚固的锁链 > 位置 1315束缚是想要支配对方的表现，也是一种基于不信任感的想法。与一个不信任自己的人处在同一个空间里，那就根本不可能保持一种自然状态。标注(黄色) - “人生谎言”教我们学会逃避 > 位置 1333那并不是因为无法容忍 A的缺点才讨厌他，而是你先有“要讨厌 A”这个目的，之后才找出了符合这个目的的缺点。标注(黄色) - “人生谎言”教我们学会逃避 > 位置 1345人就是这么任性而自私的生物，一旦产生这种想法，无论怎样都能发现对方的缺点。标注(黄色) - 阿德勒心理学是“勇气的心理学” > 位置 1373青年：也就是“不在于被给予了什么，而在于如何去使用被给予的东西”那句话吗？第三夜 让干涉你生活的人见鬼去标注(黄色) - 自由就是不再寻求认可？ > 位置 1405就是：“货币是被铸造的自由。”它是陀思妥耶夫斯基的小说中出现的一句话。“被铸造的自由”这种说法是何等的痛快啊！我认为这是一句非常精辟的话，它一语道破了货币的标注(黄色) - 自由就是不再寻求认可？ > 位置 1449阿德勒心理学否定寻求他人的认可。标注(黄色) - 要不要活在别人的期待中？ > 位置 1479在犹太教教义中有这么一句话：“倘若自己都不为自己活出自己的人生，那还有谁会为自己而活呢？”你就活在自己的人生中。书签 - 要不要活在别人的期待中？ > 位置 1498标注(黄色) - 砍断“格尔迪奥斯绳结” > 位置 1689否定原因论、否定精神创伤、采取目的论；认为人的烦恼全都是关于人际关系的烦恼；此外，不寻求认可或者课题分离也全都是反常识的理论。标注(黄色) - 自由就是被别人讨厌 > 位置 1764自由就是被别人讨厌”。标注(黄色) - 自由就是被别人讨厌 > 位置 1785不畏惧被人讨厌而是勇往直前，不随波逐流而是激流勇进，这才是对人而言的自由。第五夜 认真的人生“活在当下”标注(黄色) - 对决“人生最大的谎言” > 位置 2910人生中最大的谎言就是不活在“此时此刻”。纠结过去、关注未来，把微弱而模糊的光打向人生整体，自认为看到了些什么。标注(黄色) - 对决“人生最大的谎言” > 位置 2916因为过去和未来根本不存在，所以才要谈现在。起决定作用的既不是昨天也不是明天，而是“此时此刻”。标注(黄色) - 人生的意义，由你自己决定 > 位置 2982必须有人开始。即使别人不合作，那也与你无关。我的意见就是这样。应该由你开始，不用去考虑别人是否合作。”后记标注(黄色) - 位置 3011一切烦恼皆源于人际关系”“人可以随时改变并能够获得幸福”“问题不在于能力而在于勇气 ...