最新文章

采集自各技术站点的近期文章。

IT 后端/ 2015-02-26 22:27:55 / 累计浏览 1,558

Plack 代码和结构分析-plackup Architecture[译]

这篇译文深入拆解了 Perl Web 框架 Plack 中 `plackup` 命令的内部架构，核心聚焦于 `Plack::Runner`、`Loader` 与 `Handler` 三者的协作机制。作者指出，我们常用的 `plackup` 脚本本身只是一个简单的封装，真正的“大脑”是 `Plack::Runner`。它负责解析命令行参数，并依次协调两个关键模块：`Loader` 与 `Handler`。`Loader` 决定了服务器的加载与运行模式，比如是否支持文件更改自动重启（Restarter），或是为每个请求 fork 新进程（Shotgun）。`Handler` 则是一个巧妙的适配层，它通过实现统一的 PSGI 规范接口，使得诸如 Starman、Twiggy 等原生 PSGI 服务器，甚至像 Apache2/FCGI 这类传统服务器，都能被 Plack 框架统一管理与调用。文章特别演示了如何自定义一个 `Handler`，以此扩展框架的服务器支持。理解这些组件的职责与交互（文中的时序图做了直观总结），对于掌握 Plack 如何以高度可插拔的方式启动和管理 PSGI 应用至关重要，也为开发者自行扩展服务器支持提供了清晰路径。

本机暂存

IT 算法/ 2015-02-26 22:26:26 / 累计浏览 4,536

软件开发的硬约束

这篇讲的是作者从超市结账小票的两种打印方式出发，对软件开发中“软约束”与“硬约束”的深刻反思。作者观察到，收银小票倾向于为同一件商品打印多行记录（每行数量为1），而非合并成单行（数量为N），即使后者更省纸。起初他怀疑是设备性能所限，但通过一次收货管理系统的开发与实地部署，他发现了真正的原因：合并记录会影响仓库作业流程的效率与操作习惯——后续员工需要在纸质清单上手动划销，单件单行才最直观。这个发现让他意识到，长期从事纯软件开发时，功能、架构与责任划分往往具有灵活性（“软约束”），可以按需调整。但现实世界存在大量“硬约束”，比如设备操作习惯、生产线工艺流程、物理环境限制等。他进一步以工厂生产多语言说明书为例：生产线难以像软件模块一样灵活拆分组合，导致不得不为所有市场印刷包含所有语言的通用说明书，以避免为每种语言维护独立生产线的高昂成本。作者总结道，随着软件深入物理世界，决定其价值的往往不是复杂的技术架构，而是能否与现实约束融洽相处。开发者需要跳出纯粹的代码思维，直面问题的核心限制。文章最后以快递站利用条码替代键盘操作的巧妙案例收尾，说明了解决方案可以完全跳出技术框架，以极低成本满足场景的真实需求。

本机暂存

IT 前端/ 2015-02-26 22:24:24 / 累计浏览 3,559

小tip: IE下zoom或Matrix矩阵滤镜中心点变换实现

这篇讲的是如何在老版本IE浏览器中实现元素居中缩放的问题。当CSS3 `transform`尚不可用时，IE的`zoom`或`Matrix`滤镜会改变元素的原始尺寸和位置，导致缩放时无法像现代浏览器一样以中心点为基准，开发者不得不手动计算繁琐的偏移值。文章提出了一种巧妙的“广阔海洋”布局方案来解决这个问题。其核心思路是：在外层可视容器内部，构建一个尺寸远大于自身的绝对定位容器（“海洋”），并通过`margin`负值将其精确居中。这样一来，需要缩放的元素在这个“海洋”里同样实现居中定位后，无论进行`zoom`还是`Matrix`变换，视觉上都能保持中心点不变。作者通过代码示例和效果对比清晰地展示了方案的有效性。在IE8等浏览器下，传统方法会导致图片从左上角放大，而运用此技术后，hover缩放效果就能与现代浏览器保持一致的中心点放大。对于旋转等其他矩阵变换，该布局策略同样适用，为低版本IE的兼容性开发提供了一个简洁且实用的解决思路。

本机暂存

IT 后端/ 2015-02-26 22:22:28 / 累计浏览 1,959

Plack 代码和结构分析一[译]

