最新文章

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

IT 后端/ 2014-09-17 12:19:04 / 累计浏览 1,460

rabbitmq java client api详解

这篇详细拆解了RabbitMQ Java客户端的核心API，是一篇非常实用的技术讲解。文章首先快速厘清了AMQP协议下的关键概念：Broker、Exchange、Queue以及Binding如何通过Routing Key与Binding Key共同决定消息流向。随后，重心转向Java客户端的实战部分，从最基础的连接代码讲起，逐步深入到更复杂的配置场景。例如，如何通过配置线程池来并发消费消息，如何设置地址数组实现连接故障时的自动转移。核心API部分讲解得非常细致，包括了声明交换机、队列及其绑定的完整参数含义，发送消息时`basicPublish`各个参数的作用，以及通过`DefaultConsumer`进行消费和手动确认ACK的模式。文中还特别指出了一个最佳实践：虽然Channel是线程安全的，但为每个线程创建独立Channel能避免潜在的性能问题。此外，文章还补充了一些容易忽略但至关重要的细节，比如如何设置QoS、开启连接自动恢复、配置心跳时间，以及各种Exchange类型（如direct, topic, fanout）的适用场景。对于需要快速上手或深入使用Java Client的开发者来说，这篇文章提供了清晰的路线图和实用技巧。

本机暂存

IT DevOps/ 2014-09-15 14:16:17 / 累计浏览 1,717

在一个列表里选定主机名后直接 SSH 登陆

运维或开发人员常会遇到这样的场景：即使有配置管理工具，仍免不了需要手动SSH登录单台服务器排查问题。反复查IP、复制、切换窗口的操作既繁琐又容易出错。这篇文章介绍了一个简洁实用的解决方案：一个名为warp的Bash脚本。它的核心思路很直接——将常用服务器的主机名或IP地址整理在一个文本文件中，通过运行脚本即可调用Vi/Vim进行选择式登录。用户只需在列表中上下移动光标，按下回车便能自动完成连接，省去了手动输入的麻烦。 warp的设计亮点在于其灵活性。配置文件格式自由，支持使用注释（如“#”或“--”）对服务器进行分组和说明，既清晰又便于维护。工具本身仅是一小段脚本，无需复杂安装。更巧妙的是，如果同时选中多行，它还能配合csshx工具实现批量操作，进一步提升效率。这种将机械性操作自动化的思路，虽然工具简单，却能有效优化日常工作流，减少重复劳动。对于经常需要管理多台服务器的团队来说，是个不错的效率小工具。

本机暂存

IT 后端/ 2014-09-15 14:12:28 / 累计浏览 4,715

网关协议学习：CGI、FastCGI、WSGI

这篇讲的是Web服务器与后端程序如何对话的几种核心协议。作者从最传统的CGI讲起，它每次请求都要“fork-and-execute”一个新进程，这种简单粗暴的模型在面对高并发时会迅速耗尽服务器资源。于是FastCGI登场，它采用了“常驻进程”的设计，将解释器进程保持在内存中，性能据称能提升5倍以上。文章接着剖析了PHP生态中与此相关的几个工具：PHP-CGI的先天不足、Spawn-FCGI的古老与脆弱，以及PHP-FPM作为现代解决方案提供的平滑重启、慢日志等实用功能，形成了一个完整的技术栈演进图景。最后，文章将视线转向Python的WSGI。它并非一个具体的程序，而是一份让Web服务器与应用程序解耦的“契约”。通过中间件层的设计，WSGI能够实现请求路由、负载均衡等高级功能，极大地提升了Python Web应用的灵活性和可移植性。从CGI到FastCGI再到WSGI，这条技术演进的线索清晰地展示了一个核心诉求：如何在保证功能的前提下，不断提升Web交互的性能与架构的优雅度。

本机暂存

IT 移动开发/ 2014-09-15 14:11:40 / 累计浏览 5,594

