前言 本文是什么 终端工具FZF的简单介绍和入门 「个人」对此工具的使用和实践，尤其是一些扩展使用方式 【矫情】由小及大，怎么联想到一些其他的东西的 本文不是什么 不是“最佳实践” 「最佳实践」是指在特定领域内经过实践检验并证明具有卓越效果的技术、方法、流程、活动或机制。它们之所以被称为「最佳」，是因为这些实践能够在提高效率、降低成本、提升质量、确保安全、增强客户满意度等方面展现出超越平均水平或现有做法的优势。 这篇文章显然配不上这个称谓 不是系统性的使用教程，更不是使用手册 RTFM 😊 Wiki FZF是什么 基于终端和命令行的工具（CLI） 提供「模糊」搜索的功能（Fuzzy Search） 提供一个简单但直观的TUI （Integrated with Other Tools） 基础用法 查找文件：直接使用 你可以直接在命令行下面输入对应的命令，-m表示多选，默认行为是列出当前文件夹下的所有文件，选中后按回车会把路径/文件名显示在命令行上 fzf fzf -m vim $(fzf -m) 还可以通过环境变量配置预览效果、窗口大小、快捷键等。 因为是环境变量，所以如果在Shell配置文件里将其export，让它被子进程继承，那么所有的相关配置无需重复配置，便可以在子进程（例如Vim中）生效，后面将在Vim集成章节中稍稍展示一下。 典型例子如下（具体含义请参见官方文档）： FZF_DEFAULT_COMMAND FZF_DEFAULT_OPTS FZF_DEFAULT_OPTS_FILE 简单语法 fzf支持一套语法（丐版正则），让你能在fuzzy的过程中，还是有一定的搜索效率，以下仅列出部分，更多请参考官方文档 Token Match type Description sbtrkt fuzzy-match Items that match sbtrkt 'wild exact-match (quoted) Items that include wild ^music prefix-exact-match Items that start with music .mp3$ suffix-exact-match Items that end with .mp3 !fire inverse-exact-match Items that do not include fire !^music inverse-prefix-exact-match Items that do not start with music !.mp3$ inverse-suffix-exact-match Items that do not end with .mp3 与Shell集成 查看Shell命令历史 使用快捷键Ctrl+R查看Shell命令历史，如果你使用的是原始的bash或者zsh的话，基本可以替换原来的功能，使用起来友好得多；如果你和我一样，主要使用fish，那可能不一定用得上，但我由于个人使用习惯，目前仍然在使用fzf的这个功能，而不是fish自带的那个也蛮好用的历史记录。 ...

The ORIGINAL post Abstract 约翰麦卡锡于1960年发表了一篇非凡的论文,他在这篇论文中对编程的贡献有如 欧几里德对几何的贡献.1 他向我们展示了,在只给定几个简单的操作符和一个 表示函数的记号的基础上, 如何构造出一个完整的编程语言. 麦卡锡称这种语 言为Lisp, 意为List Processing, 因为他的主要思想之一是用一种简单的数据 结构表(list)来代表代码和数据. 值得注意的是,麦卡锡所作的发现,不仅是计算机史上划时代的大事, 而且是一种 在我们这个时代编程越来越趋向的模式.我认为目前为止只有两种真正干净利落, 始终如一的编程模式:C语言模式和Lisp语言模式.此二者就象两座高地, 在它们 中间是尤如沼泽的低地.随着计算机变得越来越强大,新开发的语言一直在坚定地 趋向于Lisp模式. 二十年来,开发新编程语言的一个流行的秘决是,取C语言的计 算模式,逐渐地往上加Lisp模式的特性,例如运行时类型和无用单元收集. 在这篇文章中我尽可能用最简单的术语来解释约翰麦卡锡所做的发现. 关键是我 们不仅要学习某个人四十年前得出的有趣理论结果, 而且展示编程语言的发展方 向. Lisp的不同寻常之处–也就是它优质的定义–是它能够自己来编写自己. 为了理解约翰麦卡锡所表述的这个特点,我们将追溯他的步伐,并将他的数学标记 转换成能够运行的Common Lisp代码. Addendum Paul Graham原文

