1691 条评论

友人C 1 星期前
💬 分享 于豆包平台上察觉到了一个名为「攻击性领导」的智能体。秉持着欲践行“非暴力沟通”之理念，进行了数个回合的交流，最终甘拜下风。LINK 此情形表明“非暴力沟通”绝非一蹴而就之法，而是需要历经诸多轮次的坚持，同时亦考验我们是否切实与对方的情绪建立了联结。
显然，于我的回合当中，我仅是套用公式，却未真正领会“领导”恼怒的缘由，亦未真切洞察“领导”的需求（“我”的工作取得良好成果）究竟为何。潜意识里，我始终认为这位“领导”并非正常之人，过于愚钝……我寻得另一位“非暴力沟通专家”智能体（尽管也并非特别专业……）令二者进行交流，最终获得了“领导”的认可。LINK 能够清晰地感受到，
“非暴力沟通专家”在沟通之时自身并无愤怒之情绪。我们拥有评判事物的标准，然而欲在沟通中不潜意识地评判对方着实困难重重啊。
（文字通过“豆包”进行润色）
 1 发自Mac OSX

友人C 2 星期前
🙉 奇奇怪怪 【频繁批判自己的人也在爱批判他人】
我发现很多时候觉得自己很糟糕或者做的不够好，并不只是简单评判自己，潜台词是在怪罪（评判）别人。这两者紧密关联以至于让人感到不可思议。
比如“我认为我被孤立，导致悲伤、伤心的感觉”，同时会潜意识认为对方“故意为之”，“故意”和自己过不去，或者认为别人没有按照我们的想法去做，没有给我们我们足够多的支持、理解。在批判自己过程也在不断的评判别人的过错，这可能因为评判自己过于痛苦，以至于我们潜意识不得不把责任归咎于他人。
当自己陷入评判自己的痛苦中：
1. 首先察觉到自己也正在评判别人。有意识的停止评判别人，会推动我们不去评判自己
2. 把所有注意力放到自己身上，觉察真正未被满足的需要是什么。这些需要可能是多层次，可能是需要完成某项进行中任务以及被尊重、被认可的需要，这些需要和具体的人无关，这些觉察进一步推动我们要怎么去做能够满足我们的需要。比如完成工作，可以把注意力全部放到当下工作中。如果想要获得认可，也不必从单一对象上进行，甚至可以来自自己的认可。这些想法让我们有更多可选择的行动，而不再是沉溺在负面情绪中
“It's All Depends On You”，“木鱼水心”视频中翻译为“一切的决定权，都在我们自己手中”，我非常喜欢。这一次，你可以自己决定自己的情绪，从停止评判任何人开始，从觉察自己真正的需要与做什么可以满足自己的需要开始。
 1 发自Mac OSX

友人C 2 星期前
📖 读书 《蛤蟆去看心理医生》，蛤蟆发觉了一直在批判自己，“会严厉的惩罚，包括折磨自己，在极端的案例里，甚至会施以极刑。但问题是，即便对自己轻判，这种谴责和惩罚也可能伴随一生，变成无期徒刑，”
蛤蟆问到：“苍鹭，我该怎么做，你能帮我吗？”
苍鹭回答道：“能帮你的人是你自己，也只有你自己。有许多问题需要你向自己发问。比如你能停止自我批判吗？你能对自己好一些吗？也许最重要的问题是，你能开始爱自己吗？”
【你能开始爱自己吗】
无数次听过鸡汤要爱自己，那怎么爱呢。停止批判自己是一种方式，但还是不够具体。从《非暴力沟通》里，也有单独一章是「爱自己」。
自我的批判，比如“我怎么那么蠢”，“我当时怎么做了那件事情”的想法会直接的产生“内疚、愧疚、压抑”这种让自己“失去与自身”连接的感受。可以从两方面去思考：
1. 当时那么做是为什么满足什么需要？ 一旦我们主动思考了这一点，也就能更好的理解自己，宽恕自己当时的行为。“遗憾总是难免，但不必后悔”
2. 现在是因为什么需要没有被满足，而感到“内疚、愧疚、压抑”？ 可能是需要被关注、被认同、被欣赏、被理解。当主动思考着一层后，之前的“内疚、愧疚、压抑”的感受就会被其他的感受所替代，比如“伤心、难过、遗憾、恐惧”。我们不再谴责自己，就会有动力推动自己去如何满足自己当下需要，从而从中学习、有所收获和成长。当批判自己，感到“内疚、愧疚、压抑”的时候，也是一次自我成长的机会。
“是否爱自己”，自己的注意力有多少放在自己的身上？也即有多频繁的关注自己的感受与需要？可能是我需要不断思考的一个问题。
 0 发自Mac OSX