近距离端详Android ART运行时库

这篇技术分析聚焦于Android平台从Dalvik虚拟机向ART运行时过渡的核心变革。文章从Google I/O大会的发布背景切入，指出传统Dalvik虚拟机在应对多核处理器、大内存等新硬件趋势时已显吃力，从而引出ART的诞生。文章的核心，是将ART与Dalvik进行多维度对比。最关键的差异在于编译策略：ART采用预编译技术，在应用安装时一次性将字节码编译为本地机器码并存储，而Dalvik依赖于每次运行时的即时编译。这一改变带来了直接好处，例如性能测试显示代码执行效率可提升2到3倍，同时因减少了运行时编译开销而有助于延长设备续航。另一个对比重点是垃圾回收机制。文章通过详实的日志对比了二者的表现：Dalvik的垃圾回收常导致数十甚至上百毫秒的停顿，引发明显的画面卡顿；而ART经过重新设计的垃圾收集器，能将这类停顿时间压缩到微秒级，卡顿现象得到极大改善。文章也客观指出了ART的权衡之处，即首次安装或设备启动时的编译时间会变长，但这是用一次性的存储和时间成本，换取了应用运行期的长期性能收益。总体而言，这是一次为匹配现代硬件能力而进行的底层架构升级。

本机暂存

IT 开发者/ 2014-08-15 14:06:44 / 累计浏览 2,142

教你如何在Windiws平台上创建以点(.)开头的文件名

Windows系统有个小脾气：当你想创建像.gitignore这样以点开头的配置文件时，如果直接输入文件名，系统会弹出“文件名不能以点开头”的错误提示。这给需要管理隐藏配置文件的开发者带来了困扰。这篇教程分享了一个非常巧妙的解决方法：在命名时，在期望的文件名（例如.gitignore）末尾**再添加一个点**，将其输入为“.gitignore.”。这样，文件就能成功创建，并且系统会自动识别并保留真正的“.gitignore”这个文件名。这个技巧利用了Windows文件命名规则中的一个小盲区，虽然简单，却有效解决了实际问题。需要注意的是，这个方法在Windows资源管理器中操作有效，但更适合需要看到文件扩展名的程序员用户。对于普通用户，通常可以通过命令行或其他方式达到目的。这个小技巧体现了在技术实践中，有时绕过表面限制、理解系统底层行为，能找到意想不到的简便解法。

本机暂存

IT 前端/ 2014-08-15 13:52:56 / 累计浏览 2,488

浏览器的重绘(repaints)与重排(reflows)

这篇讲的是浏览器渲染页面的核心机制——重绘与重排，这是前端性能优化中必须理解的概念。文章从页面加载流程入手，清晰地区分了两个关键环节：重排是元素几何属性变化导致渲染树需要重新计算，性能开销显著；重绘则是元素外观改变触发的重新绘制，不一定引发重排。但重排必然伴随重绘，理解这种连锁反应至关重要。作者列举了几种典型的重排触发场景，比如修改DOM几何属性、改变DOM结构，甚至只是读取 `offsetWidth` 等属性值，也会强制浏览器同步计算布局，打乱其优化节奏。这些细节揭示了性能问题的隐形来源。文章的价值不止于概念解析，更提供了切实的优化策略：将多次样式修改合并、对动画元素使用绝对定位以隔离影响、在内存中操作节点后再插入文档，以及隐藏元素进行复杂操作等。这些实践建议直接指向如何在开发中最小化重排次数和影响范围，帮助开发者规避常见的性能陷阱。

本机暂存

IT 前端/ 2014-08-15 13:51:14 / 累计浏览 3,309

页面重绘和回流以及优化

