IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

最新文章

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

IT 算法/ 2013-08-13 13:08:27 / 累计浏览 7,338

Python程序的执行原理

这篇讲的是Python代码从源文件到运行背后的核心机制——字节码与虚拟机如何协同工作。文章从最简单的“Python先把代码编译成字节码”这一概述出发,层层深入,带我们看清了执行过程的每个关键环节。 作者详细拆解了字节码在Python内部的具体形态——PyCodeObject对象,并剖析了其结构体定义,如co_code、co_consts等字段如何承载代码信息。对于开发者日常可能遇到的.pyc文件,文章也理清了它的生成时机(模块import时)与Python的加载更新策略,解开了不少常见疑惑。 文章的精彩之处在于将理论落地到可操作的层面。它展示了如何利用内置的compile函数和dis模块,去实际“解剖”一段代码对应的字节码指令序列,让抽象概念变得可视、可调试。最后,文章将视角拉升到虚拟机执行层面,通过类比X86的栈帧,讲解了Python如何通过PyFrameObject管理函数调用和作用域,完整模拟了一个程序的运行世界。 整篇文章就像一份精心绘制的内部结构蓝图,不仅告诉你Python“怎么做”,更展示了它是“如何做到”的,非常适合希望突破语法层面、理解Python执行本质的开发者。

本机暂存
IT 数据库/ 2013-08-13 13:06:59 / 累计浏览 1,679

国际商品编码EAN-13介绍

这篇讲的是我们身边无处不在的商品条形码背后的技术标准——EAN-13。文章深入剖析了这个全球通用编码的内部结构。一个标准的EAN-13码由13位数字构成,包含了国家代码、厂商代码、产品代码和检查码。其巧妙之处在于,为了便于机器可靠读取,它并非简单对应,而是有一套精密的编码规则。 具体来说,最左边的第一位数字作为“导入值”,本身不印出条纹,但它决定了紧随其后的六位数字(左资料码)采用A类还是B类的编码模式。左、右资料码之间还通过“中线”这个特殊标识分隔开。右资料码则统一采用C类编码。文章详细列举了A、B、C三类编码各自的逻辑值转换规则,这些由细黑线和细白线组合成的不同图案,最终构成了扫描枪能够精准识别的条形码。 这种多层级、有变化的编码设计,确保了即使从左到右扫描,机器也能准确无误地读取信息,理解了这套规则,就明白了超市扫码器“嘀”一声背后运行的逻辑。

本机暂存
IT 前端/ 2013-08-13 13:05:47 / 累计浏览 2,028

我的博客系统折腾手记暨papery正式发布

作者为了根治自己的代码洁癖,将一个最初用几个零散 Node.js 脚本搭建、丑陋且通用性差的个人博客系统,彻底重构为名为 papery 的通用博客生成器。这个过程源于微博上朋友们的询问,促使他花了一个周末集中解决积累已久的痛点。 重构的核心方案是明确区分通用与特化功能,并引入现代化开发体验:通过 npm 实现一键安装和升级;用 EJS 模板引擎替代手工 HTML 拼接;采用 YAML 作为更简洁的配置文件格式;新增命令行工具以一键创建博客并启动本地调试服务器。作者还充分利用了 Node.js 社区的成熟组件(如 js-yaml, connect 等),避免重复造轮子,最终目标是让代码变得清晰、优雅且易于扩展。 目前 papery 已开源在 GitHub 和 npm 上,作者自己的博客便是用它生成的。作为一个新项目,它可能尚不完美,但已切实解决了作者的痛点,实现了从“凑合能用”到“清晰好用”的转变。

本机暂存
IT 前端/ 2013-08-13 13:04:31 / 累计浏览 1,772

javascript继承机制

这篇讲的是 JavaScript 中实现继承的两种经典机制:构造函数继承与原型继承。作者从具体的代码示例出发,清晰地展示了 `Animal.apply(this, arguments)` 这种构造函数继承如何复用父类构造函数中的属性,同时点明了它无法继承原型方法的局限性。 文章的核心在于对比。它指出,如果使用 `class.prototype = new parent_class()` 的原型继承方式,则能同时继承父类构造函数和原型上的属性与方法。此外,文章还细致地区分了 `call` 与 `apply` 在传参方式上的不同,并通过反例(如在构造函数内使用 `this.prototype`)强调了原型继承的正确写法。 最后,作者给出了一个精炼的总结:根据是否需要继承原型方法来选择继承方式——若只需构造函数内的成员,用 `apply/call`;若需要原型链上的完整继承,则用原型赋值。这种对比式的讲解,帮助开发者快速理解不同继承模式的核心差异与适用场景。