这篇讲的是作者从提升源码阅读能力出发，对 Perl 生态中的 Web 框架 Plack 进行的一次深度代码剖析。Plack 本身是 PSGI 规范的工具集，代码以简洁、注释极少且高度自解释而闻名，广泛采用了类似 JavaScript 的回调模式来处理事件驱动。作者首先通过 Git 获取了项目代码，并统计出它拥有超过 5600 行代码，核心贡献者超过 10 位。为了让庞杂的代码结构化，文章将 Plack 的 lib 目录拆解为三个清晰的层级：负责加载和运行服务器的模块（如 plackup 和 Loader）、用于构建 PSGI 应用的核心组件（如 Builder 和 Middleware），以及支撑测试的模块。每一部分都附有简短的功能描述。这种从宏观架构到微观目录的梳理方式，把一个看似复杂的框架拆解得层次分明，不仅展示了 Plack 优雅的设计，也为想学习阅读高质量开源代码的开发者提供了一份可操作的路线图。

本机暂存

IT 开发者/ 2015-02-26 22:21:24 / 累计浏览 5,720

让邮件飞一会儿

这篇讲的是，很多程序员每天都会遇到但未必认真思考过的场景——工作邮件。作者从开发经理发来的一封紧急邮件切入，探讨了邮件这种“又爱又恨”的沟通工具。他指出，邮件的核心优势在于其非实时性，既避免了直接打断他人工作，又能留下清晰的文字记录。文章将邮件按重要性分为紧急、重要和一般三类，并给出了明确的应对策略：紧急问题需立刻处理，重要事项可在完成手头任务后详细回复，而一般通知则仅需了解。针对如何高效回复邮件，作者提出了几个实用技巧：比如在邮箱中用颜色标注重要发件人，避免频繁查看邮件打断心流，以及由上级统一回复涉及需求或进度的邮件。作者认为，写邮件也是一门艺术。关键在于将其视为高效沟通的工具，而非工作的“累赘”。编写时应语句通顺、表意清晰、仔细检查，确保信息准确传达。掌握这些邮件处理的“学问”，能帮助我们更好地管理精力，让工作流程更加顺畅。

本机暂存

IT 后端/ 2015-02-26 22:20:27 / 累计浏览 1,903

Plack 代码和结构分析-Plack::Builder[译]

这篇翻译自 kablamo.org 的技术文章，深入拆解了 Perl Web 框架中 `Plack::Builder` 模块的内部实现。作者从其简洁优雅的 DSL 风格配置代码出发，揭示了背后支撑的三个核心编程技巧。第一个技巧是利用 Perl 的函数原型（`&`），确保 `builder` 块只能接收一个匿名子程序，否则会在编译时报错。第二个技巧是通过 `Exporter` 模块导出 `enable`、`mount` 等关键字，使它们在 builder 代码块内可直接作为函数调用。最精妙的是第三个技巧：这些 DSL 关键字在 `builder` 块外其实是会报错的占位符，仅在 `builder` 运行时被临时替换为真正的实现逻辑，从而实现了上下文内的“魔力”。文章通过具体的代码示例，将 Perl 语言特性与 DSL 设计模式巧妙结合的过程清晰地展现出来，对于想理解框架元编程技巧或 Perl 高级用法的开发者来说，是一次直观的代码剖析。

本机暂存

IT 后端/ 2015-02-26 22:18:37 / 累计浏览 4,659

关于http代理

这篇技术文章聚焦于一个网络基础问题：当使用HTTP代理时，目标域名的DNS解析究竟发生在用户客户端，还是代理服务器上？作者从两种典型的代理工作模式展开分析，厘清了其中的关键差异。第一种是直连模式，常用于HTTP请求，代理服务器直接接收客户端发送的完整URL并转发，因此域名解析由代理服务器完成。第二种是CONNECT隧道模式，主要用于HTTPS，客户端先与代理建立TCP通道，随后在通道内进行TLS握手，此时代理服务器同样负责解析目标域名。为了验证这一点，作者进一步使用Golang编写了测试代码，并设置环境变量来配置代理。测试结果表明，无论是HTTP还是HTTPS请求，Golang的标准库实现与curl的行为一致，域名解析都发生在代理服务器端。文章还揭示了一个有趣的实现细节：在Golang处理HTTPS请求时，代理的CONNECT握手与后续的数据传输是在不同的线程中完成的。通过对比和代码验证，这篇文章清晰地解释了不同代理场景下的底层行为，对于理解代理工作机制、进行相关调试或开发都有直接的参考价值。

