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

最新文章

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

IT 前端/ 2016-02-09 23:08:00 / 累计浏览 2,006

小tip: 子元素scroll父元素容器不跟随滚动JS实现

这篇讲的是前端开发中一个常见的交互痛点:当页面存在嵌套滚动容器时,子元素滚到底后,滚动事件会“冒泡”导致父容器继续滚动。作者从“萝卜蹲”的生动比喻出发,解析了这一浏览器默认行为的链条。 核心方案聚焦于PC端,利用JavaScript拦截鼠标滚轮事件(`mousewheel`或Firefox的`DOMMouseScroll`)。关键思路是:为子元素绑定滚轮事件监听器,当检测到滚动位置即将到达顶部(`scrollTop`为0)或底部(到达最大值)时,手动将滚动位置精确定位到边界,并立即调用`event.preventDefault()`阻止事件继续向上冒泡,从而“切断”父容器的滚动。 文章特别指出了IE浏览器的兼容性“坑”——它会在阻止前直接跳过边界。解决方案是在到达边界的前一次滚动时就介入处理,提前手动设置边界值。作者最终将方案封装成了一个简洁的jQuery插件`$.fn.scrollUnique()`,调用一行代码即可生效,并提供了可交互的在线演示。对于键盘等其他滚动触发方式,作者认为可按需扩展,但鼠标滚轮处理已覆盖主要场景。

本机暂存
IT 后端/ 2016-02-09 23:06:49 / 累计浏览 1,747

skynet 里的 coroutine

这篇讲的是 Skynet 框架如何利用 Lua 协程,将基于回调的消息处理模型,巧妙地转换为开发者更熟悉的阻塞式 RPC 调用风格。 Skynet 本身是一个消息分发器,每个服务通过一个统一的回调函数处理消息。这种异步模型虽然高效,但写起来可能不够直观。文章深入剖析了框架内部的核心技巧:为每条进入的消息创建一个协程,并让消息处理函数运行在其中。当遇到如网络请求等需要阻塞的操作时,处理函数会通过 coroutine.yield 将控制权交还框架,并附带操作类型(如“CALL”)和会话ID。框架挂起该协程,等待结果消息到达后,再根据会话ID找到并恢复对应的协程继续执行。 文章还进一步探讨了更高级的场景:如果开发者想在消息处理中自己使用协程怎么办?此时,用户协程的 yield 会被自己的 resume 捕获,导致 Skynet 的阻塞 API 失效。为此,框架提供了 skynet.coroutine 库。它在用户 yield 的类型前加上一个“USER”标记,从而与框架的内部 yield 区分开来,确保两者能协同工作而不冲突。 作者最后分享了使用协程作为迭代器的实际案例:处理一个巨大的内存操作日志文件时,通过协程实现了流式读取和转换,避免了内存溢出,展示了这一机制在实际工程中的实用价值。

本机暂存
IT 移动开发/ 2016-02-09 23:04:15 / 累计浏览 2,547

自己动手打造基于 WKWebView 的混合开发框架(三)——设计插件协议以兼容 Cordova

这篇讲的是如何从零构建一个基于 WKWebView 的混合开发框架,并重点实现与 Cordova 插件的完全兼容。作者的目标很明确:让你已有的 Cordova 项目能无缝、无感知地迁移到自研的高性能框架上。 核心思路是打通 JS 与 Native 之间完整的双向数据通道。文章详细拆解了实现过程:首先通过 `window.webkit.messageHandlers` 建立了 JS 到 Swift 的传值与调用机制,并用 Console 插件作为示例。接着,为了解决 Swift 向 JS 的异步回调问题,作者设计了一个基于队列(Queue)的管理系统,每次调用将回调函数压栈并传递序号,Native 处理完再凭序号回调,从而完美复刻了 Cordova 的插件调用模式。 文章的巧妙之处在于,作者没有止步于零散的调用实现,而是进一步抽象设计了统一的 `Plugin` 基础类和插件协议。这个协议规范了 JS 层如何封装调用数据(包含 className、functionName、data 及回调 taskId),以及 Native 层如何统一反射、分发请求并管理回调。这使得新增一个兼容 Cordova 的插件变得结构清晰、流程标准。最终,这套设计被整合为一个名为 BlackHawk 的纯 Swift 开源项目,为追求性能与可控性的团队提供了一个切实可行的 Cordova 替代方案。