简介 主要面向计算机技术新手（甚至是简中限定），分享一下我对 如何拓宽技术视野 如何找到自己想要的东西 的一些建议和体会，希望能帮助到一些朋友，随手一写，随时更新。 免责声明： 仅为个人体会，无任何权威性，我也是一个时常陷入迷茫的普通人，请酌情食用。 正文 保持【好奇心】与对计算机科学/工程的【热情】，多【思考】 最好是有科学上网的能力 -> 你如果自己搭的话，这个过程甚至就已经是延伸视野的起点之一了 学好英语，具备基本的读写能力，最好是能有一定的听说能力 系统性学习，比如读经典书籍，相信“正确”事情的长期价值。我个人是不太相信“碎片化”学习的，它只适用于一定特定的场景。 不要认为“折腾”是完全浪费时间。“折腾”重要的是过程，不是结果。 摸鱼是第一生产力，这个行业确实变化很快，勤奋可能会让你挣钱，并不完全能让你的能力提升（如果你的目的只是挣钱，那可能就无所谓了），一般来说【懒】的牛人会推动技术进步）， 如果你在工作 ，你要做的是在下班后完全放下工作、甚至工作时间间歇性地放下工作。工作能带给你提升，但不会一直给你提升 如果你还是学生，那么恭喜你，你有远超工作党们的折腾时间，请不要局限于课堂，甚至不要当老师眼里的好学生。大多数老师不会为你的未来负责，为自己的未来负责的只有你自己 常逛GitHub或优质的技术论坛，技术视野多是交流出来的（但简中互联网优质资源确实相对少） Google/ChatGPT GitHub: awesome-xxxx telegram/discord的相关群组 如果没法翻墙，可以考虑一些“卖课”的课程，但要仔细甄别，少被割韭菜。免费的话B站有很多还不错的资源（这点上我还是喜欢B站的），包括一些课程，或者是优质的UP主的分享 ….. 向周围（或者网络公众人物）优秀的人学习，你认为他在某个方面值得你学习，去学就是了，但不要把自己饭圈化了，人无完人，小心人家割你韭菜（当然你如果真的愿意，那就不是被割） 对于绝大多数人来说，计算机是工程学科，动手去做，螺旋上升，learn by projects … 举例 我是怎么接触到vim/nvim的，怎么“学会”vim/nvim的 怎么找到我视频里那些“教程”的 missing-semster 反面例子：AI知识学习🥲，战略上懒惰啦 … 结尾 我不是一个推崇方法论的人，任何方法论都有其适用和不适用的点（此处似乎有方法论悖论🤣）。很多人懂得很多道理，却仍然过不好这一辈子（包括我自己）。正所谓“学而不思则罔，思而不学而殆”。 我只能说多实践、多思考：光思考（“思”）可能会变成满口方法论但却眼高手低的人，光实践（“学”）可能会让自己迷失在一条路上，用战术上的勤奋掩盖战略上的懒惰。 大家共勉，Peace.