这篇讲的是前端性能优化中的关键概念：页面重绘与回流。作者从浏览器渲染页面的流程切入，清晰解释了DOM树、样式结构与渲染树（Render Tree）的构建关系，并指出渲染树不包含 `display:none` 等隐藏节点这一重要细节。文章的核心是区分回流与重绘：当元素的几何属性（如尺寸、位置）改变时触发回流，浏览器需要重新构建部分渲染树；而仅改变外观属性（如背景色）则只触发重绘。作者强调“回流必将引起重绘”，并列举了六种常见触发回流的场景，如DOM增删、窗口尺寸变化等。为说明性能影响，文章通过一段JS代码演示了连续样式修改如何导致多次不必要的回流。同时，作者揭示了浏览器内部的优化机制——通过维护操作队列来合并回流操作，并提醒开发者某些属性访问（如 `offsetWidth`）会强制刷新该队列。最后，文章给出了具体的优化策略：批量修改样式（如使用 `className` 或 `cssText`）、采用离线操作（如 `DocumentFragment`）、缓存布局信息，以及让动画元素脱离文档流。这些方法能有效减少渲染树的重构规模，提升页面性能。

本机暂存

IT 算法/ 2014-08-15 13:49:20 / 累计浏览 3,580

用三段 140 字符以内的代码生成一张 1024×1024 的图片

这篇讲的是 StackExchange 上一个名为 “Tweetable Mathematical Art” 的硬核编程挑战。参赛者需要仅用三段不超过 140 字符（相当于一条推文长度）的 C++ 代码，生成一张 1024×1024 像素的彩色图片。规则是实现 RD、GR、BL 三个函数，分别对应红、绿、蓝三原色通道，通过数学计算为每个像素点赋值。文章的核心亮点在于展示了极简代码如何创造出令人惊叹的视觉艺术。例如，Martin Büttner 的作品仅用寥寥几个三角函数就生成了绚丽的渐变图案；而排名第一的作品更是利用随机数和递归，在极短的代码内实现了类似分形的纹理效果。文章还列举了用极简代码绘制 Mandelbrot 分形集的实例，颠覆了人们对复杂图形生成代码量的认知。这些参赛代码巧妙利用数学公式、随机种子甚至静态变量，在字符限制内实现了图像算法的核心逻辑。文章不仅分享了有趣的代码片段，更展现了在极限约束下编程的创造力和美学，对于理解图形学原理和代码压缩技巧都很有启发。

本机暂存

IT 开发者/ 2014-08-15 12:31:42 / 累计浏览 2,126

Python中的闭包

这篇讲的是Python中一个既基础又容易模糊的概念——闭包。作者从一个实际的读者提问出发，用维基定义的“词法闭包”和“自由变量”两个关键词引入，并巧妙地将其比喻为一个“封闭的包裹”，包裹（函数）内部装着随身携带的自由变量。文章的核心对比在于闭包与类：两者都实现数据封装，但闭包粒度更细，是一个只读的“函数对象”。作者接着深入剖析了闭包在Python中最常见的三个应用场景：一是构建装饰器，通过闭包持有被装饰函数并扩展其功能；二是实现类似“惰性求值”的效果，推迟某些操作（如数据库查询）的执行；三是作为`functools.partial`的原理示范，用于函数参数的提前绑定。通过这些代码示例，文章清晰地展示了闭包如何作为函数式编程的重要工具，解决代码复用和状态保持的问题。对于想真正理解Python装饰器机制或函数式编程特性的开发者来说，这篇从概念辨析到实战落地的讲解是个不错的起点。

本机暂存

IT 后端/ 2014-08-13 12:34:57 / 累计浏览 5,152

百度是如何使用hadoop的

