笨狗又一窝 -- IT技术博客大学习 -- 共学习共进步！

首页 / 笨狗又一窝

IT 2019-03-26 09:52:05 / 累计浏览 2,140

折腾 Python logging 的一些记录

这篇讲的是 Python logging 模块的深度“折腾”与实战技巧。作者从 logging 的官方流程图和源码出发，清晰地拆解了从日志请求发出，到经过 Logger、Filter、Handler 层层处理，最终格式化输出的完整链路。文章的亮点在于，它没有停留在理论层面，而是基于对这套机制的理解，分享了如何巧妙地扩展功能。比如，利用 Filter 不仅能过滤还能**改写** LogRecord 的特性，为日志添加了项目相对路径（`relpath`）。文章也指出了配置中的一个“坑”：自定义 Filter 无法通过 `fileConfig` 文件配置，必须使用 `dictConfig` 或 Python 字典。更进一步，作者将这套扩展思路应用到了实际工程中。通过 Filter 动态地向 LogRecord 注入上下文，成功地为 Flask 请求和 Celery 任务日志串联上了关键的 `request_id` 和 `task_id`。文章还提到了用装饰器自动记录函数调用参数与返回值，并处理了其中容易出错的日志定位问题。整体而言，这不仅是一次对 logging 内部机制的剖析，更是一份如何将其“驯服”并服务于复杂应用场景的实践指南，对想深入理解或定制 Python 日志系统的开发者很有启发。

IT 2017-02-20 00:16:04 / 累计浏览 1,280

2016 年度盘点（完整版）

这篇年度盘点里，作者分享了2016年在家庭、工作和生活上的多重变化与思考。技术篇幅主要围绕一次漫长而曲折的前端重构：最初目标只是将大型CSS文件变量化，却在过程中发现选择器与逻辑混乱，最终演变为前后端代码的全面重写。文章详细描述了项目如何因过度设计、人员变动和实际复杂度而一度失控，又如何在下半年通过聚焦功能完成、样式适配与浏览器兼容，最终在年末成功上线。在工作层面，除了代码实践，作者也坦诚地谈到团队管理上的学习——认识到只注重过程不够，结果才是关键，同时也需要提升沟通技巧。生活方面，记录了新房装修、孩子莫莫出生带来的重心转移，以及由此引发的消费观念转变：败家重心从个人数码产品（如为家人购置红米手机、小米空净）转向家庭开支与育儿投入。整体而言，这不仅是一份技术项目的复盘，更像是一位开发者对工作与生活平衡的观察。作者在结尾反思了理财与买房决策，流露出对“结果导向”与“人生自主”的朴素理解，让技术人的年度总结多了几分生活温度。

IT 2016-02-12 17:49:23 / 累计浏览 1,380

OS X 下好用的磁盘空间分析工具: ncdu

这篇讲的是在 OS X 下分析磁盘空间占用的两个选择：一个是界面精美但需要付费的图形化工具 Daisy Disk，另一个是免费、命令行风格的替代品 ncdu。作者从不想为软件付费的“抠门”心态出发，找到了 ncdu 作为解决方案。文章将两者做了对比：Daisy Disk 用环形图直观展示空间占用，体验优秀；ncdu 则在终端运行，用键盘操作，是“命令行版的 Daisy Disk”，更符合极客口味，但扫描时不会智能跳过挂载点，需要手动添加排除参数。文章的核心是提供了 ncdu 的实用指南：通过 `brew install ncdu` 即可快速安装。使用时，简单的 `ncdu ~` 可以分析个人文件夹，而扫描整个系统盘或外部硬盘时，则需要用 `ncdu / --exclude /Volumes` 这样的命令来排除干扰。最终，作者认为两者各有适用场景：习惯图形界面的用户可以选择购买 Daisy Disk，而偏好命令行或预算有限的用户，ncdu 是一个高效且免费的得力工具。

IT 2015-11-02 22:26:19 / 累计浏览 3,060

git 查看文件修改记录

这篇讲的是，当接手了几年前的历史代码，想追查某行逻辑的修改记录时，`git log` 可能不够用。作者分享了自己从 `git log -p` 到熟练使用 `git blame`，最终定位到“问题代码”最初引入版本的全过程。文章指出，单纯用 `git log` 只能看提交摘要。加上 `-p` 参数才能看到具体修改内容，但这对于长期演进的文件依然不够精准。真正的利器是 `git blame`，它能标注每一行最后的提交。通过 `-L n,m` 参数，可以只查看特定行范围的修改历史。更关键的是，文章演示了一套“链式追溯”技巧：用 `git blame` 找到某行的最近一次修改提交，再进入该提交查看对应行号，然后以此提交号和行号为新起点，再次执行 `git blame`，如此循环往复，便能沿着代码的修改路径，一路回溯到最初被引入的那个提交。作者建议配合 Source Tree 等图形化工具查看具体的代码 Diff，让这个追溯过程更直观。