本机暂存

IT 开发者/ 2015-02-26 14:11:47 / 累计浏览 2,753

如何通过互联网出版一本小书

这篇讲的是作者如何将一篇“写一本书”的愿望清单落地，并分享其中关于工具、渠道与心态的完整实践经验。工具上，他推荐技术作者使用GitBook，因为它支持Markdown、能一键生成多种电子书格式，并可拖拽调整章节。他也坦诚提到了早期版本在中文支持上遇到的小坑，建议可搭配其他编辑器使用。分发渠道部分对比详细：自建页面如SelfStore流程简单但需自行推广；百度阅读自带编辑器且支持版权控制，但平台流量有限；多看、亚马逊等主流平台则需通过BookDNA等代理上架，作者指出这类代理虽能扩大覆盖面，但存在收益反馈滞后和版权授权的风险。最重要的是心得：他发现2-3万字聚焦细分领域的“小书”同样有出版机会，这打破了必须靠篇幅“凑数”的传统观念。作者鼓励技术人员从经营系列博文开始，逐步积累，未来无论是自出版还是联系出版社，都会更为从容。这为许多想系统化整理知识但畏惧“出书”工程量的人，提供了一条清晰的轻量路径。

本机暂存

IT 开发者/ 2015-02-26 14:10:02 / 累计浏览 2,565

互联网公司和软件工程那些事

这篇从作者在新浪的一次通宵加班经历讲起，具体描绘了当年大型项目开发时，团队如何在高强度工作中依然面临延期困境。由此，他开始了对软件工程的长期思考。作者的核心发现是，延期问题的根源往往在于需求定义的粗糙。在他后来负责新浪云计算项目时，通过将需求分解到技术实现级别，做到了以小时为单位的精准排期，将延期控制在极小范围内。这揭示了互联网时代需求与开发关系的本质变化。在质量控制方面，文章分享了两个生动实践：一是为降低技术门槛而设计的LazyPHP框架，二是通过资源配额实现代码优化的新浪云平台策略。同时强调，单元测试、编码规则等硬性指标必须集成到发布系统中，形成自动化约束。最终，作者提出了一个前瞻性观点：传统的“软件工程”概念已经过时。他主张未来会走向“产品工程”，即以产品为核心、以天为周期的全流程迭代，并认为大型技术团队将分化为平台支撑与业务实现两类角色。文章融合了个人实战经验与行业趋势洞察，对互联网时代的技术管理方式提出了独到反思。

本机暂存

IT 算法/ 2015-02-26 14:07:49 / 累计浏览 2,502

使用逻辑时钟重述paxos协议

Paxos协议以其晦涩难懂而闻名，但这篇技术博客提供了一个清新的视角：用逻辑时钟来重述它。作者认为，一旦从带时钟同步的RPC协议出发，复杂的共识流程就变得直观起来。文章首先构建了一个基于逻辑时钟的通信框架。它引入一个全局计数器（globalClock）来产生全局递增的时间戳，规定所有网络消息必须携带时间戳，且接收方拒绝处理“过时”的请求。这个简单的同步机制，为后续的协议设计打下了确定性基础。在此基础上，Paxos的两个阶段被清晰地映射为两类带时钟的请求。Proposer在Prepare阶段（设置时钟、广播提案号）和Accept阶段（发送具体提案）中，都遵循“时钟必须严格递增”的规则。Acceptor则依据收到的消息时间戳与本地时钟的比较，来决定是接受还是拒绝。这样一来，协议中复杂的冲突避免和提案推进，被转化为了对时钟值的比较和递增操作。更进一步，文章指出可以摆脱中心化的全局时钟服务。每台机器的本地时钟可由一个二元组（轮次编号roundNumber, 服务器ID）构成。通过定义先比较轮次再比较ID的规则，保证了分布式环境下时间戳的全局唯一性和单调性，使得整个协议更加贴近实际部署场景。总而言之，这种重述方式将分布式共识中抽象的“提案编号”竞争，转化为对逻辑时钟值的单调递增和比较操作，让Paxos协议的内在逻辑——即如何利用确定的全局顺序来避免冲突、达成一致——变得异常清晰。

