关于开源，关于 GitHub, 关于 Android
这篇讲的是作者从Android与GitHub的并行增长出发，对开源生态与实践的思考。他通过两组2007-2013年的增长曲线，直观展示了移动设备爆发与GitHub繁荣的潜在联系，并调侃Android开发者因开源而更“幸福”。 基于此，作者重点分享了如何“用好”开源项目。他提出了一个针对Android库的协作分析项目，并给出了具体的选型标准：必须谨慎对待GPL协议，理解库的实现原理是使用前提，同时需考察功能、文档、稳定性与扩展性。对于源码修改，他强调应尽量采用包装方式，若必须修改则务必回馈社区，让代码保持在开源的“大陆”上，而非变成“孤岛”。 文章最后还总结了一个优质开源项目应具备的要素，如规范的README、清晰的协议声明和便捷的联系方式等。整体上，这不是一篇空谈理论的文章，而是一位实战派开发者关于如何选择、使用乃至回馈开源项目的经验谈。
从 Nginx 默认不压缩 HTTP/1.0 说起
这篇讲的是，Nginx 默认只为 HTTP/1.1 启用 GZip 压缩，而对 HTTP/1.0 请求关闭压缩，这背后并非配置疏忽，而是 HTTP 协议特性在服务端实现中的一个关键权衡。 文章从移动端异常高比例的 HTTP/1.0 流量这一现象切入，深入剖析了原因。Nginx 默认采用即时压缩（On-The-Fly Compression）以优化首字节时间，但这导致无法预知响应大小，无法设置 Content-Length。在 HTTP/1.0 中，没有 HTTP/1.1 的 Transfer-Encoding: chunked 分块传输机制，客户端只能依靠 Content-Length 或断开连接来判断结束。因此，Nginx 为了在 HTTP/1.0 上尽可能保持持久连接（keep-alive），默认选择了放弃压缩。一旦启用 HTTP/1.0 压缩，Nginx 就只能返回 Connection: close 来结束传输。 文章通过对比测试验证了这一机制，并给出了务实建议：对于动态内容（如 PHP 输出的 HTML），因其本身无法预知大小，不妨启用 GZip 以节省流量；对于可预知大小的静态文件（JS、CSS），则建议将关键资源内联，非关键资源用外链并启用压缩，接受连接断开以换取流量节省。一个看似简单的 Nginx 配置，背后其实是 HTTP/1.0 与 1.1 在协议能力上的深刻差异。
git diff(merge) with beyond compare
这篇讲的是如何在Mac上将Beyond Compare配置为git的差异对比和合并工具。作者从实际需求出发，指出了一个常见问题：macOS版本的Beyond Compare默认并未安装命令行工具，这使得它无法直接被git调用。文章详细说明了通过特定方式安装命令行的过程，并解释了生成的 `bcomp`（等待操作完成）和 `bcompare`（立即返回）两个命令的区别。 核心内容聚焦于git difftool的配置。作者梳理了git支持的各类图形化diff工具列表，并分析了其中 `bc`（即Beyond Compare）与 `bc3` 的关系，指出git虽内置这些工具的配置，但需在图形环境下才能正常工作。文章通过实例，如 `git difftool -t vimdiff` 的指定方式，以及使用 `-x` 选项自定义命令的技巧，展示了配置的灵活性。最终，读者可以借助这些步骤，将强大的Beyond Compare无缝集成到自己的git工作流中。
Mac实用技巧——在Finder中显示文件完整路径
这篇讲的是一个让Mac Finder显示文件完整路径的实用技巧。在默认设置下，Finder只会在标题栏显示当前文件夹的名字，而不会显示完整路径，这给需要频繁导航多层目录的用户带来了不便，尤其是在处理复杂项目文件时，常常需要反复点
securecrt linux与windows 互传文件
这篇讲的是如何用SecureCRT自带的sz/rz命令，来替代传统FTP/SFTP工具进行Windows与Linux间的文件互传。作者开篇就点出了常见方案的痛点：FTP/SFTP工具操作繁琐，尤其在目录层级较深时体验不佳。 文章的核心是介绍sz（下载）和rz（上传）这对命令。通过具体配置和代码示例，它展示了如何先在SecureCRT中设置默认的传输目录，然后直接使用`sz 文件名`将Linux文件下载到指定本地路径，或使用`rz`弹出窗口选择本地文件上传到Linux当前目录。整个过程不需要启动额外客户端，直接在终端里就能完成。 不过，文章也坦诚地指出了局限：sz/rz对于小文件传输非常便捷，但传输大文件时速度会比较慢。因此，这个方案特别适合那些需要频繁、快速交换中小型文件的运维或开发场景，能显著提升工作效率。
初入运维的小伙伴，别再问需不需要学Python了
这篇讲的是运维人员该不该学Python的老话题。作者从百度知道上一个常见的提问切入，观点很明确：掌握一门开发语言，尤其是Python，已经是高级运维工程师的必备技能。 文章认为，不会开发，就难以深入理解业务流程、优化性能，也无法在复杂场景（如数千台服务器）中实现真正的自动化运维，只能依赖通用工具或拼凑开源软件。而Python恰好能胜任，它既是强大的脚本语言，满足绝大部分自动化需求，又能用于开发后端的C/S架构和Web界面，让运维人员有能力构建自己的运维平台，从而体现核心价值。 作者也对比了其他语言。比如，PHP更专注于Web；Java显得臃肿；C++在运维场景中多数时候“是为了来装B的”；而Go语言虽新，但预计不会成为运维开发的主流。同时，针对“Python效率低”的说法，作者指出程序效率更取决于开发者本身，并以Tornado框架在Python下实现高并发作为例证，强调语言本身的影响只占一部分。 文章的核心结论是：别再纠结“需不需要学”，Python因其简洁、全面和生态优势，就是运维转向开发、提升竞争力的首选工具。
开启命令行下的社交
这篇文章记录了作者将社交工具搬到命令行终端的一次有趣实践。作者近期沉浸于命令行工作环境，尝试脱离图形界面，探索如何在终端中处理即时通信需求。 核心部分介绍了开源项目 Mojo-Webqq 的安装与使用。这是一个基于 Perl 的非 GUI 框架，能作为 SmartQQ/WebQQ 的命令行客户端。文章详细列出了在 Mac 上通过 cpanm 安装的步骤，以及如何配置一个基础脚本启动 QQ 登录并搭建本地 HTTP 服务，从而通过 curl 等命令实现消息的收发，为 QQ 消息的自动化处理提供了接口基础。 此外，作者还回顾了使用命令行 IRC 客户端（如 Weechat 和 irssi）的经历。文章比较了两者在安装和中文支持上的差异，并分享了通过 `/help` 命令探索使用、配置服务器连接和频道加入的入门路径，展现了 IRC 这个经典技术交流平台在终端下的独特魅力。 整体而言，文章从个人工作流的转变出发，具体演示了如何用工具和脚本在命令行中搭建社交桥梁，为希望摆脱图形界面束缚的开发者提供了一种可能。
页面跳转时，统计数据丢失问题探讨
这篇讲的是前端埋点统计中一个让人头疼的常见问题：页面跳转或关闭时，关键统计数据（如链接点击、停留时长）还没来得及发送就丢失了。作者从这个痛点出发，梳理了工程师们惯用的几种“阻塞”浏览器关闭的黑客方案（如同步Ajax、死循环、图片请求），并指出了它们在兼容性和用户体验上的硬伤。 文章真正的亮点在于提出了一个思路转换：既然在当前页面发送如此困难，不如将数据交给下一个页面去发送？由此引出了通过URL传参或利用`window.name`特性将数据跨页传递的方案。但作者也坦言，这依赖于开发规范和系统环境的统一。 最终，文章将解决方案推向了更高层面——这本应是浏览器原生能力。它介绍了W3C提出的`Beacon API`，其异步、不影响页面卸载的特性完美解决了上述所有痛点，尤其是在移动端场景下，即使用户切换应用，数据也能可靠上报。整个探讨过程从具体问题到变通方案，再到标准解，清晰展示了技术演进的逻辑。
2015年版阿里云ECS服务器使用总结（与aws比较）
这篇讲的是国内云服务商阿里云和亚马逊AWS在服务器产品上的直接较量。作者从价格、稳定性、速度等多个维度进行了详细对比。 价格上，阿里云包月实例比AWS同配置便宜约40%，但AWS的预留实例方案可将价格拉平。稳定性方面，AWS整体表现更可靠，而阿里云则以超快的工单响应和给力的客服支持取胜。 速度测试是文章的重点。通过实测发现，阿里云1Mbps带宽下载速度约42-60KBs，但属于共享带宽，并发能力弱；AWS带宽上限更高，下载速度可达900KBs且不受影响。连接时间上，阿里云杭州节点（约280ms）明显优于北京节点（约2000ms），甚至快于AWS东京节点（约140ms）。 在服务与备案等本土化体验上，阿里云具有明显优势。文章最后给出了务实的选择建议：对于需要全栈云服务的国内创业团队，阿里云已能满足基本需求；而追求更成熟技术架构的团队，可继续关注AWS中国区的发展。
Macbook Air换电池教程
这篇教程源自作者亲身体验：一台2012款Macbook Air使用三年半后，电池从最初五六小时的续航暴跌到仅一小时，最终插电能显示充满但拔电即关机，确认电池彻底老化。 为避免官方维修的高成本，作者决定自行更换电池。在淘宝上找到匹配型号的绿巨能品牌
小谈矢量网络
这篇讲的是 Figma 团队如何重新思考并改进了诞生三十多年的矢量编辑工具。作者从自身游戏开发背景出发，指出传统基于“路径”的钢笔工具在交互上存在诸多反直觉的限制。为此，Figma 提出了“矢量网络”这一新模型。 与路径的单一链条不同，矢量网络允许任意两点之间自由连接和分割，极大提升了形状编辑的灵活性，甚至对用户而言是“无缝”的体验。文章还分享了其他关键改进：弯曲工具允许直接拖拽曲线而非仅靠控制柄，符合直觉；同时，Figma 的填充算法摒弃了传统复杂的“卷绕数”概念，通过智能识别封闭区域并提供油漆桶工具一键开关，让填充操作变得直观。这篇文章揭示了如何通过底层模型的创新，让基础设计工具变得更自然、更强大。
手滑的故事
这篇讲的是程序员们“手滑”引发的线上惊魂时刻。作者从自己和同行的经历出发，提到了忘带WHERE条件的UPDATE和DELETE、误执行`rm -rf`，以及误杀重要的线上Hadoop任务、误删生产文件等真实案例。那些操作失误后瞬间“浑身颤抖”的体感，相信很多工程师都似曾相识。 文章不仅罗列事故，更着重讨论了事后反应的光谱：从最糟糕的当众批评、追责到底，到更理性的对外冷处理、对内聚焦问题根因而非个人。作者认为，责任主体往往已懊悔万分，过度追责反而导致“不做不错”的消极心态；而复杂的Checklist或繁琐的审批流程，也只是笨拙且降低效率的补救。 他更推崇那些“不知不觉”规避风险的实践，例如建立不同权限的Linux用户，以及做好充分的备份与容错机制。核心观点是：在系统维护中，人远不如机器可靠。与其纠结于事后惩处，不如构建鼓励坦诚报告、聚焦系统性改进的工程文化，因为“没有手滑的人生，是不完整的”。
程序员如何写出一份好的文档？
程序员的工作不止是写代码，文档质量同样影响项目协作效率。这篇经验分享文章直接切入痛点，从四个实用技巧出发，教你如何写出清晰、易懂的技术文档。 作者首先强调了结构化的重要性——杂糅的信息会变成“云里雾里”，而将功能点逐条列出，逻辑立刻清晰。其次，对于socket通信这类流程性内容，一张流程图比大段文字更直观，读者能迅速把握整体逻辑。第三，当涉及连续的数据对比（如每月bug修复量）时，用图表替代文字描述，数字变化一目了然。最后，避免直接堆砌代码，转而使用伪代码或流程图来说明设计思想，能显著降低阅读门槛，让文档更具普适性。 这些技巧的核心，正如文中引用爱因斯坦的话，都指向一个原则：简单就是美。好的技术文档也应如此，用最直接的方式传递信息，让读者轻松理解复杂的内容。
教你如何查询当前主流数据库及其排名？
查询数据库流行度排名有捷径吗？作者直接指向了db-engines.com这个权威榜单。这篇文章带我们快速浏览了2015年6月的数据库流行度前十名，像Oracle、MySQL、SQL Server这些巨头稳居前列，但有意思的是，微软的Access依然高居第七，让不少开发者感到意外。同时，Redis作为新贵闯入了前十，而国产的巨杉数据库排名则从186位滑落至235位，引发了讨论。 榜单的排名并非凭空而来，它综合了277个数据库在资讯网站、谷歌搜索、技术讨论、招聘市场以及社交网络上的热度数据。通过这些多维度的积分统计，这个榜单真实反映了当时各类数据库在开发者社区和行业中的实际关注度与应用情况。对于需要了解数据库技术趋势或进行技术选型的人来说，这提供了一个非常直观的参考视角。
2015中国程序员生存报告，请勿对号入座
这篇发布于2015年的文章，以一份“不负责任”的报告形式，用幽默甚至自嘲的笔触勾勒了当时中国程序员的群体画像。文章起点是Stack Overflow的数据：全球软件开发者中男性占92.1%，而文章调侃道，剩下的女性比例里“一个姑娘也没给中国同行留”。 围绕这个背景，作者从几个切面展开了对“生存报告”的描绘：从性别比例失衡导致的社交硬伤，到对“猝死”话题的下意识警觉；从与“天敌”产品经理在像素级需求上的日常博弈，到对薪资增长靠跳槽、职业天花板无形的隐晦吐槽。文章甚至将“出路”话题引向了最终与产品经理“成为最熟悉的人”的无奈又好笑的结论。 它并非一份严肃的调查报告，而更像是一次基于行业共识的集体自嘲与情绪表达。这种“别对号入座”的标题，恰恰精准击中了程序员群体在高速迭代的技术压力与相对单一的生活环境中，所共享的、复杂又难以言状的生存状态。
SecureCRT怎么设置字符集编码及缓存
使用SecureCRT连接Linux终端时，中文字符乱码是个常见问题。这篇教程详细拆解了问题的根源和彻底解决的方法。 问题的根本原因在于字符编码不匹配。教程指出，只需将SecureCRT的默认编码设置为UTF-8，即可同时解决显示乱码和输入乱码两大问题。它提供了清晰的全局设置路径：从“Options”菜单进入“Global Options”，然后编辑默认会话设置，在“Appearance”选项卡中找到并勾选“Character encoding”为UTF-8。 除了编码，文章还顺带讲了一个实用技巧——如何调整回滚缓冲区大小。在同一个配置界面的“Emulation”部分，可以将“Scrollback buffer”从默认的500行调大，最大支持128000行，方便回溯更长的历史命令输出。 教程最后也提醒，上述修改会影响所有新建的连接。如果只想让某个特定会话生效，应该通过“Session Options”进行单独配置，这为用户提供了灵活的选择。
如何教会非计算机专业的女友写代码
这篇讲的是一个计算机专业男生如何系统指导金融专业女友转行前端开发并成功就业的完整经历。 作者从自身背景出发，为女友选择了适合入门且“可进可退”的前端方向，并制定了清晰的学习路径：从《Head First》系列和《JavaScript语言精粹》等书籍掌握基础语法，再通过言传身教渗透HTTP协议、网络通信等原理知识。他强调“工欲善其事”，专门为女友购置MacBook Pro以便熟悉Vim、Git等开发工具。 实践环节是关键。作者引导女友在GitHub写博客、开发小作品，并报名参加了筛选制的百度IFE前端技术学院。当基础扎实后，便鼓励她投递简历，通过面试发现不足，最终顺利获得实习Offer。过程中遇到的JS异步、闭包等难点，也被一一攻克。 文章还直面了两个常见偏见：技术是否适合女性，以及互联网行业是否过于繁忙。作者以实例论证，技术岗位对女生同样有吸引力且并不枯燥，互联网公司也存在灵活的工作选择。最后，他用自己的支持与担当，为这段转行之路画上了有温度的句号。
OS X 下好用的磁盘空间分析工具: ncdu
这篇讲的是在 OS X 下分析磁盘空间占用的两个选择：一个是界面精美但需要付费的图形化工具 Daisy Disk，另一个是免费、命令行风格的替代品 ncdu。 作者从不想为软件付费的“抠门”心态出发，找到了 ncdu 作为解决方案。文章将两者做了对比：Daisy Disk 用环形图直观展示空间占用，体验优秀；ncdu 则在终端运行，用键盘操作，是“命令行版的 Daisy Disk”，更符合极客口味，但扫描时不会智能跳过挂载点，需要手动添加排除参数。 文章的核心是提供了 ncdu 的实用指南：通过 `brew install ncdu` 即可快速安装。使用时，简单的 `ncdu ~` 可以分析个人文件夹，而扫描整个系统盘或外部硬盘时，则需要用 `ncdu / --exclude /Volumes` 这样的命令来排除干扰。 最终，作者认为两者各有适用场景：习惯图形界面的用户可以选择购买 Daisy Disk，而偏好命令行或预算有限的用户，ncdu 是一个高效且免费的得力工具。
开源项目的那点事
作者从近期重构CppJieba、发布NodeJieba的实践出发，分享了自己在开源社区中的几点切身感受与学习开源项目的方法。 他强调，一个重视用户体验的开源项目，往往从“简陋”但无依赖的轻量版本开始，例如他早期的CppJieba和ideawu的SSDB，都坚持不依赖第三方库以实现即装即用。在学习上，他建议开发者善于积累自己的代码片段，将小实验逐步组合成项目；同时也要“站在前人的肩膀上”，优先参考现有分析文档再阅读源码，避免低效硬啃。 作者提出了一个颇具启发性的观点：开源项目的学习价值并非由star数决定，而在于其与学习者当前工作的相关性及代码的可读性。他认为，阅读与自己领域相近、核心逻辑清晰的源码，更能带来实际灵感；而一味追求明星项目或高性能代码，有时反而因牺牲可读性而难以深入。 最后，他呼吁回归开源初衷——即知识的分享与传播，而非过分功利化。整篇文章将个人开发经历与开源学习心得紧密结合，对初入社区或希望提升源码阅读能力的开发者都有切实的参考意义。
excel打开csv文件乱码的解决方法
这篇文章讲的是许多人在用Excel处理CSV文件时都会遇到的“乱码”坑。作者从一个实际问题出发：一个用程序导出的TXT文件，记事本打开一切正常，但把扩展名改成CSV后，用Excel打开不仅汉字乱码，连数据分列都识别不了。 问题的根源其实很直接——编码不匹配。在简体中文环境下，Excel打开CSV文件时默认使用的是ANSI编码，而很多现代程序导出的文件则是UTF-8编码。当Excel试图用“旧地图”去解读“新文字”，乱码和列错位就发生了。 解决办法简单有效：用记事本打开这个乱码的CSV文件，通过“另存为”功能，将编码从UTF-8明确选择为“ANSI”，保存后再次用Excel打开，问题就迎刃而解了。文章不仅给出了“三步走”的操作方案，还顺带科普了ANSI、Unicode和UTF-8这几种常见编码方式的核心区别与适用场景，帮助读者知其然也知其所以然。对编码原理感兴趣的读者还能读到更深入的讲解。