IT 2014-12-10 23:19:02 / 累计浏览 9,080

【2014年版】异地购房提取北京公积金

这篇讲的是作者离职后异地购房，如何提取北京公积金的完整实操经历。文章从个人“踩坑”出发，梳理了从账户状态确认、材料准备到现场办理的全流程。作者首先发现自己的公积金账户已被原单位挂靠的中智公司“集中封存”，导致无法线上处理。朝阳管理部电话长期打不通，最终通过拨打北京公积金中心客服热线010-96155，获取了清晰的材料清单，包括购房合同、发票、身份证、结婚证，以及针对已离职人员的关键文件——异地购房证明和社保缴纳明细。文章详细记录了如何与购房地居委会沟通开具证明，并分享了自己拟定的证明模板。现场办理时发现，正是因为账户处于“封存”状态，才得以以个人名义直接前往公积金中心办理，避免了通过单位的繁琐流程。作者在文中对比了南北方办事效率的差异，并总结了多条实用提示：优先查询官方网站、耐心拨打官方客服电话、利用在线问答渠道获取准确信息。整体是一份信息扎实、充满细节的“办事指南”式经验复盘。

IT 2014-11-25 23:08:47 / 累计浏览 4,260

OS X 支持 NTFS 读写

这篇讲的是如何用系统原生的方式，让 Mac 对 NTFS 格式的硬盘支持读写功能。作者从一个常见情况切入：明明 OS X 内核支持 NTFS 读写，但系统默认却只以只读模式挂载，导致很多用户需要借助第三方软件才能向 NTFS 分区写入数据。文章的核心方案是直接修改系统自带的挂载脚本。通过 root 权限将原始的 `mount_ntfs` 程序重命名，并创建一个新的脚本文件，在其中调用原始程序并强制添加读写（`rw`）参数。这个方法绕过了第三方工具，利用了系统自身潜藏的能力。作者在最后也提醒了两个实操要点：一是建议 NTFS 分区最好设置卷标，避免因默认的“未命名磁盘”导致挂载失败；二是指出网上流传的添加 `nobrowse` 参数的做法其实多此一举，正确理解 `-o` 参数的含义后，完全可以让分区正常显示在 Finder 侧边栏，无需额外折腾。整个方案简洁直接，适合希望用最小改动实现原生读写的 Mac 用户参考。

IT 2014-11-24 23:41:42 / 累计浏览 7,620

也说 Mac 的不好

从Windows阵营转投Mac后，作者经过三个多月的深度使用，坦诚分享了一系列“水土不服”的痛点。文章并非泛泛而谈，而是直击几个核心的体验落差与技术细节。字体渲染是首要槽点。作者指出，在非Retina的外接显示器上，Mac的字体渲染效果远不如Windows下的微软雅黑清晰，显得“糊”。这背后是苹果尊重字形原始结构的技术路线，与微软为液晶屏优化的渲染策略的根本差异，而前者在普通分辨率下优势尽失。此外，MacBook Pro键盘缺少PageUp/Down、Home/End等物理按键带来的效率损失，以及外接键盘后Home/End键“移动到文稿首尾”而非“移动到行首行尾”的默认逻辑，都与PC用户的习惯严重冲突。作者不仅提出了用Fn组合键过渡，还提供了通过编辑`DefaultKeyBinding.dict`文件进行系统级键映射的进阶方案。对于F11/F12等被系统默认功能占用的全局快捷键，作者提醒需要手动到“系统偏好设置-键盘-快捷键”里逐一排查和重新分配。整篇文章像一份来自前线的实战报告，把那些看似“奇葩”的问题掰开揉碎，给出了可操作的解决思路。对准备或刚刚入手Mac的用户来说，这份基于真实踩坑经验的总结，能帮助他们更平滑地跨越系统切换的初期障碍。

IT 2014-11-24 23:37:41 / 累计浏览 4,840

Mac 锁屏的各种方法

从 Windows 转到 Mac 后，一个不起眼但让人头疼的问题浮现：找不到那个顺手的“Win+L”锁屏快捷键。作者从这个切身痛点出发，系统梳理了多种尝试方案，并分析了它们各自的“坑”。像合上盖子或短按电源键，虽然常见，但它们实际触发的是“睡眠”而非“锁屏”，会导致网络断开、程序中断，与用户安全锁机的初衷相悖。设置触发角虽然可行，但容易误触，体验并不理想。文章详细对比了这两种主流方法的利弊。最终，作者推荐了一个更可靠的方案：通过“钥匙串访问”在菜单栏添加一个锁形图标，点击即可立即锁定屏幕。这个方法直接、可控，避免了睡眠带来的副作用，也无需担心误操作，算是为 Mac 用户找到了一个安全又便捷的锁屏路径。

IT 2014-07-28 12:45:00 / 累计浏览 3,380

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

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