本机暂存

IT 后端/ 2015-02-26 14:05:46 / 累计浏览 3,618

Java跨语言调用实现方案

这篇文章探讨了在大型分布式Java系统中，如何在不改变原有POJO发布方式的前提下，实现跨语言RPC调用。作者指出，随着业务扩展，上层可能采用PHP、Ruby等技术，而底层服务又可能需要用C++、Python来追求更高性能，这就对现有的、基于Java的RPC框架（如Spring Remoting）提出了跨语言兼容的挑战。文章首先梳理了业界三大主流方案：Google Protocol Buffers、Facebook Thrift 和 Apache Hadoop Avro。作者分析了各自的优劣：Protocol Buffers 的序列化格式高效但RPC能力弱，生成代码有侵入性；Thrift 提供了完整的服务栈和强大的接口支持，但与现有Java RPC体系不兼容；Avro 的动态类型机制灵活，但学习成本较高。最终，作者提出了一种“扬长避短”的混合解决方案：核心采用Protocol Buffers的序列化格式和代码生成能力，服务接口定义借鉴Thrift的模式，并兼容现有的RPC传输层；同时，利用Avro的Schema机制来实现对原有POJO对象的无缝序列化与反序列化。这套方案旨在保留现有Java RPC架构的同时，优雅地打通多语言互操作。文章还留下了具体实现细节，为后续分享埋下了伏笔。

本机暂存

IT DevOps/ 2015-02-26 14:03:22 / 累计浏览 5,316

在vim保存时获得sudo权限

这篇讲的是在vim编辑器中，如何不退出进程就能获得sudo权限来保存只读文件。在维护线上服务的过程中，工程师经常需要编辑那些只有读权限的文件——比如系统配置或日志文件，它们通常属于其他用户。每次保存时，vim都会提示“read-only”，迫使你先退出编辑，再用sudo vim重新打开文件进行保存。这种反复切换的操作不仅繁琐，还容易打断思路，尤其在紧急修复时更显低效。文章作者从这一常见痛点出发，分享了一个巧妙的解决方案：使用vim命令 `:w !sudo tee %`。这个命令允许在vim内部直接调用sudo权限，将当前缓冲区的内容保存到文件，无需中断编辑进程。具体来说，`:w !{cmd}` 执行外部命令`{cmd}`，并将缓冲区内容通过stdin传入；tee工具负责将stdin保存到文件；而`%`是vim中的一个只读寄存器，始终存储着当前编辑文件的路径。因此，整个操作相当于从vim外部修改了文件，巧妙地绕过了权限限制。这个技巧能极大提升运维效率，避免反复退出和重启vim的麻烦。它展示了vim命令行的强大灵活性，以及如何利用外部工具增强编辑器的功能——对于经常处理系统文件的技术人员来说，这无疑是一个实用且高效的工作流优化。

本机暂存

IT 开发者/ 2015-02-20 22:23:05 / 累计浏览 3,833

野兽派游戏

这篇讲的是一个IT创业者从虚拟世界走进传统行业后，对“成功”与“生存”的重新思考。作者从自己转行做摄影服务出发，发现传统行业环环相扣的链条远比专注一个点的IT复杂。为了突破行业瓶颈，他甚至被迫去“颠覆”印刷业。在应对创业焦虑和外部不确定性的过程中，他提出了“野兽派”的生活哲学：像野兽一样，把“保持活着”视为最根本的成功标准。他将这种心态具体化：房子本质是居住空间，买或租只是形式；工作应追求满足感而非仅为了生存；无需被股票、学区房等社会设定的规则耗尽精力。这种回归本质的视角，帮他剥离了大多数不必要的恐惧与负担。文章最终落脚于一个启发：当我们卸下社会灌输的复杂标准，用野兽般的简单逻辑看待生活，很多焦虑和抉择会变得清晰。生存本身就是一场可被我们掌握规则的游戏，而真正的挑战，在于找到能带来深层成就感的“游戏”。

本机暂存

IT 后端/ 2015-02-14 14:21:22 / 累计浏览 4,228

java中文乱码解决之道（六）—–javaWeb中的编码解码