本机暂存
IT 移动开发/ 2016-02-09 23:02:45 / 累计浏览 2,286

自己动手打造基于 WKWebView 的混合开发框架(二)——js 向 Native 一句话传值并反射出 Swift 对象执行指定函数

这篇讲的是在基于WKWebView的混合开发中,如何让JavaScript(JS)代码直接调用Swift编写的原生功能。作者从WKWebView的一个“屌炸天”的新特性——`window.webkit.messageHandlers`方法出发,演示了JS如何通过`postMessage`这一句话,将字符串甚至JSON对象传递到Native层。 核心的巧妙之处在于,接收到消息后,作者利用苹果开放的runtime接口,通过解析出的类名和方法名字符串,动态反射出Swift对象并执行指定函数。这意味着网页可以按需调用任意预注册的原生方法,极大地增强了混合应用的灵活性。文章提供了从注册消息处理程序、接收数据到最终反射执行的完整代码示例,并配有截图验证了每一步的结果。 作者在此基础上构建了一个名为“BlackHawk”的纯Swift高性能框架,可作为Cordova的替代方案。整个过程将原本可能复杂的跨语言调用,简化为了清晰可循的几步操作。

本机暂存
IT 移动开发/ 2016-02-09 23:01:00 / 累计浏览 2,032

自己动手打造基于 WKWebView 的混合开发框架(一)——WKWebView 上手

这篇讲的是如何从零开始,基于 iOS 的 WKWebView 打造自己的混合开发框架。作者从 WKWebView 的优势切入——它解决了 UIWebView 的内存和性能顽疾,将渲染进程交给系统管理,还支持高达 60fps 的刷新和更直接的 JS 通信方式。 文章是典型的“上手指南”风格,手把手教学。它从最基础的代码示例开始,逐步带你完成初始化、加载网页、解决 iOS 9 默认不支持 HTTP 的 bug,再到实现错误处理和 JS 的 alert 弹窗等核心功能。每一部分都配有具体代码和效果截图,特别适合想了解混合开发底层实现的 iOS 开发者参考。 在教程之外,作者还推荐了一个名为 BlackHawk 的开源项目,它是用 Swift 实现的高性能 Cordova 替代方案。如果你对文章里的基础实现感兴趣,这个项目提供了一个更完整的工业级参考。

本机暂存
IT DevOps/ 2016-02-08 19:55:22 / 累计浏览 2,655

使用reposync同步yum源

这篇技术博客源于一个实际痛点:国内服务器同步Openstack RDO源(repos.fedorapeople.org)时面临速度慢、易中断的窘境。作者尝试使用rsync但发现源服务器未开放该服务后,找到了系统自带的`reposync`命令作为替代方案。 文章清晰地拆解了整个操作流程。首先需要安装`yum-utils`等工具包,其中包含了`reposync`这个Python脚本。接着配置好需要同步的源(如RDO源),通过`yum repolist`获取准确的源ID。核心步骤是使用`reposync --repoid=xxx`命令直接拉取,实测能在本地生成与远程源完全一致的目录结构。最后,作者提到可用Nginx将同步好的本地源对外服务。 这是一个典型的“发现工具-验证解决”的实践记录,对于需要在内网构建私有镜像源或解决跨国仓库同步问题的运维人员来说,提供了一个具体、可复现的命令行级解决方案。

本机暂存
IT 安全/ 2016-02-08 19:50:03 / 累计浏览 2,994

内存寻址原理

