1751 条评论

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

友人C 2 星期前
要想让自己始终是 “请求”，而不是“要求”别人的一个方法是，当你有一个对别人的请求的时候，就立即去说出来。在脑海里构建的时间越长，投入的精力越多，就越可能强迫别人满足自己的“请求”，从而变成一个要求。
 0 发自Windows 10

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

友人C 2 星期前
"情绪闪回"
 0 发自Mac OSX

友人C 4 个月前
💬 分享 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 4 个月前
💼 工作记录
    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

胖哥 3 个月前
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

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

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

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

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

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

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

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

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

友人C 5 个月前
💬 自言自语 “学习的最佳效率，是抽空 做事的最好状态是兼职” 多多视频看到的一句话，甚是觉得有理。很多时候都在想，不上班就好了，就可以干嘛干嘛了，但实际上真不上班了，又会有经济上的负担，因此，在上班基础上，抽空做事未尝不是一种办法
 0 发自Mac OSX

星图 5 个月前
需要有一个前提，能抽空
 0 发自Mac OSX

友人C 5 个月前
🍃 handsome主题 增加了一个引用说说的功能： 牙疼的时候才想起早干嘛不勤刷牙，生病时候才想起早不锻炼身体，不合理饮食了，快死的时候才想起早干...
但没有增加反向引用，因为如果一个页面中每条说说都去查询反向列表，sql 查询可能有些耗时

 1 发自Mac OSX

墨竹 5 个月前
佬，新版在盒子模型的基础上加个整体宽度选项呗，默认、窄、宽。现在的版本在笔记本15寸1080p上还可以，但在27寸4k显示器上就有点宽
 0 发自Windows 10

友人C 5 个月前
你的显示器分辨率是多少呀？
 0 发自Mac OSX

墨竹 5 个月前
目前就是4k 3840*2160 缩放 175%
 0 发自Windows 10

友人C 5 个月前
会考虑的
 0 发自Mac OSX

友人C 5 个月前
🍃 handsome主题 增加了一个有趣功能，在文章下方会显示反向引用和引用的列表
(PS: v10.0 目前在开发阶段，正式发布仍需要一段时间)

 6 发自Mac OSX

友人C 5 个月前
💼 工作记录 对于客户端开发来说，crash是性能/稳定性中最重要的指标之一，因为crash意味着功能不可用。
最近工作上引入了两个功能crash，被折腾了一番，有一个感想：“对任何改动的上线一定要测试”。这里“测试”根据不同情况有不同程度测试，其中最基本的测试是确认功能是否能跑起来，而不仅仅是编译通过即可。
可能你会说，提代码肯定需要测试啊。但是有些场景，可能就会偷懒，比如加一行日志，或者简单增加一个指针判空，或者简单调整了两行代码的位置，就因为“匆忙”，并且过度自信，就没有测试，甚至基本测试都没有！
上述的场景可能是本地的分支开发别的功能，突然反馈过来的一个bugfix，为了本地不切分支，而选择在网页端简单提交bugfix的代码
这些看上去“人畜无害”的代码，其实往往暗藏“玄机”。比如日志打印调用了一个指针的函数，却没有检查指针是否为空，误以为指针一定不为空，尤其是在编写宏的情况，更容易忽视。
除了这些改动极小的代码，一些不是特别大的改动也可能引入意想不到的问题。举个例子，移动了某一个observer 事件发送的位置，在模块owner看来可能没什么关系，但可能外部利用了这个observer，并且依赖了某种时序，一旦某两行代码调整了顺序就可能导致异常。
这里有一个调整两行代码顺序导致问题的例子：
....
std::string str = "1234";
SomeStrToInt(str);
SomeClassConstruct class (std::move(str));
其中第3行和第4行的位置调整就会导致异常，而这个问题非常难以发现，因为最开始的这段代码可能比较久远，甚至不是自己写的，因此就会忽视后面对string move的调用。
---
有经验的程序员是否可以避免上述问题，足够细心的条件下一些简单的错误可以被避免，比如上面的std::move 顺序问题。但是对于更复杂的场景忽略掉也是可以被理解的，更不用说，粗心是一种很容易犯的问题。
因此黑盒测试的必要性是无法被白盒测试替代，白盒测试100%覆盖是一个理想而不及的目标，受限于代码可测性、ut质量等等因素。意味着一定有不少场景是UT无法覆盖的部分，对于大型项目尤其如此。（尽管如此，UT重要性仍然是不言而喻）
---
我个人的一点想法是对任何提交MR做以下两点检查：
• 做了哪些测试来减少问题发生 （至少要测试功能是否可以跑起来，而不是过度自信）
• 是否对该处改动的所有外部依赖都清楚，如果不清楚则优先考虑使用灰度验证的方式上线（比如修改某个对外的接口返回值，不要过度自信！）
上面的两点check不能避免所有的问题，但可以拦截大部分很低级的问题（事实很问题都来自低级的错误），除此之外，成熟的工程会一般会有完备的稳定性流程来拦截更复杂的问题。
 1 发自Mac OSX

胖哥 5 个月前
冒烟测试 你们这边是开发自测的吗 还是有专门的团队、工具做冒烟测试的呢？
crash我们一般很多会遇到，在冒烟测试拦截的居多， 然后取dump文件，分析定位，建BUGid 解决bug 回顾总结 写rootcase。
 0 发自Windows 10

友人C 5 个月前
各个环节也是有的，比较头疼是写「回顾总结」文档，感觉团队里有些太重文档，文档写了具体原因还要一遍遍的修改细节，绘制图之类
 0 发自Mac OSX

友人C 6 个月前
📝 每日记录 今天我碰到一个老太太，她说：“想吃啥就买啥，买回来吃得下就是最幸福的事！”我突然意识到，经历了身体不适后，能畅快呼吸才是最大的幸福。
😷 生病的事 去年4月开始胸闷，原以为夏天会自愈，却愈发严重，走了不下8、9次医院，从呼吸科到心脏科，再到肠胃科。一开始呼吸不顺畅，到10月更加频繁，夜间难受，早晨仍不适。躺床上唯一想的是早点康复，畅快呼吸成唯一奢望！
11月，胸闷变胃不适，反酸+胸闷。除肠胃镜外，做了胸部/心脏CT。吃药治疗，一度好转，但又反弹。
12月，胸闷缓解，开始嗳气，反酸减轻。嗳气频繁，一天嗝百余次，难受。4月底超声显示胃正常，但嗳气仍频繁。
3月停药，调整作息，早睡早起，控制饮食。5月中嗳气减轻，胸闷改善，生活正常。终于看到曙光。
如期盼的，畅快呼吸、健康无疾，就已幸福。只要有美食且能享用，便最快乐。生病时渴望康复，康复后又追求更多。这次病或许长而深刻，让我知足。
曾焦虑未来，名利如何，欲望无尽！若生命倒计时，珍惜生活比名利更重。听《好了歌·解》，感慨良多。或许，正视最坏结果，就是“向死而生”。知足与懒惰、进取并非冲突。
正叹他人命不长
哪知自己归来丧
经过CiciAI 润色文本
 1 发自Mac OSX

Chuck 5 个月前
感觉和你一模一样，最近公司赶项目很累，经常夜间胸闷，去医院查了好多次，也没发现什么病因，但愿能快点好起来。
 1 发自Windows 10