这篇深入分析了Java Web开发中最令人头疼的中文乱码问题，尤其聚焦于服务器与客户端交互的编码/解码链条。作者从用户发起请求的四种方式（URL直接访问、链接、表单GET/POST）切入，详细拆解了浏览器在编码URL路径和查询字符串时的差异——例如IE与Chrome/Firefox在处理同一段中文时，一个采用GBK而其他采用UTF-8，揭示了乱码产生的首要根源。文章的核心亮点在于源码级剖析。它追踪了Tomcat服务器接收请求后的解码流程，展示了`CoyoteAdapter`如何通过`connector.getURIEncoding()`获取`server.xml`中配置的编码集（如`UTF-8`）来解析URI，并默认使用`ISO-8859-1`处理未指定的字符。对于请求参数，则解析了`Request.parseParameters()`方法的调用时机与逻辑。这些底层实现解释了为何配置不当或浏览器行为不一致会导致乱码。最终，文章将整个过程归纳为“页面编码->服务器解码->业务处理->编码响应->客户端解码”的闭环，并强调在服务器-客户端交互环节集中设置正确的编码是解决问题的关键。对于需要彻底理清Java Web中文乱码链条的开发者而言，这是一份从现象到原理的清晰指南。

本机暂存

IT 前端/ 2015-02-14 14:19:21 / 累计浏览 2,495

内容loading加载后高度变化CSS3 transition体验优化

这篇讲的是如何用一行代码优化动态内容加载时的高度过渡体验。作者从常见的加载场景出发，敏锐地指出了一个普遍但容易被忽略的体验问题：当内容（尤其是高度不确定的动态内容）突然呈现时，那种“砰砰砰”的生硬切换，与流畅的动画过渡相比，显得格外突兀。文章的核心挑战在于，CSS3 transition无法直接将高度从一个固定值动画到 `auto`。为了解决这个难点，作者提供了一个仅十行左右的 JavaScript 函数 `funTransitionHeight`。其巧妙之处在于，它通过快速读取内容变为 `auto` 后的高度，再立即设回原高度作为起始值，最后在 `setTimeout` 中将高度设置为目标值，从而“欺骗”浏览器触发了平滑的 `height` 过渡动画。整个方案的实操性非常强，只需在内容载入后增加一次函数调用即可生效，实现了低成本的体验提升。效果上，原本生硬的高度变化被流畅的伸展动画所替代，让交互过程变得更加自然舒适，符合现代前端对细节体验的追求。

本机暂存

IT 后端/ 2015-02-14 14:17:28 / 累计浏览 1,882

java中文乱码解决之道（五）—–java是如何编码解码的

这篇文章深入到了Java虚拟机内部，剖析了字符编码解码的核心机制。作者从I/O操作和内存处理这两个乱码高发场景切入，详细拆解了Java如何处理字符与字节之间的转换。文章指出了一个关键点：乱码的“元凶”往往是编解码使用的字符集不一致。例如，在按字节读取UTF-8编码的文件时，若未在构造String时明确指定编码，Java会使用平台默认的GBK去解码，结果自然就乱了。更巧妙的是，文章揭示了字符流（如InputStreamReader）本质上只是一个“桥梁”，其底层仍在进行字节读取，并依靠指定的字符集完成解码。在内存操作部分，文章通过分析String.getBytes()与new String()的源码，展示了StringCoding.encode()和decode()方法的工作流程。特别指出了一个隐藏逻辑：如果没有指定编码，系统会先尝试平台默认编码，失败则回退到ISO-8859-1。理解这套内部流程，能帮你从根源上理解乱码问题。

本机暂存

IT 后端/ 2015-02-14 14:15:24 / 累计浏览 1,670

[译文]使用 Mojo::DOM 来解析和处理 HTML