这篇讲的是内存寻址的底层原理,作者从网络安全分析中遇到的寻址难题切入,直接点明这是理解漏洞分析和系统行为的关键基础。 文章的核心内容,是对CPU几种工作模式——实模式、保护模式与虚拟8086模式——进行了清晰的对比。它解释了实模式下1MB的寻址限制、所有内存均可直接访问的特性,以及它在系统启动阶段的作用;而保护模式则支持高达4G(32位)的地址空间,并通过段页式机制实现了内存隔离与保护,这是现代操作系统安全运行的基石。 在概念梳理上,文章厘清了逻辑地址、线性地址与物理地址的转换链条。特别是通过一个具体的程序地址实例,逐步拆解了段选择符如何从描述符表中定位段描述符,最终与偏移量相加得到线性地址的过程,让抽象的理论变得可视化。 理解这些寻址细节,对于追踪内存越界、分析指针漏洞以及编写底层驱动都至关重要。文章将计算机体系结构的演进需求与具体的内存管理实现结合起来,为开发者搭建了一个从逻辑地址到物理内存的完整认知地图。

本机暂存
IT 数据库/ 2016-02-07 14:53:24 / 累计浏览 1,344

MySQL运行中被改权限测试

这篇讲的是一个真实的线上踩坑经历。作者的一位朋友遭遇了数据库目录权限被运维人员误改为 root 的紧急情况。为了弄清后果,作者特意搭建了 MySQL 主从环境进行测试。 实验中,将主库目录权限改为 root 后,在触发日志切换(flush logs)之前,主库的数据写入和主从复制似乎一切正常。但关键问题在日志切换时暴露:主库因无权创建新 binlog 文件而报错,而从库虽然收到了新的日志文件名,却无法获取到实际日志内容,导致复制中断。 这个现象有点反直觉:权限错误并未立刻阻塞所有数据操作,却为数据同步埋下了一颗定时炸弹。文章的结论很明确:一旦发生这种情况,主库的数据是最全的,但主从已经失同步。作者最后还附上了修复思路和关于这或许是 MySQL 一个“诡异”行为的思考。

本机暂存
IT DevOps/ 2016-02-07 14:50:29 / 累计浏览 3,139

《火星救援》中你应该知道的5个高可用系统故障恢复原则

这篇文章从电影《火星救援》出发,将主角马克·沃特尼的火星生存挑战,与互联网高可用系统的故障恢复实践做了精彩类比,提炼出了五条关键原则。 作者指出,故障发生时应秉持信息透明原则,及时向内部与外部同步状态,这比隐瞒问题更能赢得理解与支援。面对紧迫的恢复时限,技术负责人需在信息不全的情况下快速决策。在解决过程中,既要鼓励工程师发挥主观能动性积极尝试,也要善于利用系统预留的“救生锤”——比如那些99.9%时间不用的功能开关或旧接口。最后,当常规手段失效时,可能需要像电影里抛弃所有负重一样,采取一些简单粗暴但有效的方法来快速恢复服务,事后再进行数据修复。 文章没有停留在抽象理论,而是紧扣电影情节与技术场景的对应点,比如NASA的新闻发布会对应故障公告,探路者号对应遗留系统,让这些工程原则变得生动可感。文末那个马克在地球喝咖啡的比喻,也巧妙点出了运维人员平凡日常中的珍贵。

本机暂存
IT 算法/ 2016-02-07 14:49:39 / 累计浏览 1,942

Pinterest的Feed架构与算法

这篇讲的是Pinterest如何将首页Feed流从简单的时序排列,升级为高性能、高可用的个性化推荐系统。随着流量增大,约1/3的访问指向Feed页,工程师面临的核心挑战是:如何在保证99.99%可用性的前提下,为每个用户动态生成个性化的高质量内容。 核心方案是一个分层的“Smart Feed”架构。它不再按时间排序,而是按权重优先展示。系统由三个关键服务构成:Feed Worker负责接收新内容并为每个用户独立计算权重,放入优先级队列;Feed Content Generator根据队列生成新的、按优先级排序的Pin流;Smart Feed Service则负责整合新内容与历史快照,确保即使在新内容生成服务异常时,用户也能快速看到历史列表,实现优雅降级。 存储层的设计尤为巧妙。面对海量数据和高写入QPS,Pinterest采用了双HBase集群方案。主集群处理写入,通过异步任务将数据同步到备用集群。读取时则优先从轻量的“物化存储”集群获取历史列表,再与主集群的新内容合并。这一设计不仅优化了读写延迟,更通过跨可用区的备份,将整体可用性提升至99.99%以上。

