Bash脚本15分钟进阶教程
这篇教程源自谷歌内部广受欢迎的“Testing on the Toilet”材料，系统梳理了编写健壮、可维护的Bash脚本的进阶技巧。它从脚本安全的开篇三行代码讲起，解释了如何通过`set -o nounset`和`set -o errexit`来避免引用未定义变量和忽略执行失败这两个常见坑点，并指出了其例外情况。 文章的核心在于提升代码质量。它强调了函数在增强可读性和结构化方面的作用，并推荐将大部分代码封装其中。在变量处理上，提倡善用`local`和`readonly`注解来明确作用域和防止意外修改。此外，教程对比了几种Bash语法：推荐用更清晰、不易混淆的`$()`替代反引号，以及用功能更强大的双中括号`[[]]`替代单中括号`[]`进行条件测试，并列举了后者在字符串比较和逻辑运算上的优势。 整篇文章没有空泛的理论，而是通过具体代码示例，直接提供了能立刻用在生产脚本中的最佳实践，帮助读者从“能跑就行”迈向编写更专业、更可靠的自动化脚本。
让安卓手机通过代理翻墙的方法
这篇讲的是作者为解决小米3手机无法连接Google Play商店的问题，摸索出的一套安卓手机代理翻墙方案。作者的电脑一直通过PuTTY连接海外主机建立的SOCKS v5代理正常上网，他尝试让手机通过同一局域网内的这个代理上网，却发现只有Dolphin浏览器成功，谷歌Play商店等大量应用依然无法连接。 问题的根因在于，部分安卓系统应用和商店无法识别纯SOCKS代理。作者最终找到了DeleGate这款开源工具，用一行命令将电脑上的SOCKS代理转换为HTTP代理。具体方法是在电脑端运行指令，将本地7070端口的SOCKS代理映射到8080端口的HTTP代理，然后在手机WLAN的代理设置里指向电脑IP的8080端口。 验证效果是，完成这个转换后，手机上所有应用都能正常联网，谷歌Play商店恢复了应用下载和更新功能。文章记录了从遇到问题、排查到最终找到可行解决方案的完整折腾过程。
如何对待开发团队中那个拖后腿的人？
这篇讲的是团队中相对弱势的成员如何成为检验团队文化健康度的试金石。作者从自己多年参与不同团队的经历出发，分享了一个观察：优秀的开发团队往往都有一个“垫底”的成员，但关键不在于这个人的能力短板，而在于团队其他人如何对待他。 文章用了一个生动的例子——在作者曾参与的志愿者团队中，有个叫Elliot的成员。他热心却总是把事情搞砸，没人会把关键任务交给他，但所有人都体谅他，帮他融入并贡献自己的力量。团队会私下叹气，但绝不容许外人欺负他。作者指出，这种相互尊重与包容的氛围，恰恰是团队和谐与高效的标志。 相反，在不和谐的团队中，类似的成员容易被孤立和轻视，这会带来负面影响。文章认为，如何对待团队里“那个Elliot”，直接反映了团队的文化与领导力。商业组织和开源社区都能从中获得启发：关注成员间的互动方式，有时比单纯追求个人技术能力更能决定一个团队的长期健康与凝聚力。
程序员的复仇方式
这是一篇充满极客幽默的技术复仇实录。故事背景很简单：作者总被公司一位擅长“防守”的同事捉弄，于是决定利用对方不太懂电脑的弱点，发起一场悄无声息的技术反击。 作者的核心武器是一些轻巧却诡谲的脚本与命令。他趁同事离开时，在其Mac电脑上部署了远程访问密钥，并植入了一段Shell脚本。这个脚本会让电脑随机间隔、用低沉的语音悄声说出字母“i”（我），制造灵异感。更妙的是后续升级版脚本，它能主动调高电脑音量播放“i”，随后立刻静音，即便对方在听音乐也会被诡异打断。 但这只是开始。作者还远程执行了 `open` 命令，让对方电脑不断打开一个怪异的网页；偷偷将同事桌面上待评审的所有照片，替换成一张老人打瞌睡的滑稽图片。终极一击是预设了一个AppleScript，在电脑发出怪声前，桌面会瞬间闪现一张经典的恐怖动画图，然后再恢复正常。整个系列操作环环相扣，充分展现了命令行与脚本在“非技术用途”上的惊人灵活性。 文章的魅力在于，它将枯燥的Shell、AppleScript命令融入了一个具体的、充满张力的生活化叙事中，读者能清晰看到每一行代码带来的戏剧性效果。作者在结尾的“求助”也为这场技术复仇增添了互动与开放的余味。
教你如何在Windiws平台上创建以点(.)开头的文件名
Windows系统有个小脾气：当你想创建像.gitignore这样以点开头的配置文件时，如果直接输入文件名，系统会弹出“文件名不能以点开头”的错误提示。这给需要管理隐藏配置文件的开发者带来了困扰。 这篇教程分享了一个非常巧妙的解决方法：在命名时，在期望的文件名（例如.gitignore）末尾**再添加一个点**，将其输入为“.gitignore.”。这样，文件就能成功创建，并且系统会自动识别并保留真正的“.gitignore”这个文件名。这个技巧利用了Windows文件命名规则中的一个小盲区，虽然简单，却有效解决了实际问题。 需要注意的是，这个方法在Windows资源管理器中操作有效，但更适合需要看到文件扩展名的程序员用户。对于普通用户，通常可以通过命令行或其他方式达到目的。这个小技巧体现了在技术实践中，有时绕过表面限制、理解系统底层行为，能找到意想不到的简便解法。
在程序员的眼里，用户是这样使用他们开发的软件的
这篇讲的是程序员与普通用户之间那条意想不到的认知鸿沟。作者从程序员的视角切入，描述了当用户“另辟蹊径”使用他们开发的软件时，程序员眼中那种既好气又好笑的场景。 文章举了两个生动的例子：客户找不到桌面的IE图标，只会说“大e不见了”；另一位客户则在页面上找不到他想要的搜索，其实他需要的只是浏览器自带的Ctrl+F功能。这些真实案例凸显了一个核心矛盾：程序员容易高估用户对软件的掌控能力，同时低估了自己所构建逻辑的复杂度，最终导致自认为完美的程序在用户手里变得“极其难用”。 不过文章也指出，尽管过程充满挫折，但用户的满意正是程序员成就感的来源。文中穿插的多幅幽默图片，形象描绘了用户使用软件时的懵懂与程序员视角下的“灾难现场”，让整个讨论在调侃中不失共鸣。 最后，文章延伸到了与程序员沟通的实用建议：因为他们对逻辑因果极其敏感，与他们对话最好遵循清晰的“If…Then…Else”结构，主语明确，以免产生误解。整篇文章既是一次对“开发者思维”的幽默解构，也提醒着所有技术从业者：理解用户的局限性，是打造好软件不可或缺的一课。
如果代码审查时你忘记了拿近视眼镜
这篇讲的是代码审查中那些破坏可读性的常见“坏味道”。作者用了一个有趣的比喻：当你忘记戴近视眼镜时，看代码就只能依赖整体的“形态”和“结构”。这恰恰点出了代码审查的本质——我们有时需要暂时忽略实现细节，去审视代码的骨架是否健康。 文章通过六个生动的代码片段示例，具体演示了哪些设计会让“模糊的你”一眼就觉得不对劲。比如，把 `UserCreator` 的职责过分简化，导致创建一个简单的对象都需要在一堆小文件中寻觅；或者反其道而行之，让一个类塞进太多无关的方法，伪装成一个“全能”类。再比如，方法被拆得过于碎片化，使得逻辑追踪令人头疼；以及命名空间嵌套深达六层，让代码定位变得曲折。 作者指出，这些做法虽然在技术上可能“能运行”，却为人脑的理解设置了不必要的障碍。一个拥有8个参数的方法、一段需要长篇注释才能理解的逻辑，都在无声地增加协作与维护的成本。 最终，文章的落点在于：清爽、简洁、结构良好的代码是高效团队协作的基石。忽视代码的“可读性设计”，无论初衷多么良好，终将反噬项目本身。
给代码多留一些空间
这篇文章探讨了代码格式中一个看似微小但影响深远的细节——空格的使用。作者从观察到不同团队编码规范差异入手，对比了括号内外不加空格的常见紧凑风格，与括号、花括号内侧统一留空的宽松风格。他并未简单评判优劣，而是引发思考：在开源项目（以Ceylon语言为例）缺乏统一规范时，混乱的风格混杂是否会真正影响代码的可读性与协作效率？ 作者将代码格式与经过数千年演进的普通文字书写规范进行类比，指出在符号两侧保持空格，能让代码阅读更接近自然语言的认知习惯。文章的核心观点在于：虽然团队可以基于成员习惯或开源社区影响选择具体风格，但一套统一的格式规范至关重要。最后，作者结合IDE自动格式化的便利，强调有意识地多使用空格，是提升代码长期可维护性与阅读体验的简单而有效的实践。
使用Node.js、Twilio实现手机控制门锁
这篇教程解决了一个很实际的场景：忘带钥匙或需要远程为访客开门时，如何用手机控制家里的门锁。作者从自己在Makerland大会的演讲出发，手把手展示了一套不需要破坏原有门锁的DIY方案。 硬件核心是使用Arduino Uno微控制器驱动一个伺服电机，再通过物理结构（比如纸板和胶带）将电机的转动与门锁的旋钮联动起来，实现开锁与闭锁的机械动作。软件层面则构建了一个完整的通信链路：Node.js脚本通过Express框架搭建本地Web服务，利用Twilio API接收特定号码发来的短信指令；随后，脚本再通过串口通信向Arduino发送控制信号，驱动电机完成操作。整个系统通过ngrok实现内网穿透，让外网的Twilio能够访问到你的本地服务。 文章最巧妙的地方在于，它清晰地拆解了从物理组装到软件集成的全流程，让一个听起来有点科幻的想法，变成了一个有具体零件清单、接线图、代码示例的可复现实验。对于喜欢折腾硬件和Node.js的开发者来说，这是一个将软件能力延伸到物理世界的小而完整的范例。
no no no. 不要使用kill -9
这篇文章直接警告程序员不要滥用 `kill -9`。Perl 语言专家 Randal Schwartz 用“不要用收割机来修剪花盆里的花”来比喻，指出强制发送 SIGKILL 信号会粗暴地终止进程，使其完全丧失清理现场的机会。 具体来说，进程将无法关闭网络连接、删除临时文件、通知子进程或重置终止状态。这就像强行中断一场手术，可能会留下损坏的文件或系统状态不一致，为后续运行埋下隐患。文章强调，正确的做法是优先发送更温和的 SIGTERM（kill -15），给进程一段处理善后的时间。如果它无响应，再考虑发送 SIGINT（kill -2）或 SIGHUP（kill -1）。只有在确认程序本身存在严重缺陷、完全无法响应时，才应该使用 kill -9 这最后手段。 对于那些“卡住”的进程，文章建议先使用 `strace`、`ltrace` 或 `gdb` 等工具诊断其卡死原因，而不是直接“处决”。其核心观点是，通过信号与进程协作，是系统稳定性和可维护性的基础；粗暴地“一杀了之”恰恰掩盖了程序本身可能存在的问题。
如何用“友好”的方式告诉经理：拥有一个好程序员是你的幸运？
这篇讲的是程序员与管理者在“工作时间”问题上可能产生的典型冲突。作者从一个真实案例出发：一家小公司的新经理，要求资深程序员必须严格坐班8小时，而这几位程序员恰恰是公司业务的核心支柱，并习惯于灵活安排时间。 文章没有鼓吹对抗，而是提供了一套“友好”的沟通策略。其核心观点是，有效的沟通始于理解对方立场。在提出自己的诉求前，先询问并理解经理推行新规的真实动机——是来自上级压力，还是对管理失效的焦虑。随后，在表达时应使用“我感觉这种变化有点突然”这样的句式，以寻求折中方案的姿态，代替直接的最后通牒。最终，无论结果如何，都应尊重对方的管理权威。 作者认为，这种将心比心、避免情绪化的沟通方式，比单纯强调个人贡献或以离职相威胁，更能争取到有利的协作空间。它提醒技术从业者，高超的沟通与共情能力，有时和专业技能一样重要。
如何向外行人解释什么是内存溢出
这篇文章用了一个生活化的比喻，解释计算机中一个抽象但危险的概念——内存溢出。 作者没有堆砌术语，而是虚构了一张“欠款清单”和一支“神奇的铅笔”。清单就像计算机内存，记录姓名和欠款金额；铅笔的“自动擦除”功能，则巧妙地模拟了内存覆写的机制。当你新写入的数据（一个超长的名字）超出了预定空间（姓名栏），它并不会停止，而是“溢出”到了相邻的数据区（欠款数额栏），覆盖了原有的信息。这就是内存溢出的本质：程序将数据写到了它不该去的内存位置。 这个比喻的巧妙之处在于，它把原本需要想象电子信号的故障，变成了看得见的书写错误。更进一步，它直观地展现了溢出的后果：清单（内存）中的数据（欠款数额）被破坏，最终导致你还了一笔离谱的巨额欠款——在现实中，这可能意味着程序崩溃、数据错乱甚至安全漏洞。 对于想理解底层原理的读者，尤其是非技术背景的朋友，这个比喻提供了一个非常直观的认知锚点。它说明了为什么一个看似微小的编程疏忽，会在系统层面引发严重的连锁反应。
关于程序员的59条搞笑但却真实无比的编程语录
这篇整理了59条来自行业先驱与匿名程序员的经典编程语录，主题横跨开发生活、软件设计、调试纠错到产品交付。它并非技术教程，而是一次对程序员共同经历与职业哲学的幽默盘点。 从“过马路要往两边看”的谨慎，到“软件就像做爱，一次犯错，你需用余生维护”的犀利比喻，这些语录用自嘲的方式道尽了行业的真相。比如比尔·盖茨说“按代码行数评估进度，如同按重量评估飞机建造”，直指项目管理的荒谬；而“拷贝-粘贴是一种设计错误”则严肃提醒着代码质量的重要性。 文章的价值在于，这些段子与警句并非单纯搞笑。它们凝练了无数项目中的血泪教训与智慧闪光，比如对“未注明的功能特征”（即bug）的经典辩解，或是对“理论与实践差异”的精辟总结。对于从业者而言，阅读过程会不断产生“太真实了”的共鸣，仿佛与一群懂行的老友会心一笑，同时也能在笑声中反思自己的开发实践。
防止表单重复提交的几种策略
这篇讲的是多用户Web应用中一个经典问题：表单重复提交。从用户误点两次按钮、刷新页面，到使用浏览器前进/后退，甚至网络层的重复请求，都可能导致同一数据被多次处理，带来数据不一致或资源浪费。 文章梳理了四种常见的应对策略。前端层面，可以暂时禁用提交按钮，但这依赖客户端JavaScript，不够稳健。更推荐的做法是采用Post/Redirect/Get模式——提交后立即重定向到结果页，从根本上避免刷新或回退带来的重复提交。后端控制上，可以在session中为每次生成的表单嵌入一个一次性令牌，服务器处理时立即核验并删除，这是一种结合了安全考虑的有效方案。最后，从数据源头兜底，在数据库层面设置唯一约束或索引，确保即使重复数据到达也能被拦截。 这些方法各有侧重，从用户交互、请求流转、会话状态到数据存储形成了多层次的防御。实际开发中，往往会根据应用的安全要求和复杂度，选择组合使用这些策略。
程序员的18个有趣的事实
这是一篇充满黑色幽默与职业共鸣的程序员文化观察。作者从开发日常中提炼出18条令人会心一笑的“真理”，精准捕捉了程序员群体在自嘲中展现的独特智慧。 文中的事实从多个角度切入：有对版本迭代的幽默解构（“如果第一次运行不成功，那就叫它1.0版吧”），有对bug的哲学化开脱（“那些只是开发出来的随机的功能特征”），还有对编程本质的尖锐洞察（“编程是10%的科学，20%的创造力，和70%的让这创造力符合科学”）。这些看似玩笑的语句，实际映射着调试的挫败感、对完美的执着、以及咖啡与代码间的生化反应。 文章没有停留在单纯的趣味列举。它像一面镜子，照见了程序员在理性框架下的感性挣扎：既抱怨被用户“不够友好”地对待，又承认自己或许“没有源代码”去改变世界；既明白代码错误需用一生维护，又依然享受着编译通过瞬间的纯粹快乐。这种矛盾恰恰揭示了这个职业最真实的核心——在严谨的逻辑系统中，依然保有鲜活的人性与创造力。 读罢这些事实，你或许会笑，但更会思考：在那些看似怪诞的幽默背后，藏着多少深夜调试时的心照不宣，又定义着怎样一种用逻辑丈量世界的浪漫。
十种更好的表达“你的代码写的很烂”的方法
如何指出代码质量问题是许多技术团队避而不谈的尴尬。直接说“你的代码很烂”可能引发对抗，而沉默或抱怨又无法解决问题。这篇文章正是从这个常见的协作困境出发，提供了十个具体、可操作的沟通策略。 作者并非空谈理论，而是结合了iOS开发者Tim Burks、Adobe研究员Tom Jacobs等业内人士的实践智慧。这些方法的核心思路是将“批评”转化为“协作邀请”。例如，“开门见山”法不是指责，而是诚恳地请求对方帮你理解代码逻辑；“糖衣炮弹”法则在提出改进点前后，先肯定代码中值得学习的部分；“偷换概念”法通过改变主语（如“我需要重构这段代码”而非“你写得乱”），有效降低对方的防御心理。 文章最实用之处在于，它揭示了所有这些技巧的共同点：将对话焦点从评判“人”转向优化“代码”本身。无论是通过非正式的啤酒聊天来理解对方的编码习惯，还是通过组织编程大赛来营造安全的讨论氛围，目标都是让代码质量提升成为团队共同追求的目标，而非个人之间的对错之争。对于任何需要进行代码评审或团队协作的开发者，这些沟通心法都值得借鉴。
Python语言的创始人解释为什么Python数组的索引从0开始
Python的创始人自己解释了，为什么Python选择从0开始索引数组，而不是像一些语言那样从1开始。 这个问题源于Twitter上的一次提问。他回顾了对Python有重要影响的几种语言：ABC语言（Python的祖先）使用1-based索引，而C语言使用0-based索引。他自己最早接触的语言如Algol和Fortran等则各有不同。 最终决定采用0-based索引的关键原因，是Python切片语法的优雅性。在0-based索引下，`a[:n]`可以清晰地表示“取前n个元素”，`a[i:i+n]`表示“从第i位开始取n个元素”。而在1-based索引下，要表达同样的“取n个元素”操作，就需要繁琐地写成`a[i:i+n-1]`，或者改用不直观的`起始索引+长度`的表达方式。 这种设计还带来了一个巨大的好处：当进行连续切片时，索引能够自然衔接。例如，要将数组在`i`和`j`两处分割成三部分，可以非常优雅地写为`a[:i]`、`a[i:j]`和`a[j:]`。切片的终点恰好是下一段的起点，无需做任何调整。 这种对语法简洁性的追求，深刻影响了Python日常编码的体验，让数组和列表的操作直观而富有美感。
代码审查不是用来……
这篇文章讲的是代码审查在实践中常被误用的几个典型姿势。作者从自己公司的长期实践出发，总结了四个容易让代码审查变味的陷阱。 首先，别把代码审查当成控制代码的流程关卡。在团队内部，信任比强制审批更重要，流于形式的审查只会引发抵触。其次，它不该是追究责任的审判厅，揪出某个审查者来背锅会彻底摧毁团队的信任。第三，不要将其变为程序员必须完成的枯燥任务，这会扼杀其作为学习与交流机会的乐趣。最后，对代码的批评应当对事不对人，避免演变成互相讽刺的人身攻击。 文章指出，代码审查的真正价值在于促进学习、获得反馈与团队交流。作者通过具体场景描述了这些误区如何发生，旨在提醒团队避开这些坑，让审查回归提升代码质量与团队协作的正途。
代码重构方向原则指导
这篇讲的是，当代码重构没有像“消除代码异味”那样现成的、明确的方向时，开发者可以遵循哪些具体的原则来指导决策。作者将重构比作爬山，指出在缺乏明显路径时，我们常陷入罗列更多“坏味道”模式的讨论，却鲜少给出建设性意见。 文章的核心价值在于提供了一套清晰的重构决策清单。它首先厘清了重构的两个基本方向：通过“归纳方法”分解组件以实现复用，或通过“内联方法”消除琐碎函数。随后，针对“如何知道哪种方法是正确道路”这一编程艺术中心问题，作者直接抛出了17条可操作的原则。 这些原则极具针对性，例如：偏向用多态（多形）替代switch语句；不确定时优先使用组合而非继承；用guard语句和封装来简化条件逻辑；甚至建议尽量将代码逻辑放在model层而非controller层。这些指导超越了简单的“代码整洁”，直指提升代码可维护性、降低耦合的工程实践。对于在重构中感到迷茫的开发者，这份清单提供了一张值得参考的路线图。
Linux内核代码中的脏话统计
这篇讲的是作者从一个已停更的“the linux kernel fuck count”项目获得灵感，对Linux内核的C、H及汇编源代码进行了一次系统的脏话统计分析。作者按版本号，分别从脏话的绝对数量和代码行的脏话密度两个维度绘制了图表。 数据呈现了一个有趣的趋势：从2.4版本开始，脏话的绝对数量显著攀升。然而，考虑到同期内核代码总量也在激增，折算下来，平均每行代码的“脏话密度”反而是在下降的。文章坦诚地分享了统计方法的局限，比如会将词中包含的词也计入，以及受FreeBSD正则引擎内存泄漏的影响未能优化。 作者最终开源了统计脚本，但也自嘲其代码质量混乱。这本质上是一次用独特视角审视开源社区文化的趣味实践，既看到了开发者情绪的外露，也反映了代码库膨胀带来的稀释效应。