IT 2014-05-27 23:00:16 / 累计浏览 3,060

客服趣事

这篇讲的是技术团队成员临时顶替客服岗位时遇到的那些令人啼笑皆非的真实片段。作者从一次团队内部的人员轮换出发，记录了技术“门外汉”代班客服时，与形形色色的淘宝卖家沟通中产生的各种误会与趣事。文中细节颇有趣味：有客户把“在吗”打成“阿紫”让人联想到武侠剧；有客户执着于让“美艳艳”的男性技术员证明价格；有使用疑似Windows 2000古老系统却质疑浏览器过时的卖家；更有妈妈卖家在沟通中因孩子放学而突然中断的日常。这些片段不仅展现了客服工作的多面性，也揭示了技术支持中一个常见的现象：很多问题根源在于用户端的环境（如过时的浏览器、缺失的字库）或对系统规则的误解。最生动的是，作者描述了一位爱钻研的卖家花费一周时间分析对手的“价格显示玄学”，而最终很可能只是系统的一个显示bug。这些看似琐碎的互动，实则勾勒出电商技术支持生态中，技术思维与用户日常操作之间的有趣落差，以及一线沟通中不可或缺的耐心与幽默感。

IT 2013-08-21 13:17:04 / 累计浏览 2,600

广告从业者的良心

这篇讲的是计算广告从业者的职业价值与良心困境。作者从Facebook技术高管那句“我们这一代最聪明的人都在思考如何让人点击广告”的感慨出发，探讨了行业现状。他认为，顶尖人才聚集于计算广告领域有其必然性：广告是互联网公司最主要的生存之本，优化广告效果直接关系到企业收入，这本身无可厚非。更重要的是，作者从“阳光”的一面阐述了计算广告的正面价值。其本质是高效的信息匹配：将特定信息送达有需求的受众，创造多方共赢。例如，维基百科通过精准的广告被更多人发现，用户获得了有用信息，广告平台也履行了连接责任。从业者提升的关键，是让广告信息对用户更有用，而非单纯增加广告量。文章也明确了行业的“节操”底线：不能欺骗广告主与用户，不能传播违法内容。作者认为，技术可以有强弱，但良心不能泯灭，最终回归到“有节操地改善人类信息获取方式”这一初心。

IT 2013-05-21 22:56:28 / 累计浏览 3,820

SNS 背后的技术: 消息流的推拉模式选择

这篇文章深入对比了SNS消息分发的推模式与拉模式，从技术实现、资源消耗到用户体验进行了全面剖析。作者从传统通信的推模式（如短信）在SNS场景下遇到的挑战切入，引出了拉模式作为更节省存储的替代方案。文章的核心在于辩证地分析了两种模式的优劣：拉模式在存储效率上能实现百倍级节省，并更有利于处理垃圾信息、好友关系变更、隐私权限修改等复杂的“删除与修改”操作；而推模式在保证信息即时性、减少登录后延迟方面有理论优势，但面临巨大的缓存维护成本和一致性挑战。文章并未止于理论推演，而是结合了对Twitter、Facebook、新浪微博、QQ空间等主流平台的公开信息与现象观察，指出了各平台在推拉选择上的实际权衡。例如，新浪微博的拉模式有助于快速应对大规模删帖需求，而Facebook对离线用户采用拉模式则体现在登录时News Feed的短暂加载上。最后，文章通过具体的数据模型计算，直观展示了在不同用户规模和行为模式下，推拉模式对缓存资源和网络开销产生的巨大影响。作者犀利指出，推模式下频繁的缓存修改操作会“让cache痛不欲生”，而一个设计良好的拉模式配合临时缓存，往往能在性能、成本与灵活性上取得更好的平衡。

IT 2012-11-26 13:49:17 / 累计浏览 2,640

为什么通过前端 .js 记用户日志会丢数据

文章从实际业务需求出发，对比了三种点击日志记录方案。第一种是通过URL参数传递信息，在服务器端（如Nginx）记录请求日志；第二种是通过中间服务器进行跳转并记录，数据最完整，Google、百度等搜索引擎均采用此方式，百度每天十亿级网页搜索请求用约50台服务器即可承载；第三种是前端JavaScript监控上报，能记录悬浮、滚动等丰富行为，但普遍存在15%-20%的数据丢失率。文章重点剖析了JS方案丢数据的根本原因：前端无法为每个事件立即发送请求，必须将行为缓存后批量上报。如果用户在上报触发前关闭浏览器或发生崩溃，这部分缓存数据就会丢失。这本质上是用户体验流畅度与数据完备性之间的权衡——上报越频繁，体验越卡顿但数据越完整；反之则数据丢失风险增加。同时，高频上报也会给日志服务器带来巨大压力。对于追求数据完整性的核心场景，跳转记录是更可靠的选择；而JS方案更适合需要采集丰富交互行为、对少量丢失可容忍的分析场景。