本机暂存
IT 后端/ 2013-08-13 13:04:08 / 累计浏览 5,735

谈谈Facebook的聊天系统架构

这篇讲的是Facebook在2009年公开的聊天系统核心架构。作者从一份内部PDF中的架构图出发,清晰地拆解了支撑数亿用户实时聊天的四个关键模块及其设计考量。 整个系统分为Web Tier(用PHP处理业务逻辑)、Chatlogger(C++开发的消息存储层)、Presence(C++编写的在线状态服务)以及Channel Cluster(基于Erlang和Mochiweb开发的服务器推送通道)。作者着重分析了每个模块的选型逻辑:Chatlogger需要应对海量历史数据,因此依赖Cassandra/HBase;Presence将用户在线状态全部存于内存以追求极致性能;Channel Cluster则通过保持长连接和本地缓存在线列表,实现了高效的实时推送,并减轻了Presence的压力。 文章不仅解释了“是什么”,还点明了“为什么”——例如为什么Presence不用PHP+Redis,为什么Comet服务器需要做二次开发。作者最后总结道,这个架构设计本身已经非常清晰透彻,但在实际应用中,仅靠整合现有开源组件远远不够,必须根据自身技术栈进行深度定制和二次开发,才能应对真正的规模化挑战。

本机暂存
IT 开发者/ 2013-08-12 13:56:31 / 累计浏览 6,812

十五个只有程序员会乐的事情

这篇合集收集了十五幅只有程序员才会会心一笑的漫画,用幽默的方式刻画了程序员独有的工作场景与日常体验。从标志性的“大水杯”、项目开始与结束时的鲜明对比,到用编程语言改写爱情故事,作者敏锐地捕捉到了那些潜藏在代码、调试与产品迭代背后的微妙情绪。 这些段子的笑点往往建立在共同的技术语境之上——无论是浏览器兼容性的困扰、项目状态在“开始”与“完成”之间的漫长徘徊,还是将祈求服务器稳定的姿势变成一种仪式。它们不仅描绘了熬夜调试的疲惫、面对需求变更的无奈,也轻松地调侃了程序员特有的表达方式与生活痕迹,比如用二进制纹身。 文章没有深奥的分析,而是通过这种轻松自嘲的漫画集,为技术读者提供了一面共鸣的镜子,也为非技术读者打开了一扇理解程序员幽默感的窗户。它本质上是一次对程序员文化的趣味性扫描,让那些淹没在逻辑与字符中的情感变得可见而可爱。

本机暂存
IT 数据库/ 2013-08-12 13:54:40 / 累计浏览 3,410

云和恩墨版Oracle Database 12c 最新体系结构图下载

这篇分享的是云和恩墨精心制作的Oracle Database 12c体系结构图。该图最早于2013年甲骨文全球大会上发布,历经多达43个版本的反复修订和打磨,旨在为技术爱好者们提供一份准确、清晰的数据库架构全景参考。其细节之处凝结了团队深厚的技术研究与精益求精的态度。 如今,这份高质量的架构图已开放电子版下载。文章直接提供了Windows版压缩包以及适配Mac不同分辨率(1280X800与1920X1080)的JPG图片下载链接,方便不同平台的用户使用。对于这样一个持续迭代的专业成果,作者也开放了反馈通道,欢迎读者指出任何可能存在的错误或问题,以便在后续版本中进行更正与完善。

本机暂存
IT 开发者/ 2013-08-12 13:52:33 / 累计浏览 4,510

数据即代码,我和小伙伴们都惊呆了!

这篇文章从一个实际的技术需求——设计命令行参数解析API出发,对比了几种从简单到复杂的代表性方案。作者以“小伙伴们”的视角,先点评了C语言经典的getopt()函数,它功能基础,只能处理单字符选项,面对复杂场景力不从心。接着是Google的gflags,通过宏定义选项,好用但能力有限。然后探索了Ruby Commander和Lisp cmdline库,它们语法炫酷、功能强大,却也因复杂或晦涩增加了学习成本。 对比最终聚焦到Node.js的LineParser库。仅仅用一个结构清晰的JSON对象,就完整定义了程序信息、子命令、各类选项及默认值、多种使用模式,并支持自动生成帮助信息。这种“数据即代码”的设计,不仅实现了前面几种方案的大部分甚至全部功能,更难得的是直观、易懂。文章通过这个探索过程,清晰展现了命令行解析从过程式、宏到数据声明式的演进,其核心启示在于:优秀的API设计,有时恰恰是让复杂逻辑回归到简洁、直观的数据描述中。