友人C 3 星期前
🍃 handsome主题 把主题的大部分的字号调大的一号，长久以来感觉14px正文不太容易阅读，而且正文文字颜色在之前也调整了更黑了一些，不知道你们感受如何
 4 发自Mac OSX

胖哥 2 星期前
感觉怪怪的。默认的绿色主题对散光的我极其不友好。、
 0 发自Windows 10

友人C 2 星期前
哈哈，可以在右侧设置按钮里切换，我自己比较喜欢这个颜色
 0 发自Mac OSX

友人C 3 星期前
C++Tips Google C++ Style 关于输出参数在2020年5月20号 以及之前推荐使用指针：
Input parameters are usually values or const references, while output and input/output parameters will be pointers to non-const.
而在之后，则修改规范推荐使用了引用：
Input parameters should usually be values or const references, while required (non-nullable) output and input/output parameters should usually be references
个人认为指针作为输出参数更明确语意，如果使用引用参数，程序员可能漏写了const，从而输入参数被误认为是输出参数。
但是可能这不是一个好的理由，因为这是程序员自身的错误，同时传递指针需要内部判空使用有些麻烦。
 0 发自Mac OSX

友人C 3 星期前
📖 读书 最近在读《非暴力沟通》，很早在微信读书简单看过几页，这次买来实体书去看，觉得写的很不错。
非暴力沟通流程上并不复杂，沟通中遵循四个步骤即可：观察、感受、需要和请求，非暴力沟通核心在于不批判/评判任何事情，而专注自己的感受和需求是否被满足。
首先需要区分观察与评价。我试了一天进行这个训练，并不容易。比如“食堂有人不小心撞了一下，会下意识的骂道没长眼吗”，“等红绿灯的时候有人闯红灯就会暗想真没素质”。除了这种明显的评价以外，还有一些非常容易混淆的评价。比如你总是很早就下班，他每次开会都很晚才过来，他经常见面故意不打招呼。看上去是在描述事实，实际上已经带上评价的词汇，比如“总”、“每次”，“经常”，“故意”，这些词汇的评价大概率都是评价，观察在于描述准确的事实而不带有任何感情偏好。
其次区分感受与想法。感受一般以“我感到”开头，或者直接表达自己的情绪，比如我饿了、我感受孤单，我害怕等等。但是很容易与想法混淆。想法和评价类似，一般以“我认为” 开头，比如我认为他故意不理我，我认为他不尊重我，我认为他工作能力不行。会发现这两种很重要的区别在于，感受是来己自身，与他人无关，他人行为只是外在因素，并非是我们的感受。"我感到被孤立" 这种说法非常迷惑，实际上是一种想法，而非感受，更准确的表达是“我认为我被孤立”。
在非暴力沟通中，非常重要的一点就是意识到我们感受的根源是来自自身的需求未被满足，而非是他人的行为（可能有关，但不是根本因素）。只有意识到这里才能让我们跳出指责🫵他人的思维，更好的把注意力放到如何满足自身的需要上。
因此发现自己的需要至关重要。但特别注意的是，“需要”是我们自身渴求的资源，“需要”和满足需要的方法区分开。具体来说，“需要”不涉及到具体行为的人。比如，宿舍里太吵了，”我需要其他人安静一点“这不是书里定义的”需要“。这里真正的需要是”我需要更安静的环境以便更好休息/学习等“。只有区分这两点，在沟通中表达我们的需要，才能让对方不会觉得是在指责🫵对方。
在实际的的沟通中，为了让对方更好的倾听我们表达的感受、需要和请求，我们也需要主动的先去倾听对方的感受、需要和请求。尤其是识别对方语句中的感受和需求。
在这本书里，还有两个观点让我感觉很有意思：
• 对”感受“来源的曲解。现实中我们很容易将我们的感受归咎到其他人身上，比如，“他总是很懒让我很生气”。这里的潜意识是，我们希望通过这种表达，让对方内疚，希望利用对方的内疚来达成我们的目的，这其实就是一种语言“暴力”。换成“非暴力沟通”大致是：这一周的每天回家的时候，衣服都直接扔在沙发上（观察），我感到不开心（感受），我希望家里能够更整洁、更舒适（需要）。你能把衣服放到衣架上吗（请求）。” 由此可以发现同一种情绪，换一种表达方式就会减少对抗，实在是很神奇的，而后者没有指责🫵对方，更关注对方能够满足自己需要上。
PS：你也许会说，一次说了，这次改过来了，后面又是一次次的回家就扔到沙发上，每次都说，想不生气都难。一旦有生气的情绪，其实本质还是自己的需要没有被满足。如果自己表达了自己需求仍然没有被满足，说明对方没有真心认可你的说法，很可能是对方的需要没有被满足，不妨引导对方表达对方的感受和需要。比如对方可能工作回来很累，回家需要更放松，不希望太过有形式。在充分理解对方基础上，再协商提出新的需要，直到双方都能满足各自的需要为止。非暴力沟通中，倾听也是非常重要的一部分，不仅以更合适的方式表达自己的感受和需求，同时也需要从对方的话中识别出对方的感受和需要，
• “不得不”的曲解。我经常早上起床的时候会想，今天又“不得不”起床上班了，今天又不得不面对那些工作上的烦心事情了。这种表达方式是别人逼迫自己做的选择，自己也没有别的选择了，淡化了个人责任。书中建议改为“我选择___，因为”。比如上面的表达就可以改成"我选择每天起床上班，是因为我想要得到收入报酬以便自己能够过的更加体面和自由"。在这个表达里可以看到我们做的选择是为了满足我们特定的需要。
这两个 常见的曲解本质都是逃避了自己责任，是需要更好的觉察到的。
 0 发自Mac OSX