这篇文章讲的是百度如何将Hadoop深度应用于其海量中文搜索及数据处理场景。面对日志存储、网页挖掘、商业分析、在线反馈等复杂需求，百度不仅大规模部署了Hadoop（约700台机器，日均处理120TB数据），还针对实际运行中的效率与可靠性问题进行了系统性改造。具体来看，百度在多个层面做了定制优化：在MapReduce策略上，通过限制作业并发、调整预测执行和基于节点内存调度来提升稳定性；对HDFS增强了权限控制与容错能力，比如让分区与节点解耦，避免单点故障影响全局。此外，他们还修改了推测执行（Speculative）策略，用速率倒数来更公平地触发备份任务，并引入资源控制机制，甚至修改Linux内核来限制进程内存使用。文章也坦诚分享了百度在实践中遇到的痛点，包括MapReduce的I/O与排序效率、HDFS的随机访问延迟、内存管理压力以及作业调度精细化等问题，并针对如Streaming只能处理文本数据的局限，提出了自研的Bistreaming方案。这些细节揭示了在超大规模环境下，如何将开源框架“打磨”得更适合生产需求——不仅是使用，更是持续的调优与二次开发。

本机暂存

IT DevOps/ 2014-08-13 12:33:03 / 累计浏览 2,797

Linux系统巡检常用命令

这篇讲的是Linux系统日常巡检的“工具箱”，作者把运维中最常敲的几十条命令按用途做了梳理。从用`uname -a`和`cat /proc/cpuinfo`摸清系统底牌，到用`free -m`、`df -h`、`top`实时监控内存、磁盘与进程状态，再到借助`netstat`、`iptables`、`ifconfig`快速扫描网络连通性与安全设置——几乎覆盖了服务器健康检查的所有关键维度。文章特别指出，像`uptime`和`cat /proc/loadavg`这样的组合，能让你同时看清系统负载与运行时长；而`ps -ef`配合`w`命令，既能看到全部进程，也能锁定当前登录的活跃用户。对于需要回溯问题的场景，`last`查看登录日志、`dmesg`排查硬件启动信息这些命令也都没落下。整份清单直接贴进终端就能用，省去了新手翻文档的时间，对需要快速上手Linux运维的人尤其友好。

本机暂存

IT 安全/ 2014-07-28 12:45:44 / 累计浏览 2,202

有用的linux命令——chattr

这篇讲的是Linux系统里一个容易被忽略但超实用的命令——chattr。我们平时用的rwx权限，是操作系统层面的规定。但chattr管理的是ext文件系统赋予文件的“隐藏属性”，它有个关键区别：一旦设置，连root用户也要遵守规则，比如用chattr +i给文件加上“i”属性后，这个文件就变得“坚不可摧”：不能被删除、修改、重命名，也不能创建硬链接。文章通过实际命令截图演示了这个过程，哪怕用rm强制删除也会报错。作者从这个防误删的实用场景切入，清晰说明了如何用lsattr查看属性、用chattr设置属性。对于运维人员或需要保护关键配置文件的开发者来说，这相当于给重要文件上了一道“系统保险锁”，能有效防止手滑或脚本误操作导致文件丢失。

本机暂存

IT 开发者/ 2014-07-28 12:45:00 / 累计浏览 3,429

那些让工作更美好的设备们

这篇文章分享了作者在办公室和家里使用各种设备的体验与推荐。作者从自己的办公桌面和家里环境出发，列举了包括DELL U2412m显示器、Noppoo Lolita机械键盘、罗技G1鼠标以及SteelSeries QcK+鼠标垫等在内的一系列日常装备，并详细解释了选择它们的理由。核心观点在于：每天高频使用的设备，值得投资好一些的。作者认为，这能换来持续的高效率和好心情，这笔钱花得其所。比如，他盛赞了IPS屏幕的色彩与可视角度，以及可升降旋转支架带来的舒适姿势；在键盘选择上，则分享了对87键布局、红轴手感以及走线设计的个人偏好。文章不仅是单纯的产品罗列，更融入了作者对于“好设备如何提升幸福感”的切身思考。例如，他提到一些功能“没用前不觉得，用了再退回没有时就会很不爽”，道出了升级体验的本质。对于那些觉得公司设备不佳的读者，作者也提出了务实的建议：如果是自己干活必需的，不妨自费购买，毕竟这些设备未来还能带走。对于关注日常工作效率与幸福感的读者，这篇结合了个人实践与详细点评的分享，提供了许多具体而实用的升级思路。

