关于我
-
来自南部的一个小城市,个性不张扬,讨厌随波逐流。
那年今日
🥳 周末 [WEEK-05] 这周只休息一天,即使只上班了4天,但是仍然觉得一周休一天实在是不够啊!🎬 电影 晚上看了《和莎莫的500天》,是deepseek推荐的:)看之前我以为是男主和女主...
💼 工作记录 今天要修复一个之前写业务代码模块时候的一个bug,已经好几个月没写太多业务代码了。这让我回想起写业务代码有写业务的挣扎。新增或者修改一个接口经常要想很久,尤其设计了很多业务特化点的...
💬 随便聊聊 以前吃饭的时候会看一下解读娱乐圈的视频,比如哪个明星又怎么样出丑了,或者装B了...看看乐子。现在再去看这种逐帧的剖析剪辑后的视频,总感觉不舒服。当根据某几帧画面就去给一个人定罪,...
💬 分享 vscode一直使用的都是深色主题。最近上午显示器因为光线太亮了,黑色看不太清,改用了浅色主题「Solarized Light」,不刺眼,而且颜色很柔和浅黄色,很喜欢,推荐!
📝 每日记录 【忙碌的端午】可能是最近一段时间最忙的一个节日了。端午节,我姐婚礼,我当伴郎🤵。还有另外三个伴郎都是姐夫的同学,我和他们完全不熟的!不过幸好的是他们人都超级好,其中还借给我皮鞋穿。...
💼 工作记录 平时工作里经常需要下载特定版本的chromium,发现已有的一些网站都不好用,用trae 🤖 AI 写了一个页面 https://github.com/ihewro/chrome_version/ ,99%都是AI完成的,算是ai含量最高的一次尝试了,有几个感受:
总之,越来越大的上下文一定是进一步发掘ai能力的一个关口
💼 工作记录 做事情的时候一定要做一步记录一步,每一步都走踏实了,切忌同时并行铺开很多方向,每个方向都浅尝辄止,这样前面的很多时间的收益就没有那么高了。最慢的反而是唯一的捷径。
💼 工作记录 工作三年得出最重要的一个想法:你始终要坚信自己能做的比任何人好,不迷信权威
💼 工作记录 发现有不少代码都是我当时参加的方案评审,当时想的是,每个人都有自己的编程习惯,所以我不太会强求别人在代码设计上一定要怎么样...比如命名风格,函数抽象,类设计等。但是这些我参加评审的代码模块最后都交接给我了
所以如果别人找你review代码或者是方案评审,就一定要坚持自己原则,别人如果觉得不对,那就提出来讨论就好了
💼 工作记录 职场不是学校,没有人有义务为你的努力打分,除非你能证明它值钱。
💼 工作记录 三年前,我用 electron 写了一个番茄钟 🍅 TLog (为什么是electron,因为它是跨平台成本最小的开发方式了 hhh),当时的初衷是为了替代滴答清单里面番茄钟,因为不想再用滴答清单了,所以它的界面就是参考滴答清单的番茄钟。
我在https://www.ihewro.com/archives/1205/ 也提到了这一点。
这个软件我用了两年,在2023年、2024年我又基本上没有再用了,而今年我准备重新捡起来,用于增强注意力专注能力。在博客右侧边栏增加了当天的专注数据小组件。
后端比较简单,就是同步数据库更新指令操作数据库,之前用python实现的,后面准备改为typecho的一个插件来实现,后面再准备以合适方式对外发布这款软件。
它有一些特点:
当然还有一些想法未实现,但整体还是希望简单,而不是成为一个项目管理这种复杂逻辑的软件:
很需要这个~~ 简单而又高效
您好,工具方便分享吗?同想用。
代码还需要再整理一下才能发布 比如现在软件里面调用后端接口地址是写死的。如果有其他感兴趣朋友可以给这条说说点赞提升优先级~
挺感谢去的,作者大大加加油
大家也可以分享下,现在有无使用番茄钟,现有的番茄钟是否有未被满足的需求的
另外一个非常大的缺点就是付费,虽然不多,就百块一年,但是就很不爽。
刚刚付费的我的碎碎念(生气#/qf)
很多不能满足的需求,整理下回复到这条评论下面。
我在做一个和硬件结合的番茄时钟,但是实现上不是非常顺利,滴答清单的API虽然丰富,但是数据用起来很不习惯,而且数据大部分都是单向的(本地获取服务器上的清单),我很多时候需求都是提醒自己什么时间做什么。 然后就是UI,不喜欢番茄时钟的风格,不支持缩放,对多屏不友好,提醒比较软,不支持一键开始,等等。
💼 工作记录 从工作中学到的一点:任何没有细化的目标都是空中楼阁。工作中可能有的时候leade一时兴起说要达成什么目标,但是又不给资源和重视,甚至也没有截止时间,就感觉只是提了一嘴,属于“薛定谔的重要且不紧急”的工作,这种工作很容易就会被遗忘掉...给自己制定目标同样,如果没有细分任务、阶段性汇报、阶段性里程碑,这样的目标完全就是欺骗自己。
确实,同感
📝 每日记录 有点感冒了,今天疲惫的要命。晚上和另一个同事随口说感冒好难受,昨晚睡了12个小时。我才发现自己并不是需要对方做什么,就是一句同理的回应就足矣了,比如“啊,这真的太难受了吧,上次感冒我也是这么疲惫了好几天”。 😷 生病的事
💼 工作记录
下午leader给我们小组做了“结构化表达”的培训。简单来说就是表达需要带有目的,在这个基础上使用一些框架(比如SQCA描述问题或者PREP 表达观点)。
会上提到了一个小问题,是华为的一道面试题“怎么运输800斤的牛过承重700斤的桥”。有点可悲的是,当时想象力完全被扼杀了,以至于我看到这个问题后,除了把牛杀了想不到别的方法了,甚至还会有“把牛杀了这个答案肯定不行的吧”的自我否定。
结构化表达的第一步骤是将“隐性思维显性化”,问题是运输牛,实际上就涉及到牛、运输方式、桥这三个基本因素,再发散一点还和当时的环境有关。所以分别在这四点上进行改进就能回答这个问题了。
这个思维方式给我有很大的启发。 表达和思维是相关的,因此这些模式即可用来表达(组织已有的内容),也可以用来思维(思考未完成的内容)。
💼 工作记录 工作中,如果同事对你的工作不满你会如何应对?比如跨团队同事合作,因为细节之前不了解,反复追问对方,然后对方不耐烦了,或者是别人对你的工作提出批评。
之前,我可能会下意识的内在批判者就开始启动了,肯定是自己太笨了,自己太让人烦了吧。
其实很早就会告诉自己,不要批判自己,但是一直没有去思考:“那正确答案是什么?”存在一种不用批判自己的应对方式吗?
可能你会说,转而批胖别人,将情绪的宣泄口转向对方,别人骂我我就骂回去。这还不对。
承认自己做的没有足够好,承认自己让别人烦了,但是不批判自己可以吗?因为这不是我们自己的错。承认是表示同理对方的感受,对方也可能经历“战反应”的情绪闪回。但不认为是自身价值的缺失,即抛弃“全或无”的观点。
💼 工作记录 今天要修复一个之前写业务代码模块时候的一个bug,已经好几个月没写太多业务代码了。这让我回想起写业务代码有写业务的挣扎。新增或者修改一个接口经常要想很久,尤其设计了很多业务特化点的时候,减少特化和最小改动之间不断进行权衡。
💼 工作记录 最近整理之前最早工作时候调研的一些关于进程、内存指标概念的文章。
刚开始工作有很多时间用来调研和学习,mentor也很支持我,所以当时想猛攻这部分然后能写出一篇非常专业、完善、严谨的文章来。但是因为内存指标涉及到的内容很广,比如系统物理内存管理方式,虚拟内存技术中的概念,内存申请方式,不同操作系统中术语看似相似实际差别巨大,导致这篇文章一直没有写完。
这次重新整理内容发现,像这种复杂的话题的写作,如果是专注于全就不用太深(配合更多的图表来梳理概念之间的关系),同时尽量避免知识性错误;如果专注于深,就不能太广泛,否则就会让自己陷入一个短时间难以完成的境地(比如内存这个话题可能需要很年的排查经验、源码研究等才能又全又深入,到足以出书的程度)。这个方式适合很多复杂话题的写作,比如耗时问题优化、性能品质、某个工具的使用等等。
💼 工作记录
这段代码是有隐患的,但是却比较难发现。因为如果这个数组中最后一位不是
\0
结束符,构造string的过程中就会一直按照地址递增访问内存直到找到结束符为止,这个过程会导致内存异常访问等问题但在真实环境中,可能不一定会导致崩溃,因为当我们new[body_len] 申请一段内存的时候,由于内存对齐以及操作系统的差异性,分配的大小会大于申请的大小,因此在body_len 位置的内存很可能就是结束符。 C++Tips
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、测试覆盖
好像发的不对,检查了下,基本没有临时的动态分配、
我这里简化了,memcpy的逻辑是另一个函数的事情,函数参数就是char*,所以外部必须传入一个分配好空间的字符指针进去
这个是sdk的代码,个人觉得c++项目而且没有那么高的性能要求下,尽量可以不用char*指针,同时这个sdk内部保存的就是string,但是函数参数是char*导致string->char*->string 这样诡异的逻辑出现
💼 工作记录
最近的两个需求尝试以 “面向测试开发”来开发。所谓“面向测试开发”,或者“测试驱动开发”,我理解就是先去写UT,先去在UT里面写好调用的函数和预期的接口。每写一个EXPECT,对应去实现类的功能,这样写完UT,功能也开发完成了,保证了模块的质量。
通过这种方式发现写代码的阻力更小一些。之前写代码脑子里可能混杂多个接口的设计想法,通过UT,每次只增加一个新的case,实现该case,能够“小步快走”,会更不容易出错。
这对项目代码质量是有比较大的要求的,如果是一个新的独立模块,还好一些,可以从零开始写UT,如果这个模块有依赖外部模块,需要mock或者外部模块也具有可测性。
如果是在已有的功能模块里新增新的功能,这就要求已有模块可测性非常强才行。历史的很多代码都没有UT,这也是困难之一吧。
💼 工作记录
“当你排除一切不可能的情况,剩下的,不管多难以置信,那都是事实。”
工作中排查bug的时候很像是侦探🕵️寻找真相。简单的bug可能很快从代码review就能发现,比如空指针等。这周遇到了一个bug ,简单来说,
线上的问题是在A操作过程中,出现了B操作,导致后续C操作的时候直接崩溃。所以线上会有概率非常小的情况下崩溃。
这里写代码的时候没有考虑到这个异步过程,同时B操作或者C操作中应该增加判断,如果A操作后,就是空操作。