本机暂存
IT 设计/ 2013-08-12 13:38:52 / 累计浏览 1,588

如何跨岗位盯人

这篇讲的是一位产品经理在资源有限、项目非重点的情况下,如何推动跨岗位协作的困境与反思。 作者列举了自己过去一年尝试的多种方法:从试图用共同目标建立共识,到协调研发资源、对UI“软磨硬泡”,甚至不得不使用考核时间“威胁”或“装可怜”。这些努力收效甚微,他感到除了“磨嘴皮”和“假传圣旨”外束手无策,最终将问题归因于公司流程与体制。 文章真正的价值在于后续的犀利观点。作者指出,大型组织中的跨职能协作常沦为“又一个单子”,缺乏“作品感”与认同。他认为,“人越多,效率越低”是难以根治的“体制之疮”,唯有项目处于高速上升期带来的兴奋感能暂时凝聚团队。此外,他强调产品经理应身兼多职,具备UE甚至测试技能是基本功,不能依赖资源。最后,文章列举了产品岗位的几种核心苦恼,将“跨岗协调”的难题置于一个更广阔的语境中。 对于所有在矩阵式组织中推动项目的产品、运营或项目经理而言,文中对“体制困境”的剖析和“产品经理应是多面手”的论断,或许能带来一些共鸣与思考。

本机暂存
IT 后端/ 2013-08-12 13:35:58 / 累计浏览 2,161

天猫导航的内部机制揭秘

这篇讲的是天猫搜索结果页上方那个看似简单的导航栏,其背后的智能推荐机制。 文章从一个常见场景切入:当用户搜索意图不明确时,导航区的类目和属性推荐就成了帮助他们找到商品的关键。作者务达揭示,这些导航项并非静态存储,而是通过算法动态生成和排序的。 具体来说,导航分为类目导航和属性导航,其推荐逻辑依赖于离线生成的词表。核心算法基于每个(Query,搜索类目)对的点击、成交和商品数数据,进行线性加权排序,决定展现哪些类目/属性以及它们的排列顺序。例如,属性推荐就细分为根类目、公共类目和叶子类目下的属性,当某个属性分数占比极高时,会直接进行“属性预选”展示。 整套系统每天承载着约3000万PV的展现量,是天猫搜索导购链路中的重要一环。文章将智能导航的架构、排序算法以及具体的展现逻辑梳理得清晰透彻,揭开了这个常见却容易被忽视的功能背后的技术面纱。

本机暂存
IT 算法/ 2013-08-12 13:35:08 / 累计浏览 4,418

淘宝搜索中Query下拉推荐技术

这篇讲的是淘宝搜索下拉推荐系统如何从基础算法演进到更智能的方案。下拉推荐能帮用户快速明确搜索意图,是提升搜索体验的关键。 文章从最基础的基于查询词历史PV的推荐策略说起,指出其存在长尾覆盖不足、推荐结果语义重复以及低质或作弊查询容易被推高排序等问题。为解决这些问题,作者介绍了两轮核心迭代:第一步,引入“查询词静态分”这一综合质量指标,它融合了流量、点击、交易转化等多维度数据,用它来排序,能让交易质量高的查询词获得更多机会,有效打压了作弊查询。第二步,则进一步建立了搜索词与候选查询词的动态联系,通过CTR预估模型来预测用户对推荐词的点击率,模型综合考虑了搜索词与候选词的内容相关性、类目匹配度以及结果页特征等,让排序更具个性化和预见性。 文章最后还提到了拼音搜索、拼写纠错、作弊清理及个性化等进阶方向,展现了淘宝搜索推荐系统从简单排序到多维度、动态智能化的完整演进路径。

本机暂存
IT 开发者/ 2013-08-12 13:34:04 / 累计浏览 4,224

做一个不喊爸不喊妈的程序员

作者从亲身经历的项目攻坚阶段出发,聊了聊程序员解决问题能力的几个层级。在无休止的加班、不合理的版本发布和各种“扯淡想法”的挤压下,他观察到面对BUG时,同事们的行为可以粗略分为四类:从最基础的“出现异常立刻汇报”,到“描述清晰文字”,再到“分析日志并推测”,直至最高阶的“尝试自己修复并验证”。他认为前两种本质上是在将问题转移给上级或同事,看似省力或“有益于项目”,实则会阻碍个人追踪能力与自信心的成长,并可能在团队中形成不良的依赖效应。 文章的核心观点并非强调技术细节,而是指向一种职业态度:倡导程序员在遇到问题时,首先应尽力独立分析与解决,而非习惯性“向上求助”。在当今强调工程效能与个人Owner意识的背景下,这种“不喊爸不喊妈”的独立解决问题的精神,或许是比单纯的技术积累更基础、也更关键的职业素养。