简介 这是我看TJ的一个视频，不能说有感而发吧，但确实引起了我的一些共鸣，时间有限在这里做些简单的记录和总结，后续有时间再更系统地写自己的感想吧。转载请注明出处。 观点提取 其实大家想问的是：我是否仍然能够通过学习编码时所学到的技能获得报酬 软件不仅仅是编码 编程本身不仅仅是编码 人工智能将能够完成初级工程师目前面临的编码任务，人工智能将能够比那些初级工程师更快、更便宜地执行这些任务 人们不会为代码付费，他们肯定不会付费只是为了观看你的代码，除非你是一个 twitch 流媒体:) 他们支付的是要解决的问题，当你编码时，你不会因为该代码而获得报酬，你会得到报酬来解决别人的实际问题或感知到的问题 你获得报酬的原因是因为你为某人解决的问题（这里后续展开说说，技术/业务间的关系），而这个关系足够有价值，让他们足以放弃他们"心爱的现金"，这可以归结为软件 能够提供比以前更快、更便宜或更可靠的东西。 软件是那些直接在计算机中输入的编码任务的超级集合，因为你需要的不仅仅是好的算法或好的类型系统 你需要理解客户需求需求并在情况发生变化时更新它们，你甚至可能会要出来与客户或利益相关者交谈，所以你要练习沟通技巧。 沟通也包括很多非技术方面，有时你需要向非技术人员传达技术概念 需要能够对您专业领域内的人员说不 项目无法正确完成所有事情 对想做但是成本过高的事情说不 它的价值是什么 软件和制作软件有社交方面的因素，比如倾听反馈和提供建设性反馈，有指导和被指导，有耐心、善意和尊重，所有这些都创建了通常看起来像团队的团队，更有效地创建软件，询问和理解诸如我们如何在这家公司赚钱之类的问题 我曾经工作过的最好的软件开发人员在所有这些方面都很出色，包括编码。他们肯定很擅长编写代码，但他们理解 这些技能中的每一项都帮助我学会更好地完成另一项，只要我们有工作，所有这些技能仍然有用 编程本身不仅仅是编码。两类程序员，一类是解决方案复制者，一类是问题解决者 解决方案复制者不仅仅是使用复制粘贴解决方案，而是使用复制粘贴解决方案来解决复制粘贴问题，而无需检查和确认（这里他举了个非程序员的例子来进一步澄清这两种类型的区别） 解决方案复制者对事情如何运作不感兴趣，他们只是一个一个接需求。他们不知道不同的库、语言和工具可以解决他们的问题的方式，或者可能无法解决他们的问题，他们只是复制粘贴StackOverflow上问题中的第一个解决方案，或者现在可能是他们最喜欢的 llm，直到CI变绿为止，而不考虑他们当前所处环境 这不仅仅限于我们一直在谈论的技术问题，可能是他们对如何赚钱或者他们的客户想要什么，也许他们从未考虑过「我们自己组织的结构是否可以帮助我们实现我们打算做的目标和愿望」 相比之下，我们有问题解决者，这些都是好奇的人 他们试图通过理解来解决问题，我认为即使我们不再编写一行代码，这些技能仍然有用 我认为人们低估了他们可以通过软件开发再次学习的技能。 我的观点是，即使你已经编写代码很长时间了，也有可能不学习这些，也不练习这些。例如 例如，我认为逻辑思维是我们在做软件时可以练习的东西 开发中，我们可以练习将大问题分解为更小的问题 我们可以致力于识别迭代并为客户解决问题，他们实际上愿意为您付费，以便可以更好地进行领域分析，正确理解问题集可能的解决方案，然后如何实施一些业务逻辑或流程来解决问题 可以致力于预测这些流程的边缘情况或故障模式 学习如何管理/解决工程中的权衡点 模式识别 这对我们都很有用。在我看来，这些技能中的每一项至少都像你可以训练并变得更好的肌肉，你可以使用软件开发作为进行训练的工具，只要我们有能力，所有这些技能都将再次有用 这些在工作中的软技能，其实与我在软件部分提到的软技能一样（然后举了两个Neovim相关的例子） 您可以用任何您想要的技术替换 neovim， react、rust、htmx、Excel等等，模式和想法是相同的，我的最终观点是您可以 选择你将如何解决问题以及你从实际解决问题中获得的收获，从单纯的复制粘贴转向"Problem Solver" 在实际的例子中，你可以尝试为自己构建一些东西来做到这一点解决你遇到的实际问题。如果其他人已经构建了它也没关系，重点是你要为自己构建它，看看你是否可以解决这个问题 为自己构建一些东西的时候，你就是自己有效反馈，让你知道你是否解决了问题。如果你没有解决，那没关系，你可以重复。失败是可以的，这是我们学习的一部分，重要的是我们利用我们的粗糙和坚韧再次尝试 但要明确的是，我并不是说解决方案复印机是坏人，或者我不喜欢他们，相反，我试图传达这样的信息：如果我开发的所有技能都围绕着重复现有解决方案（拾人牙慧），我会更担心。对我来说，现有的解决方案似乎是一个更有可能通过人工智能以某种方式实现自动化的领域 对我来说有这样的建议，比如保持好奇心，注意努力工作，不要害怕失败。那些从来没有真正让我误入歧途。在我看来以这种方式思考是正确的，无论人工智能如何快速和彻底地扩展到其他软件领域 我不知道未来会是什么样子我 我只是一个普通凡人。但我确实认为，即使不考虑我在整个视频中提出的所有论点，如果你当前的假设是数十亿行新代码将会产生，那么重要的是真正理解有关代码的一些事情，不是所有的事情，不是每种语言，不是每种框架，不是每种类型系统，而是关于软件本身的一些事情 在我看来，与您可能拥有的任何其他可能的技能相比，这似乎是一项更有益的技能 我希望这可以鼓励你在你的软件中努力学习和努力工作，并且也有一些信心，即使我们在编写代码这件事情本身上完全被淘汰，我们正在学习的很多内容都非常有用，并可以转移到其他领域 附录Appendices 原视频

使用go test -cover的时候发现了一个很有意思的事情，如果被测试函数有 coverage: xxxxxx 这样的对stdout的输出，那么对应的测试里，最后输出的 ok xxxxxx yyyyys coverage: X% of statements 中，coverage会被覆盖 谷歌没搜到答案，直接抠Go源码 这个out是buf的Bytes，通过写入，关键是coveragePercentage这，居然是个非常粗暴的正则匹配 导致了这种被hack的结果