友人C 3 星期前
🙉 奇奇怪怪 对抗负面情绪是一件非常容易和非常困难的事情。简单是因为负面情绪不是真实的物理伤害，是可以人为控制的，比如别人给了你一拳，你首先感到疼痛，其次感到愤怒。前者是物理伤害，而后者则是自己产生的负面情绪和他人无关。困难的是很多事情似乎无法控制，负面情绪就是潮水一般的淹没大脑。个人觉得可能因为物理伤害经历的太少，所以才会过分的纠结于负面情绪吧。
经常看到一些“矫情”评论，底下回复：“关两天空调就老实了”。可能是类似的道理。关空调带来的难以忍受的热是物理伤害，只有当经历的物理伤害足够大的时候，才会对那些“情绪伤害”嗤之以鼻和云淡风轻吧。如果没有经历过彻骨的痛苦，又怎能珍惜当下呢，就很容易的陷入负面情绪了
所以如果你经常陷入负面情绪，也许你是不幸的，但也许也是幸福的OωO 因为痛苦总是相对的，也许你会说痛苦不能被比较，和他人比较痛苦是无意义的，但是自己感受的到的痛苦却是真实可比较的
 0 发自Mac OSX

友人C 1 个月前
💬 分享 New York is 3 hours ahead of California but it does not mean that California is slow, or that New York is fast. Both are working based on their own "Time Zone."
LINK
 0 发自Mac OSX

友人C 1 个月前
💼 从工作中学到的
    std::string origin_response_body = "test_content";
    const int body_len = origin_response_body.length();
    std::unique_ptr<char[]> response_body(new char[body_len]);
    memcpy(response_body.get(), origin_response_body.c_str(), body_len);
    std::string body = response_body.get(); 
这段代码是有隐患的，但是却比较难发现。因为如果这个数组中最后一位不是\0 结束符，构造string的过程中就会一直按照地址递增访问内存直到找到结束符为止，这个过程会导致内存异常访问等问题
但在真实环境中，可能不一定会导致崩溃，因为当我们new[body_len] 申请一段内存的时候，由于内存对齐以及操作系统的差异性，分配的大小会大于申请的大小，因此在body_len 位置的内存很可能就是结束符。 C++Tips
 1 发自Mac OSX

胖哥 4 星期前
1:
std::unique_ptr<char[]> response_body(new char[body_len + 1]); // 分配空间 这种非常重要 且常见
memcpy(response_body.get(), origin_response_body.c_str(), body_len + 1); // 拷贝完整字符串
2：动态分配 在设计、开发阶段是要被严格管控的， 至少做到1、在详细设计阶段就要体现在文档里。2、边界检查 3、测试覆盖
 0 发自Windows 10

胖哥 4 星期前
好像发的不对，检查了下，基本没有临时的动态分配、
 0 发自Windows 10

友人C 4 星期前
我这里简化了，memcpy的逻辑是另一个函数的事情，函数参数就是char*，所以外部必须传入一个分配好空间的字符指针进去
这个是sdk的代码，个人觉得c++项目而且没有那么高的性能要求下，尽量可以不用char*指针，同时这个sdk内部保存的就是string，但是函数参数是char*导致string->char*->string 这样诡异的逻辑出现
 0 发自Mac OSX

