采集自各技术站点的近期文章。
这篇讲的是如何从头实现一个JSON解析器。作者从JSON解析器的基本定义出发——即将JSON字符串转换为语言内存中的数据结构，对比了它与XML的差异，并梳理了JSON基本类型与Java数据结构（如Map、List）的映射关系。 文章的核心在于拆解实现思路。它强调解析器应采用流式单次扫描，本质是一个状态机。实现的关键步骤被清晰地勾勒出来：首先，需要封装一个`CharReader`来支持`peek()`操作，以便在不移动指针的情况下预判字符；其次，将原始字符流进一步抽象为Token流（如`BEGIN_OBJECT`、`STRING`等），从而大幅简化状态判断逻辑。最后，文章点出了处理嵌套结构的技巧：利用栈来管理Object和Array的构建，遇到开始标记时创建对应的Map或List并压栈，以此高效地完成递归解析。 整个实现过程体现了从具体到抽象、逐步化繁为简的设计思想，将看似复杂的解析任务分解为字符读取、Token识别和栈操作几个清晰的模块。
这篇讲的是如何为Nginx配置一个自签名SSL证书，来快速启用HTTPS安全连接。 在Web开发中，HTTPS几乎是保障浏览器与服务器通信安全的必选方案，但向证书颁发机构申请正式证书往往需要每年几十到几百美元的费用。如果只是为了内部管理或测试目的，自签名证书就能提供一个零成本的解决思路。 文章从SSL证书验证的两种模式切入，解释了为什么普通网站通常只验证服务器证书，并点明自签名证书的适用场景。核心方案部分，作者详细演示了利用openssl创建证书的四步流程：生成密钥、创建签名请求、移除口令并最终签名。为了简化操作，文章还提供了一个shell脚本，以域名www.test.com为例，展示了从运行脚本到输入口令的完整交互过程，以及生成的四个关键文件。 配置环节，文章明确指出Nginx需要加载证书和密钥文件的具体路径，并附上了示例配置。最后还提到一个实用技巧：让Nginx统一处理HTTPS，后端应用服务器只用HTTP连接，这样既发挥了Nginx在处理SSL方面的优势，也避免了其他服务器配置证书的复杂性。整个过程下来，即使是自签名证书，也能让管理员通过浏览器安全地连接到服务器进行维护。
这篇讲的是程序开发中一个极易被忽视却至关重要的陷阱：如何正确地存储和处理时间。作者从大多数开发者习以为常的“获取本地时间直接存库”这一操作切入，一针见血地指出了问题的核心——本地时间丢失了时区信息，一旦环境变更，时间数据就会错乱。 文章深入浅出地解释了时区的本质，并引出了“绝对时间”（即时间戳）的概念。作者强调，正确的做法是遵循“存储与显示分离”的原则：在数据库中只存储一个与时区无关的整数或浮点数时间戳。这样，无论服务器时区如何设置，存储的时间值都是全局一致的。显示时，再根据用户的时区将时间戳格式化为字符串。 这种方案带来的好处是根本性的：时间比较和筛选变成了简单的数值运算，彻底摆脱了时区转换的泥潭。文章通过Java示例清晰地展示了一个时间戳如何被正确格式化为不同时区下的本地时间，直观地证明了其有效性。对于任何需要处理国际化时间数据的开发者来说，这篇文章揭示的原理和提供的方案，都是避免未来无尽调试的必备知识。
这篇讲的是在现有网页中如何同时使用多个jQuery版本。文章从实际开发中的痛点出发：老项目可能依赖jQuery 1.5及一堆旧插件，但新功能又想用jQuery 1.11的特性，直接升级会导致旧插件失效。 作者介绍的基础方案是利用jQuery的`noConflict()`方法。通过在新版本导入后调用`var $jq = jQuery.noConflict(true);`，就能恢复页面上`$`和`jQuery`全局变量为旧版本，同时通过局部变量`$jq`来使用新版本，从而实现共存。 但作者指出，直接在页面写多行脚本容易出错（比如被误删或顺序颠倒）。因此，他提出了一个更健壮的封装方案：把自己的新脚本（比如`myscript.js`）写成一个匿名函数，并在其中直接嵌入新版jQuery的压缩源码。这样，脚本内部通过`noConflict`获取的新版jQuery会成为一个局部变量`$`，完全不受页面其他jQuery版本影响。最终，页面只需正确引入旧版jQuery和这个封装好的新脚本即可，实现了解耦与自治。 这个方案的巧妙之处在于，它把版本兼容的复杂性完全封装在一个独立的文件里，让主页面保持干净，也避免了其他开发者误操作的风险。
这篇讲的是 JavaScript 闭包在循环中一个经典的陷阱。作者从一个看似简单的需求出发：在一个 `for` 循环中创建三个函数，分别打印当前的循环索引。但实际执行时，所有函数都打印了同一个值——循环结束后的最终值。 问题的根源在于闭包捕获的是变量的引用，而非创建时的快照。循环变量 `i` 在所有函数中都是同一个变量，因此函数执行时读取的都是循环结束后那个值。即使尝试在循环内用 `var n = i` 复制一份，由于 JavaScript 缺乏块级作用域，`n` 的作用域依然是整个外层函数，最终也会被后续的迭代覆盖。 作者指出，这条“不要在闭包中直接引用循环变量”的原则，适用于所有函数式语言。正确的做法是创建一个新的作用域来捕获当前迭代的值。文章演示了两种经典方案：一是通过一个额外的函数（如 `function(n){...}`）将当前 `i` 作为参数传入；二是更简洁的立即执行函数表达式（IIFE），在循环体内 `(function(n){...})(i)` 就地创建一个新作用域并传递参数。 这本质上是一个作用域与闭包机制如何相互作用的深度理解问题。掌握这个模式，能帮开发者避免在异步回调、事件监听等场景下产生难以排查的 bug。
这篇文章的核心主张是：在代码审查中引入并维护一份“检查清单”，能系统性地提升发现缺陷的效率，从而消除更多潜在的bug。 作者开篇就指出问题的普遍性：软件工程协会的研究表明，程序员常犯的错误集中在15-20种。因此，如果在审查时依赖纯粹的个人经验，这些常见问题就很容易被遗漏。清单的作用，正是将这些高频错误固化下来，确保每一次审查都能覆盖到这些关键点。 文章提供了一份经典的清单模板，涵盖了从“总体”（代码功能、可读性、规范、冗余）到“安全”（输入输出校验）、“文档”和“测试”等多个维度的具体检查项。它强调清单不必大而全，应聚焦于团队实际发生的常见问题。 更关键的是，清单并非一成不变。作者建议团队在实际审查中记录遇到的问题，以此作为数据来优化自己的清单，剔除不相关的项目，加入特有问题。通过这种集思广益和定期更新的方式，清单会越来越贴合团队实际。 最终，一个经过优化的、具体的清单，能帮助团队在审查中稳定地捕获更多瑕疵，避免审查质量因人而异，从而实质性地提升代码质量。
这篇讲的是JavaScript中this关键字的工作原理，作者从开发者常见的困惑入手，揭示了this在不同调用场景下的行为差异。文章首先对比了函数作为对象方法调用和获取引用后调用的区别：直接调用时this指向对象本身，但提取方法后调用可能让this指向全局window，在严格模式下则变为undefined。接着，探讨了this在构造函数中的角色，使用new关键字时this指向新实例，否则可能意外指向全局对象。 文章进一步介绍了如何通过.call、.apply和.bind来主动操作this，提供了灵活的解决方案。.call允许传递任意参数并指定this，.apply则接受数组参数，.bind能永久绑定this并创建部分参数的函数。这些工具帮助开发者应对this的“脆弱”特性，避免常见陷阱。 在作用域链部分，文章指出this无法自动继承的问题，建议使用局部变量如var self = this或.bind来保留引用，确保在嵌套函数中正确使用。通过具体代码示例，文章澄清了this的复杂机制，让读者能更清晰地理解其在JavaScript中的角色，提升代码编写能力。
这篇讲的是JavaScript中一个经典且实用的性能优化技巧：函数的惰性载入。作者从实际开发中的常见痛点切入——为了处理浏览器兼容性，像`addEvent`这类函数内部常常堆满了`if...else if`判断，而每次调用都会重复执行这些检查，造成不必要的性能损耗。 文章的核心方案是，让这些只依赖环境的判断只执行一次。作者清晰地讲解了两种实现“惰性载入”的方式。第一种是在函数首次执行时，动态地重新定义函数自身，用更精确的版本覆盖原函数，后续调用就直接命中新函数。第二种则更为巧妙，在函数声明时通过一个自执行函数来完成环境探测并直接返回一个定制好的函数，虽然初始化时稍有开销，但后续调用完全无额外负担。 两种方法的共同目标都是避免重复的分支检测。文章最后指出，选择哪种方式取决于你的具体场景，是更看重首次调用的性能，还是初始化时的简洁性。对于需要频繁触发、且依赖环境检测的工具函数来说，这种“只判断一次”的思路能带来实实在在的效率提升。
这篇讲的是如何用纯CSS3“画”出一个七巧板。作者从项目需求出发，对比了Canvas、SVG等方案后，最终选择了更轻量、兼容性好的CSS3作为实现路径。 核心思路是用CSS的border属性来构建三角形、正方形和平行四边形这三种基本形状，再通过transform属性（包括translate、rotate、skew）将它们精确地平移、旋转和变形，拼合到指定位置。文章特别提到了利用CSS预处理器LESS，通过定义一个基础长度变量来控制整体尺寸，极大地提升了代码的可维护性和灵活性。 文中还包含了具体的代码片段和效果展示，甚至延伸到了使用CSS3动画让七巧板“动起来”的可能。它展示了前端如何用基础技术，实现一个充满趣味和传统文化味的小项目。
这篇讲的是为了解决前端调试中一个具体而恼人的兼容性问题——使用 `console.log` 等方法时，在旧版IE等浏览器下因 `console` 对象未定义而导致脚本报错。作者由此引出了一个名为 `console.js` 的微型解决方案。 核心方案是引入这个库来“修复”环境：它会在页面加载时检测并模拟出一个完整的 `console` 对象及其常用方法，使得后续代码无论浏览器是否原生支持都能安全调用，避免因调试语句影响线上功能。文章不仅展示了其简短的源码实现，还贴心地解释了代码开头那个分号的防御式编程技巧，防止文件合并时出错。 虽然作者坦承该库无法解决IE8/9打开控制台后才新建 `console` 对象的特殊场景，但其定位清晰——就像 `html5shim` 针对HTML5标签一样，`console.js` 专门处理 `console` API 的兼容层，让开发者不再需要写繁琐的 `if` 判断来“喂养”每一个浏览器。
这篇文章深入剖析了JavaScript中this关键字的行为规则。作者从其他编程语言的常见用法切入，指出JavaScript的this更加灵活且容易混淆，因为它的值并非静态，而是在每次函数调用时根据调用方式动态确定。 核心关键在于，this的值取决于函数“如何被调用”，而非“在哪里定义”。文章通过一系列递进的例子清晰地展示了这一点：在全局作用域中，this指向全局对象；当作为对象的方法调用时，this指向该对象；但若将方法赋给新变量再调用，this的指向就会改变。对于嵌套对象，this始终指向直接调用它的那个对象，而非最外层。在DOM事件处理中，this则指向触发事件的元素。作者还简要提及，可以通过call、apply或new操作符来手动控制this的指向。 总的来说，作者的目标是破除对this的误解。通过具体代码演示，文章阐明了this值在不同执行上下文中的变化逻辑，帮助开发者建立正确的心理模型，从而在编码时能准确预测this的行为。
这篇讲的是如何用不到100行代码实现一个轻量级DOM操作库，作为jQuery的精简替代方案。作者从实际开发中频繁的DOM操作需求出发，设计了简洁的API：例如通过`dom('.selector').val()`快速获取或设置元素内容。 核心实现上，文章展示了如何利用原生的`querySelector`和`querySelectorAll`来查询元素，并特别强调了作用域查询的能力——允许在指定的父元素上下文中查找，这增强了库的灵活性。另一个巧妙之处是库能同时处理单个DOM元素、选择器字符串以及一个包含多个选择器的JavaScript对象，后者可以批量获取元素并方便地转换为一个结构化的数据对象。 实现细节覆盖了如何获取不同类型元素（如input、textarea、文本节点）的值，以及通过链式调用返回API本身来保持操作流的连贯性。整个构建过程清晰地展示了一个虽小但功能完整的工具库从设计到实现的关键思路。
这篇文章聚焦于CSS的渲染性能，作者从日常编码中常见的写法入手，剖析了10种可能导致浏览器渲染变慢的习惯。 文章开篇就直指通配符选择器`*`的滥用，它会遍历所有标签，是性能的一大隐患。接着，作者犀利地指出了IE滤镜（如实现灰色效果的`filter: gray`）的高资源消耗问题，并以汶川地震时大量网站变灰导致CPU飙升的实际案例佐证。此外，诸如过度使用绝对定位、背景图片平铺策略不当、CSS选择器路径过深等影响渲染链效率的写法，也都被一一拆解。 对于每个问题，作者都提供了务实的替代方案，比如针对通配符，建议改为对常用标签（body, li等）单独重置；对于背景平铺，则建议将色彩少的图片制成尺寸稍大的GIF格式。文章强调，合理的布局和让属性通过继承传递，能从根本上优化渲染路径。这些经验之谈，源于作者在真实项目中遇到的性能瓶颈，为前端开发者提供了清晰的避坑指南。
这篇讲的是CSS布局从“一团糟”到初现曙光的演进史。作者从早年开发者们不得不依赖表格、浮动和inline-block这些“hack”方法来实现多列布局说起，深入剖析了其中的核心痛点：浮动需要 clearfix、盒模型计算导致宽度溢出、以及为列间距疲于奔命。 文章并未停留在抱怨历史，而是把重点放在了CSS3带来的三把“钥匙”上。它逐一演示了如何用 `box-sizing: border-box` 让宽度计算回归直觉，如何用 `calc()` 函数在百分比中精确扣除间距，以及 Flexbox 如何以更声明式的方式简化对齐与分布。每个方案都附带了清晰的代码示例和效果对比，直观展示了布局效率的提升。 当然，作者也没有回避现实。他指出 `border-box` 仍需搭配浮动，`calc()` 依赖负外边距这种老技巧，而 Flexbox 虽好却受制于当时的浏览器支持。这种客观的对比，让读者能清醒地认识到每个工具的适用边界。对于正挣扎于布局细节的开发者而言，这篇文章清晰地指明了哪些新特性值得立即投入学习，以及它们能实实在在解决哪类历史问题。
这篇文章源于作者在知乎的一个回答，分享了自己从大公司产品经理转型到小团队创业后的真实体会。作者从规划流程、竞品应对、用户研究、优先级决策、资源分配到日常响应速度等十多个维度，生动对比了两种环境下的心态与做法差异。 在大公司，流程规范、资源集中，但也面临层层审批和内部竞争；而在小团队，决策自主、响应敏捷，但必须直面成本压力和一人多职的挑战。文章通过“找喷都要请客”、“自己测功能担惊受怕”等细节，道出了创业者在资源约束下对效率和价值的极致追求。 这篇文章并非简单评判孰优孰劣，而是通过鲜活的对比，帮助产品人理解不同环境塑造的不同工作方法和思维模式，无论身处何处，都能更好地珍惜当下、专注成长。
这篇讲的是JavaScript原型继承中一个经典的“实例属性共享陷阱”。作者从一个简单的Widget父类和SubWidget子类出发，展示了当使用`SubWidget.prototype = new Widget()`设置继承后，所有子类实例会意外地共享同一个`messages`数组——比如给sub1和sub2分别push消息，结果它们的数组内容完全相同。 问题的根源在于，通过`new Widget()`创建的原型对象中，`messages`数组只初始化了一次，所有实例都指向原型上的同一份数据。作者用清晰的对象关系图逐步揭示了这一过程：原型上的共享属性，如何在实例操作时相互影响。 解决方法是在子类构造函数中调用`Widget.apply(this, arguments)`，借用父类构造函数在每个实例的上下文中初始化属性。文章还补充了两点优化：调整调用顺序以避免子类属性被覆盖，以及直接使用`SubWidget.prototype = Widget.prototype`避免父类构造函数重复执行。这些细节让这个“踩坑-解坑”的过程更具实操参考价值。
这篇文章系统梳理了提升jQuery与JavaScript代码性能的实战技巧，核心观点是：好的代码规范直接带来速度提升，而更快的渲染与响应能显著优化用户体验。作者从“jQuery本质就是JavaScript”这一前提出发，强调应遵循相同的编码最佳实践。 文中列举了多项具体优化措施，并辅以代码对比。例如，通过缓存DOM元素减少昂贵的遍历操作，为jQuery对象使用匈牙利命名法（$前缀）以增强代码可读性，以及将分散的var声明合并为单条语句。在事件处理上，推荐统一使用`.on()`方法；在代码组织上，则提倡链式操作与适当的格式化以兼顾简洁与可维护性。 文章进一步深入选择器优化层面，指出应避免使用通用选择符（如`*`），而是利用`.children()`等更高效的方法；同时强调ID选择符的唯一性，无需添加冗余的父级选择符。此外，诸如短路求值、分离元素进行批量操作等JavaScript通用技巧，也被融入jQuery的使用场景中加以说明。 总体来看，这并非泛泛而谈的理论，而是一套源自实践的“编码惯例”清单，旨在帮助开发者通过养成良好的编码习惯，从细节处挖掘出jQuery应用的性能潜力。
在JavaScript开发中，随着项目复杂度上升，模块间的依赖管理常常成为痛点。这篇文章从“如何优雅地解耦和替换模块依赖”这一实际问题出发，深入探讨了依赖注入的几种实现方案。 作者首先展示了一个硬编码依赖的例子，并由此引出依赖注入需要达成的目标，比如保持函数作用域、支持自定义参数等。文章详细分析了两种主流思路：一种是模仿RequireJS的显式声明方式，需要在注入器中按顺序注册依赖名；另一种是借鉴Angular的反射方法，通过解析函数参数名来自动匹配，这虽然更灵活，却存在一个致命缺陷——代码压缩会破坏参数名映射。 作者并没有止步于对比。为克服单一方案的局限，文章最后提出了一个结合两者优点的自定义注入器实现：既支持通过字符串列表显式声明依赖，也能尝试基于参数名的反射匹配，从而兼顾灵活性与生产环境的兼容性。整个探索过程逻辑清晰，从问题定义到方案演进，为读者提供了在实际项目中处理依赖关系的具体思路。
这篇笔记记录了一位长期使用Aptana的开发者，因工作需要转向Sublime Text 2后的真实上手过程与心得。作者坦言，初次接触便被其秒开的启动速度、干净简洁的界面以及“无干扰”的编辑体验所吸引。 为了高效驾驭这款新工具，作者遵循“工欲善其事，必先利其器”的原则，展开了一番针对性研究。文章的核心，是作者按照80/20法则总结出的一组最常用的快捷键。从用 `Ctrl+P` 快速搜索文件、`Ctrl+Shift+P` 打开命令面板，到使用 `Ctrl+L` 逐行选择、`Ctrl+M` 跳转括号，这些快捷键覆盖了文件导航、代码编辑、文本选择和面板操作等高频场景。 作者没有罗列全部功能，而是专注于能解决80%日常编码需求的关键操作，这种务实的思路让这篇笔记本身也成为了一种高效的“工具”，帮助其他开发者快速掌握Sublime Text的核心操作逻辑。