这篇译文探讨了一个Perl开发者常会遇到的问题：如何优雅地解析和操作HTML。文章作者明确反对使用正则表达式这类“笨办法”，转而推荐Mojo::DOM这个模块，并细致地展示了其优越性。文章从核心痛点出发，解释了直接操作文本的低效与脆弱。作者演示了Mojo::DOM如何通过更接近前端开发思维的CSS3选择器来定位元素，这比记忆和编写复杂的XPath要直观得多。全文以一个实际任务——从CPAN作者页面提取模块列表——为主线，手把手展示了从获取DOM对象、用`find`方法查找元素，到利用`map`、`attr`、`grep`等方法进行链式处理和过滤的全过程。这种流畅的方法链风格，让数据处理的逻辑清晰地呈现出来。最终，文章不仅解决了“如何解析”的问题，更示范了如何将原始HTML精准地转化为一个干净、结构化的Perl数据结构。对于任何需要用Perl处理网络数据或本地HTML文件的开发者来说，这篇文章提供了一个清晰、实用且现代化的工具使用指南。

本机暂存

IT 后端/ 2015-02-14 14:13:52 / 累计浏览 2,124

Perl 中的 IPC::Semaphore 信号量的操作

这篇讲的是 Perl 中如何利用 `IPC::Semaphore` 模块来操作操作系统信号量，以实现多进程间的同步与互斥。文章从信号量的基本概念讲起，清晰解释了其值与资源数量的对应关系，以及 PV 操作（请求资源与释放资源）的具体含义。核心部分聚焦于 Perl 的 `IPC::Semaphore` 模块，详细演示了如何创建信号量、设置其初始值（使用 `setval`/`setall`）以及执行关键的 `op` 方法来进行 PV 操作。作者通过一个具体的对比实验，生动展示了信号量的实际作用：一段使用信号量的代码，能让所有子进程在父进程统一“发令”后几乎同时开始执行；而一段未使用信号量的对照代码，子进程则会因创建延迟而依次启动。这个例子虽然简单，但直观地证明了信号量在控制多进程同步启动时的效果，帮助理解其工作原理。

本机暂存

IT 数据库/ 2015-02-14 14:11:58 / 累计浏览 1,904

理想数据库客户端的准则

这篇讲的是，一位开发者从实际项目（Gittask）中遇到的数据库客户端“抽象漏洞”出发，思考了理想的数据库客户端应具备哪些特质。作者认为，当前客户端普遍存在不足，理想的客户端应遵循三大准则：首先是“无损序列化与反序列化”，客户端应负责保持数据结构的完整性，确保存取的类型完全一致，避免开发者陷入繁琐的类型转换。其次是支持“混合持久化”，客户端应能统一接入不同后端数据库，让开发者可以为不同任务选择最合适的数据库。最后是实现“跨数据库的原子事务”，当操作涉及多个数据库时，客户端应保证操作的原子性，任何环节失败都能整体回滚，避免数据处于不一致状态。文章还进一步探讨了，这种客户端应将复杂数据库操作抽象为 get、put、del 等基础操作，同时允许扩展调用特定数据库的独特功能。作者借此批判了ORM是抽象漏洞的观点，并提倡用独立的数据校验库配合此类客户端来构建模型。这套准则指向一个更强大、更通用的数据库交互层，旨在减轻开发者心智负担，让多数据库架构的开发与维护变得更可靠、更简洁。

本机暂存

IT 后端/ 2015-02-14 14:10:13 / 累计浏览 2,750

排错经历：全局变量被多次析构

这篇讲的是一个C++服务程序在退出时崩溃的排查过程。作者团队发现服务每次正常退出都会触发core dump，堆栈显示崩溃发生在exit()函数析构全局变量时，提示“double free or corruption (fasttop)”，指向一个std::string全局变量。排查过程相当硬核。由于服务器使用定制glibc，缺乏调试符号，作者只能在不完整的栈上“黑灯瞎火”地工作。核心难点在于，崩溃发生在main函数返回之后，且该std::string在exit中被析构数百次，难以直接定位。作者尝试在string的析构函数中打断点，却发现this指针已被编译器优化掉，常规条件断点也无法设置。最终，作者绕到析构函数的底层实现（_M_dispose）下断点，并通过分析内存布局，找到了引用计数成员（_M_refcount）的偏移地址。他巧妙地设置了一个基于寄存器的条件断点（`if *((int*)$edi+4)!=-1`），成功捕获到了那个引用计数异常（为-2）的string对象。通过自定义的xxd命令打印内存，最终定位到了那个出问题的全局变量。整个过程展示了在调试信息匮乏的条件下，如何结合对内存结构和编译器行为的深刻理解，一步步从core dump反向追踪到问题根源的扎实技巧。

本机暂存