本机暂存

IT 后端/ 2014-07-28 12:43:31 / 累计浏览 2,602

CAP 理论

这篇技术文章深入剖析了CAP理论这个分布式系统的经典法则，指出很多人对其存在理解误区。作者从Brewer的原始猜想和Gilbert & Lynch的严谨证明出发，澄清了C、A、P三个属性在证明中的严格界定——尤其是将一致性(C)等同于数据库ACID中的原子性，这一点是理解后续讨论的关键。文章梳理了CAP证明所依赖的强假设（如纯异步网络），并讨论了在现实中放松这些条件的可能。例如，放弃分区容错(P)意味着可扩展性受损，放弃可用性(A)则无法容忍服务中断，因此主流的分布式存储系统（如Cassandra、Dynamo）通常选择放宽一致性，转向最终一致性模型。作者还对比了两种试图“挑战”CAP的思路：一种是通过引入版本控制和操作排队规则，让系统在不同时段分别满足CAP属性；另一种是通过数据模型重构（如仅追加数据、将读操作转化为查询），以更简单的方式拥抱最终一致性，从而规避CAP带来的复杂性。文章最终指出，CAP定理依然稳固，未来的关键或许在于如何通过巧妙设计绕过其严格限制的区域。

本机暂存

IT DevOps/ 2014-07-15 23:43:20 / 累计浏览 4,946

tailf and tail -f

这篇文章从一个实际使用场景出发：用`tailf`查看大文件的新增日志时，发现没有输出，而改用`tail -f`却能立即显示。由此引出了对这两个命令核心机制差异的深入剖析。文章指出，二者的关键区别在于读取起点和检测文件变化的系统调用不同：`tailf`从文件开头逐步读取，通过文件名调用`stat`来检查文件变化；而`tail -f`则从文件尾部开始，通过已打开的文件描述符使用`fstat`进行检测。这个底层差异导致了具体行为的不同，比如在文件被删除时，`tailf`能感知到，而默认的`tail -f`则不知道。此外，文章还详细解读了`tail -F`选项（大写F）的工作原理——它通过周期性地尝试重新打开文件来兼顾对文件名变化的跟踪，是一个在`tailf`和`tail -f`之间的实用折中。最后通过`strace`跟踪的输出，直观展示了`tailf`使用`stat`与`tail`使用`fstat`的调用区别。对于经常需要监控日志文件的运维和开发人员来说，理解这些区别能帮助他们在不同场景下选择最合适的工具。

本机暂存

IT 设计/ 2014-07-15 23:06:43 / 累计浏览 2,404

Think Aloud－适合设计师的可用性方法

这篇讲的是设计领域一个经典又实用的用户研究方法——Think Aloud（出声思考）。它源于1982年IBM，并由Jakob Nielsen在可用性工程中推广，核心在于让测试用户在操作产品原型或界面时，即时地说出看到的、想到的和疑惑的内容，帮助设计师直接捕捉用户最真实的交互心智。文章重点分析了该方法相较于其他测试的独特优势：它经济高效（仅需2-8名用户）、结果可靠、形式灵活（适用于从纸面原型到上线产品的任何阶段），并且因为过程直观，极具说服力。作者进一步拆解了具体操作流程：从准备模拟真实场景的测试界面、设计明确任务脚本，到邀请合适的用户进行训练与测试，最后从用户的即时反馈中解读设计问题。文中以电商页面的“尺码助手”功能为实例，展示了如何通过用户一边操作一边的自述，发现入口隐蔽、操作路径不符合预期等设计痛点。总的来说，Think Aloud是帮助设计师和团队在早期阶段快速、低成本地验证设计假设、洞察用户真实反应的利器，它强调获取交互过程中即时的、主观的反馈，让优化决策更有据可依。