本机暂存
IT 前端/ 2016-02-07 14:48:29 / 累计浏览 1,056

说说基本的布局观

这篇文章从作者的个人经历出发,用五个串联的小故事,回顾了网页布局观念从模糊到清晰的演进过程。从大学课堂听到“表格布局”、初学时用float解决导航横排,到误解“div+css”是一门技术,再到面试时对“结构表现分离”的懵懂回答,生动展现了初学者可能遇到的典型认知阶段。 作者的核心观点是,网页布局并非指某种特定技术名词(如“表格”或“浮动”),其能力根植于对一系列基础CSS属性的掌握与理解。文章将“盒模型”广义化,强调了width、height、padding、margin、position、display等众多属性才是构成布局控制力的基本单元,而非那些封装好的“方案”或“框架”。 这篇内容特别适合前端入门者阅读。它不追求高深技巧,而是帮助新手厘清基础概念,建立从“容器摆放”到“属性控制”的正确布局观,理解一段有效代码背后的设计意图,避免在学习初期形成片面或错误的认识。

本机暂存
IT 开发者/ 2016-02-07 14:45:35 / 累计浏览 3,048

程序员为什么要学好英语

这篇讲的是程序员英语学习中的一个关键误区。很多人认为程序员只需精通“专业英语”——能看懂技术文档、记住术语就行。但作者从自身经验和教学观察出发,强调学好“真正的英语”至关重要。 核心论点是:只背专业术语,容易将知识当作孤立的“天外飞仙”硬吞下去,难以融会贯通。文章用 cache、buffer、serialize、flatten 这些常见词为例,深入剖析了其英文原意与计算机含义之间的形象联系。比如 cache 原指“隐蔽的储藏处”,恰好对应了缓存隐蔽且加速读取的特性;buffer 原意是“减震垫”,完美解释了缓冲区在数据交互中“防震”的作用。这种理解远比直接记忆中文“缓存”“缓冲”要深刻、有趣得多。 作者指出,许多技术术语都植根于生活经验,英语学习能帮程序员建立这种联系,避免术语成为枯燥的符号。反之,若只守着专业英语或中文资料,会错失知识的来龙去脉,不仅学习效率低,也容易让技术世界显得古怪而乏味。真正的出路在于完整地学习英语,用英语去理解技术背后那片生动的“土壤”。

本机暂存
IT 开发者/ 2016-02-07 14:43:31 / 累计浏览 2,160

为什么我要垂直对齐代码(你也要如此!)

这篇讲的是 HackerNews 上关于 Linux Kernel 代码风格的讨论中,一位开发者为“垂直对齐”代码风格的坚定辩护。作者从一个简单例子切入:未对齐的变量声明与对齐后的版本,后者能让 `bob_age = 250` 这样的异常值一眼就能被捕捉到。 文章的核心论点是,编程工作中有大量时间花费在理解现有代码上,而垂直对齐这种看似微小的格式调整,能显著降低这种“理解成本”。作者类比了代码与散文的阅读区别,强调清晰的代码就像一篇好文章,需要借助命名、间隔等“视觉线索”来提升可读性,让接手代码的人能更快理解意图,而非陷入解密格式的泥潭。 文中还延伸讨论了等宽字体与比例字体的争论,但最终落脚点仍是可读性——任何有助于快速理解代码结构的工具(无论是字体还是对齐)都值得采用。作者用略带调侃的“圣战”口吻,实质上是在呼吁开发者们更多地关注代码的“用户体验”,而不仅是功能实现。

本机暂存
IT 安全/ 2016-02-07 14:41:36 / 累计浏览 2,880

SSL多域名绑定证书的解决方案