本机暂存
IT 后端/ 2013-08-12 13:33:06 / 累计浏览 3,369

Java环境变量设置

这篇讲的是Java开发环境搭建的基础操作,作者从配置环境变量到运行第一个程序,演示了一个完整的入门流程。 文章核心是手把手教新手设置JAVA_HOME、PATH和CLASSPATH这三个关键变量,步骤拆解得很细,包括从系统属性入口到具体变量值的填写都有截图说明。特别贴心的是,作者预判了初学者可能卡壳的地方,比如强调命令行切换目录的正确方式,以及源文件命名必须与类名严格一致。 之后用经典的HelloWorld例子串联起来,展示了编译和运行的全过程,让抽象的环境配置变得可感知。最后还简单解释了这三个变量各自的作用,帮助读者不仅知道“怎么做”,也理解“为什么”。整体节奏清晰,非常适合刚接触Java的朋友跟着操作。

本机暂存
IT 算法/ 2013-08-12 13:32:35 / 累计浏览 4,608

Learning to rank在淘宝的应用

这篇讲的是淘宝搜索排序系统如何从传统手工调参进化到机器学习自动化调整的实践。作者从排序优化的核心难点切入:传统方法依赖人工特征调优和反复AB测试,效率低且难达最优。为此,团队在已有特征体系上应用了Learning to Rank技术,项目内部命名为Jazz。 其核心方案是采用pairwise方法来构建训练数据,但做法很有淘宝特色:没有像常规那样做耗时耗力的人工标注,而是直接利用用户的点击和购买行为数据自动生成商品对。同时,为了保证排序稳定性,还混合了部分原始排序的样本进行分层抽样。模型训练后,通过计算NDCG指标在线下评估效果,显著缩短了测试周期。 文章详细拆解了从数据生产、模型训练到效果评估的全流程架构,并坦诚分析了pairwise方法在具体实施中遇到的挑战,比如与传统论文中描述不同的样本构建思路。这种将工业级实践与算法原理结合的分享,清晰地展示了机器学习技术如何解决真实业务中的复杂排序问题。

本机暂存
IT AI/ 2013-08-08 23:43:47 / 累计浏览 2,087

如何有效的进行道歉

这篇来自外刊IT评论网的文章,探讨了有效道歉的结构和方法。作者从道歉在人际关系中的不可避免性切入,指出真诚道歉是化解伤害、修复关系的最佳途径。 文章核心引用了人类学家Gary Chapman提出的“五种道歉表达”:表达悔恨、承担责任、给予补偿、真诚忏悔与请求谅解,为不同错误场景提供了清晰的行动框架。同时,结合Heidi Grant Halvorson的观点,文章强调了有效道歉的关键——必须将焦点从自己(如意图和感受)完全转向受害者,明确理解并回应对方所受的影响与需求。 更深层地,文章将道歉视为一种“关键交流”和“为改变而做的宣言”。它引述《关键交流》一书的观点指出,真正的道歉需要内心真实的转变:放弃挽回面子、坚持自己正确或强调初衷的冲动,承认错误并做出改变。这种“牺牲尊严”的过程,最终会换来关系和睦与个人成长的双重回报。 道歉不仅是一种生活技能,更是对所有人际关系的长期投资。

本机暂存
IT 设计/ 2013-08-08 23:42:42 / 累计浏览 2,557

APP「返回键」的进化

这篇讲的是APP里那个小小的“返回键”背后,其实藏着产品设计的核心问题之一——导航与流程。作者从一个有趣的观察切入:最近几年,这个按钮本身正在悄悄“进化”。 他指出了两个显著的趋势。一是位置的移动:从经典的左上角,挪到了更方便单手触及的左下角,比如淘宝和知乎日报。作者认为,这背后是手机屏幕越来越大、越来越难以单手掌握的硬件变化在推动设计改变。二是交互方式的革新:手势操作,尤其是向右滑动返回,正逐渐成为一种更高效的选择,知乎、豆瓣小组等应用已在采用。这显然比精准点击一个按钮更流畅。 文章也点出了其中的矛盾与思考:比如在iOS上,右滑手势可能与列表项的删除操作冲突。而Android早期因物理返回键的坚持,其平台内的返回体验曾长期不够统一。作者没有给出标准答案,而是呈现了这种进化如何平衡平台规范、硬件条件和用户效率——返回的体验,依然在持续演进中。

本机暂存
IT 设计/ 2013-08-08 23:41:57 / 累计浏览 1,596