友人C 1 个月前
📝 每日记录 「自我觉察」
今天晚上在写一篇“读后感”，写了1小时左右发现自己进入了“状态”了，从而发现进入状态的重要性。
之前可能觉得“进入状态”只是一个形容词，而今天发现它确实是做好事情的一个具体的步骤。
这里列举目前想到的一些条件：
1. 良好的环境：环境是重要的，比如安静环境下更容易专注。但是很多的时候可能没有那么好的环境，因此可以尝试更好的环境，比如耳塞或者纯音乐，文档全屏等，但注意不要为此舍本逐末了。
2. 第一个可以看到显著效果的行动：如果是写文章，很容易一下午一个字也憋不出来，原因很可能是我们脑子里想的太多了，从文章的摘要到各种细节都在脑子里面转，而不在纸上，导致无法聚焦到一点，因此可以考虑先写下几点，然后不用太关注格式，再去展开第一点，等写完第一点后，就会发现后面的内容自然的有了思路。如果是写代码，可以尝试从UT开始写起，完成第一个可验证通过的UT。如果不具备写UT的条件，可以从完成第一个可以编译通过的代码开始，再到实际上产生具体作用的函数。一定不要一开始就kuchikuchi的创建一堆文件，也编译不通过，希望一次性写完编译，这是非常严重的错误。
3. 进入状态的决心：必须要有想进入状态的决心，比如今晚你确实计划想完成某项任务，这非常重要。
4. 较长的时间长度：进入状态的时间最好是1小时起。如果太短，则完成的事情有限，因此需要确保这一小时不被其他事情打断（比如开会，其他人找过来问问题等）
5. 单一工作内容：只专注在一件事，而非同时多个任务切换
 0 发自Mac OSX

友人C 1 个月前
🙉 奇奇怪怪 最近很火的 AI 认为 9.11 > 9.8 我的第一反应居然和AI一样... 可能是版本号看多了吧
 6 发自Mac OSX

友人C 2 个月前
🙉 奇奇怪怪 看到一个评论很有意思：“至少我从来没听说过有人死前还会想着，这辈子没有赚更多的钱没有为当年的公司做更多的牛马之事。”
 1 发自Mac OSX

友人C 2 个月前
💼 从工作中学到的
最近的两个需求尝试以 “面向测试开发”来开发。所谓“面向测试开发”，或者“测试驱动开发”，我理解就是先去写UT，先去在UT里面写好调用的函数和预期的接口。每写一个EXPECT，对应去实现类的功能，这样写完UT，功能也开发完成了，保证了模块的质量。
通过这种方式发现写代码的阻力更小一些。之前写代码脑子里可能混杂多个接口的设计想法，通过UT，每次只增加一个新的case，实现该case，能够“小步快走”，会更不容易出错。
这对项目代码质量是有比较大的要求的，如果是一个新的独立模块，还好一些，可以从零开始写UT，如果这个模块有依赖外部模块，需要mock或者外部模块也具有可测性。
如果是在已有的功能模块里新增新的功能，这就要求已有模块可测性非常强才行。历史的很多代码都没有UT，这也是困难之一吧。
 2 发自Mac OSX

友人C 2 个月前
💼 从工作中学到的
“当你排除一切不可能的情况，剩下的，不管多难以置信，那都是事实。”
工作中排查bug的时候很像是侦探🕵️寻找真相。简单的bug可能很快从代码review就能发现，比如空指针等。这周遇到了一个bug ，简单来说，
• 正常情况下是先执行B操作，再执行 C操作。
• 执行A 操作后，预期就不可能有B操作或者C操作了，但是A操作它是跨线程异步过程（一般时间很短几毫秒或者几十毫秒之内）。
线上的问题是在A操作过程中，出现了B操作，导致后续C操作的时候直接崩溃。所以线上会有概率非常小的情况下崩溃。
这里写代码的时候没有考虑到这个异步过程，同时B操作或者C操作中应该增加判断，如果A操作后，就是空操作。
 1 发自Mac OSX

友人C 2 个月前
💬 分享 vscode一直使用的都是深色主题。最近上午显示器因为光线太亮了，黑色看不太清，改用了浅色主题「Solarized Light」，不刺眼，而且颜色很柔和浅黄色，很喜欢，推荐！
 0 发自Mac OSX