这篇讲的是如何在一个服务器上,为多个不同的域名部署HTTPS服务。传统上,一张SSL证书通常绑定一个域名,但在实际运维中,我们常常遇到一个服务器需要同时承载多个域名的情况。文章从这个现实背景出发,梳理了几种主要的解决方案。 最直接的方式是采用虚拟主机技术,为每个域名分配独立的IP地址并绑定各自证书,但这对IP资源要求较高。对于同级子域名,可以申请通配符证书,但它只能匹配二级子域名,无法覆盖更深层级或主域名本身。更灵活的方案是使用支持“使用者可选名字”(SAN)扩展的证书,通过XCA等工具,就能将多个不同的域名都写入同一张证书中。 如果必须为每个域名单独签发证书,那么SNI(服务器名称指示)技术就成了关键。它允许服务器在SSL握手阶段就识别出客户端请求的域名,从而返回正确的证书,实现“单IP、多证书”。文章指出,这项技术已获得主流浏览器和Web服务器的支持,为灵活部署HTTPS提供了坚实的基础。

本机暂存
IT 开发者/ 2016-02-07 14:33:59 / 累计浏览 7,119

谈谈在校程序员技能培养

这是一篇关于在校程序员技能培养的经验分享,作者结合自身从北邮本科到研究生阶段的经历,给出了几条打破常规却很实用的建议。 文章的核心观点是,在校学习的目标不是“好好上课”,而是高效地掌握知识并投入实践。作者通过考前集中复习保证成绩,从而腾出大量时间用于编程实践,这让他在校招中具备明显优势。在技能培养上,他强调要“适度刷题”——算法基础虽重要,但忽视工程细节(如STL容器的内存管理、线程安全)会成为明显短板。对于实习,作者结合自己和身边人的案例,建议不要盲目追求大厂光环,早期进入能深度参与项目的初创公司,往往能获得更扎实的工程锻炼。此外,他提到要关注行业技术趋势,顺势而为比固守个人偏好更重要。 这篇文章源于作者帮助内推时对行业“人才青黄不接”现象的观察,所有建议都来自他一路走来的切身体会。虽然行业形势在变,但其中关于平衡应试与实践、在实习中追求实质成长的思路,对今天的在校生仍有参考意义。

本机暂存
IT 后端/ 2016-02-07 14:32:59 / 累计浏览 1,861

谈谈go语言编程的并发安全

这篇讲的是Go并发安全的一个经典认知误区。作者从修复分布式存储项目Weed-FS中的一个非并发安全问题出发,提交了加锁的PR,却意外被维护者以“单写多读场景不需要加锁”为由拒绝。 这挑战了作者基于C/C++开发经验的常识,促使他深入探究Go内存模型。文章梳理了Go官方建议的核心:对多goroutine访问的数据必须序列化(加锁或使用channel),并引用了社区讨论中的警句——“Don't be clever”。最终,通过go-nuts邮件列表的权威讨论,验证了作者“必须保护”的观点是正确的,维护者也接受了修改。 文章特别指出,许多人存在“每次读取都是原子行为”或“数据竞争最多只是读到旧值”的误解,这其实是非常危险的。作者推荐使用`go run/build/test -race`命令来检测这类难以复现的隐患,并提醒大家,即使程序运行正常,也不代表没有并发问题。

本机暂存
IT 移动开发/ 2016-02-07 14:26:58 / 累计浏览 1,648

iOS JSON 模型转换库评测

这篇评测文章从实际开发需求出发,对 iOS 平台常用的六个 JSON/模型转换库进行了横向对比。评测覆盖了手动转换(Manually)、YYModel、FastEasyMapping、JSONModel、Mantle 和 MJExtension 这几个主流选择。 文章的核心围绕三个维度展开:性能、功能与容错性。在性能测试中,作者使用了两个典型用例(一个简单的 GitHub User 数据,一个复杂的微博数据),给出了直观的耗时对比图表。结论非常明确:YYModel 的性能显著领先,甚至接近手写代码的效率;Mantle 的性能在对比中最弱;JSONModel 和 MJExtension 处于中间水平。功能上,各库各有侧重,比如 FastEasyMapping 支持 CoreData,但使用者较少。 容错性测试则揭示了更实际的开发体验差异。YYModel 和 Mantle 会进行类型检查以避免崩溃,但处理策略不同:前者尝试自动转换并在失败时留空,后者直接终止转换并向上报错,更利于调试。MJExtension 在自动转换失败时可能直接赋值不匹配的类型,存在潜在风险。 总的来说,文章为开发者选择库提供了清晰的参考:追求极致性能可以看 YYModel,注重稳定和调试体验可考虑 Mantle,而 MJExtension 和 JSONModel 则是在功能与易用性上的常见折中选择。