设计师,别急着打开设计软件

这篇讲的是设计师(或任何职场人)面对需求时的一种常见误区和更职业的工作路径。作者从观察团队里一位年轻 UI 设计师的坏习惯出发:拿到需求就立刻埋头用 Photoshop 作图,结果常常做出与需求不符的方案,却说不清设计背后的逻辑。 作者认为,一个优秀的职业流程应该倒过来。第一步不是打开软件,而是花时间真正理解需求:需求的具体意图、背后的商业目标、想传递给用户的核心信息是什么。紧接着,是主动与需求方核对理解,澄清疑问,而非闷头执行。 在明确了“为什么做”之后,设计师才应进入构思环节:根据需求梳理页面信息的逻辑与优先级,决定如何突出重点、排除干扰。之后,再基于逻辑去脑补合适的视觉表现方式——版式、色彩、字体等。直到所有思考都清晰了,才是打开软件制作,并在过程中保持沟通。 文章进一步指出,这种“先搞清目的,再动手执行,并持续沟通”的思路,本质上是一个人是否“职业”的体现,它同样适用于产品经理、运营和开发者。这种对“目的”的强调,是许多职场人容易忽略的底层逻辑。

本机暂存
IT 设计/ 2013-08-08 23:36:28 / 累计浏览 4,942

人人都能用的10条网站易用性技巧

这篇讲的是 WebAIM 团队总结的 10 个基础但关键的网站易用性技巧。作者通过一系列实用建议,展示了如何用相对简单的代码改动,让网站对屏幕阅读器用户更友好,同时也提升了普通用户的交互体验。 文章从最基础的给 Logo 添加替代文本(alt 文本)讲起,这是保障图片信息可访问的第一步。接着深入到了更结构化的层面,比如建议使用 ARIA Landmarks 为页面模块添加语义化角色,帮助辅助技术理解网页布局。对于容易被开发者忽略的焦点样式(focus),文章强调了保留并自定义它的必要性,以服务依赖键盘导航的用户群体。 此外,文中还涵盖了定义表单必填项、合理使用 HTML 标签(如为表格添加 th 表头和 caption 描述)、避免使用“点击此处”这类模糊链接文本,以及警惕 tabindex 属性滥用等具体实践。文章最后推荐了一个在线检测工具,方便开发者快速扫描自己的网站是否存在易用性问题。整篇文章用词直接,配有示例代码,可操作性很强。

本机暂存
IT 设计/ 2013-08-08 23:33:41 / 累计浏览 1,874

禁用状态二三事

设计师常常面临一个两难选择:禁用状态是该固定展示以建立用户认知,还是该隐藏以保持界面清爽?这篇从菜单、工具栏等具体场景切入,深入探讨了禁用状态的展示哲学。文章对比了 Chrome 和 Firefox 处理前进按钮的不同策略——前者保持按钮位置固定以形成操作惯性,后者则根据可用性动态显示,以换取界面的轻量简洁,两者各有其适用场景。 对于更复杂的列表操作,如 Gmail 和 Dropbox 所示,在未选中对象时隐藏专属操作,能在保持工具栏清晰的同时避免禁用项堆积。在引导性更强的表单发布场景,文章对比了新浪微博(禁用按钮仍可点击并给出反馈)与 Facebook(禁用按钮静默不响应)的不同做法,指出按钮的视觉状态应与其实际行为严格一致。 最后,文章总结了四条实用的设计建议:在需要引导用户时,可以考虑去掉禁用;必须使用禁用时,需确保样式区分足够明确;当禁用状态出现得突然时,应提供清晰的解释;甚至可以像 Twitter 和 Flickr 那样,为禁用状态注入动画或趣味文案,使其传达更丰富的信息。

本机暂存
IT 设计/ 2013-08-08 23:32:40 / 累计浏览 2,310

谈谈页面停留时间

这篇从内部同事常问的“页面停留时间”指标入手,解释了它的概念与计算逻辑。作者指出,尽管主流分析工具都会计算这个指标,但受限于日志采集的原理,我们无法得知用户真正的“离开”时间。实际采用的方法是用“打开下一个页面的时间”作为近似替代值。 文章用一个具体的用户浏览路径示例来说明计算过程:从进入淘宝首页,到多次搜索、浏览商品页,每个页面的停留时间实际上是用下一个动作的时间戳减去当前页面的时间戳。比如搜索结果页的停留时间,就是计算从打开它到打开第一个商品页的间隔。这种基于点击流数据的计算方式虽然存在误差(比如用户可能同时打开多个标签页),但仍然是评估页面吸引力和内容质量的最常用基准。

本机暂存