本机暂存

IT 移动开发/ 2014-07-15 23:02:58 / 累计浏览 3,662

高效输出移动app产品原型

这篇讲的是如何快速高效地完成移动App产品原型设计。作者针对原型制作过程中思路不清、协作繁琐、体验不真实等痛点，提出了一套分三步走的系统方案。核心方法在于化繁为简：首先，用“界面标题+主要内容”这种极简卡片来绘制产品流程图，确保整体逻辑正确，也便于快速讨论调整。接着，利用一套预制的Axure高保真控件库，设计师只需修改文字颜色和位置，就能迅速组装出规范的原型界面，大幅提升效率。最后，通过Flinto等工具将静态原型转化为可点击的动态演示，让团队或用户能在手机上获得真实的产品体验感受。整套流程强调的是从宏观思路到微观执行的连贯性，通过标准化和工具化，把原型制作从耗时的设计任务，转变为可快速验证产品想法的清晰路径。

本机暂存

IT 设计/ 2014-07-15 23:00:32 / 累计浏览 3,422

Google移动网站设计原则

这篇讲的是Google与AnswerLab联合发布的一份白皮书，专注于移动网站的设计原则。它并非泛泛而谈，而是基于大量真实用户研究，系统性地提炼出了25条具体设计准则。这些准则被归纳到五个核心领域：主页与网站导航、网站搜索、电子商务与转化、表单设计以及整体的可用性与表单因素。文章清晰地指出，遵循这些经过验证的最佳实践，是打造一个既能取悦用户、又能有效驱动商业转化率的优秀移动网站的关键。对于从事移动端UI/UX设计、产品策划或前端开发的朋友来说，这份白皮书提供了一套非常具体的设计检查清单。文内附有百度网盘链接，方便读者获取完整版PDF进行深度参考。

本机暂存

IT DevOps/ 2014-07-15 22:54:53 / 累计浏览 1,720

推动而不是靠拉动

这篇文章从团队协作中的常见现象切入，对比了“被动拉动”与“主动推动”两种截然不同的工作模式。作者通过两个生动的对话场景，描述了在大公司环境里，员工容易养成“等待指令”的习惯——不问背景、不管目标，只求完成分派的任务。这种“工具人”思维在创业团队中则会成为致命短板。核心观点鲜明：创业需要成员具备主人翁意识，主动为项目全盘负责，推动资源与协作，而非被动等待安排。文章指出，推动者最终能驾驭工具，而只会被拉动的人可能永远只是工具。作者还分享了团队推行的实践，比如基于项目的短站立会，以及强制提前沟通延期原因的机制，旨在通过制度帮助成员从“等任务”转向“要资源、明目标、控进度”。这篇短文对技术团队管理者和一线成员都有启发，它点明了在快速迭代的环境里，积极主动的协作文化往往比单纯的技术能力更能决定项目的成败。

本机暂存

IT 前端/ 2014-07-15 22:45:45 / 累计浏览 2,604

网页适配手机移动版的CSS

这篇讲的是用几个关键 CSS 技巧，来解决网页在手机上显示错乱、需要缩放的问题。作者从实际移动端适配场景出发，给出了三个环环相扣的解决方案。首先，要通过添加一个 `` 标签来禁止用户手动缩放页面，确保你的布局能按预设尺寸正常渲染。其次，用一条简单的 `img { max-width: 100% }` 规则，就能防止图片撑破容器，出现讨厌的横向滚动条。最后，对于表格、表单或内容容器，通过设置 `width: 100%` 并结合一个 `max-width`（比如 880px），可以让它们在电脑端保持合适的最大宽度，而在手机上则自动占满屏幕。这三个步骤非常基础但极其有效，分别处理了视口控制、图片响应式和容器流式布局这几个核心问题，是快速实现移动端友好网页的实用清单。

本机暂存