本机暂存
IT 移动开发/ 2016-02-07 14:25:11 / 累计浏览 1,636

YYCache 设计思路

这篇讲的是作者从实际需求出发,设计高性能iOS缓存库YYCache的思考过程。他对比了NSCache、TMMemoryCache、PINMemoryCache等主流内存缓存实现,发现它们在性能或功能上各有不足,于是YYMemoryCache采用了OSSpinLock保证线程安全,并实现了LRU淘汰算法,在基准测试中性能表现突出。 针对磁盘缓存,文章分析了基于文件、mmap和SQLite三种技术路径的优劣。作者指出SQLite在存储小数据时性能更优,且便于实现元数据管理和淘汰策略,因此YYDiskCache采用了SQLite结合文件存储的混合方案,在实测中兼顾了性能与功能。 最后,作者还对比了Realm与SQLite的性能差异,并提到Realm会向外部IP发送数据,建议开发者谨慎使用。整篇文章从技术选型到性能评测,为iOS开发者选择和构建缓存方案提供了详实的参考。

本机暂存
IT 移动开发/ 2016-02-07 14:23:53 / 累计浏览 2,591

移动端图片格式调研

这篇技术调研从移动端流量与视觉体验的双重痛点出发,系统梳理了从老牌JPEG、PNG、GIF到新兴WebP、APNG、BPG的多种图片格式。作者不仅对比了它们在压缩率、透明通道、动画支持等方面的核心差异,更深入到Android与iOS底层编解码架构(如Skia、ImageIO)和具体开源库(如libjpeg-turbo、MozJPEG)的性能剖析。 文章的亮点在于其扎实的实测数据。通过在iPhone 6上对典型图形与照片素材进行编解码测试,直观呈现了不同格式在文件体积、处理速度上的权衡。例如,JPEG在quality 0.9时达到较好的质量与效率平衡;PNG处理照片类图片时体积和速度明显逊色;而WebP凭借其全能特性和广泛的应用,已成为移动端优化的重要选择。 对于关注移动端性能优化的开发者来说,这篇文章提供了清晰的选择指南:WebP是当前均衡且普及的解决方案,APNG在动图上优于GIF,而高压缩比的BPG则代表了未来方向,尽管其仍受版权与计算成本制约。

本机暂存
IT DevOps/ 2016-02-07 14:18:12 / 累计浏览 2,164

用GDB排查Python程序故障

这篇讲的是一个团队在Python程序非预期退出时,尝试用GDB调试解释器,但作者提供了更高效的排查思路。 团队开发的Python程序涉及子进程管理,遇到了非预期退出。最初的调试方向是用GDB追踪Python解释器中的`exit()`调用,但作者认为有更合适的切入点。文章通过一个精简的代码案例(`DebugPythonWithGDB_6.py`)重现了问题:父进程在信号处理函数`on_SIGCHLD`中尝试用`os.waitpid()`回收子进程时,抛出了`OSError: [Errno 10] No child processes`。 作者深入剖析了根因。问题出在复杂的信号与进程交互时序上:当`os.system()`产生的子进程退出并触发`SIGCHLD`信号时,该信号处理器正中断另一个子进程的处理流程。此时在信号处理器中再次调用`waitpid()`,可能因子进程已被其他地方的`wait()`回收,导致系统调用失败,Python将其封装为异常。 文章不仅展示了问题现象,还通过伪代码梳理了`os.system()`底层(从`posix_system`到`do_system`)对信号的处理逻辑,揭示了`SIGCHLD`信号在关键路径被阻塞又释放的微妙过程。它提供了一个可复现的竞争条件案例,对于理解Python子进程管理、信号处理陷阱有很好的参考价值。

本机暂存