Marico's space

说实话，日期和时间处理是 SQL 里最容易"踩坑"的领域之一。我见过太多经验丰富的开发者，被一个"最近30天"的查询折磨得一头雾水——明明逻辑看起来没问题，结果却莫名其妙。这个话题看起来基础，但数据库引擎之间的差异往往让人防不胜防。 这篇文章覆盖了 PostgreSQL 和 MySQL 两款最常用数据库的日期时间函数，全是实打实的实战案例。文章里的例子基于一个典型的电商数据库，包括订单表和用户表

这篇文章让我感同身受。作为一名在甲方企业干了多年数据库优化的工程师，我见过太多类似的场景：业务方天天催报表性能，工程师拼命加索引、加缓存，问题却像打地鼠一样按下葫芦浮起瓢。作者用“给奶酪刨丝”的比喻讲透了物化视图的本质——不是数据库太慢，而是我们在重复做同样的计算。这套从物化视图到汇总表、再到多级缓存的演进思路，其实就是 DBA 日常优化的一个缩影，很有参考价值。 先说说背景吧。 那是一个周二

这个项目里有个不太起眼但挺有意思的技术决策：三个目录网站共用一个 Claude Haiku 客户端。它放在 packages/shared/src/claude/index.ts，所有的 ETL 任务——模型摘要、游戏推荐、开源对比——都走这个入口。有趣的地方不在单例本身，而是提示缓存的设置和容错处理。 为什么非得搞个共享库 每个应用都有自己的 ETL 目录，里面有各自的 generate-

说实话，微服务（Microservices）这个词在技术圈里被炒了这么多年，但真正能把「它解决什么问题」讲清楚的文章还真不多。要么讲得太理论，要么就是云里雾里的比喻讲一大堆。今天咱们就来好好聊聊，微服务到底解决了单体架构（Monolith）的哪些痛点。 先从一个特别接地气的例子说起吧。想象你开了一家奶茶店，一开始你一个人负责点单、做奶茶、收款，什么都是你说了算。客人少的时候，运转得还挺顺溜。但到

说实话，OAuth/OIDC 的测试一直是前端圈子的老大难问题。我见过太多项目要么跳过这部分测试，要么用一堆 mock 把测试变成了自欺欺人的游戏。这篇文章提出的思路让我眼前一亮——把协议逻辑和运行时 IO 彻底分开，这不仅仅是架构上的优化，更是一种思维方式的转变。 真正的痛点是什么 大多数 JavaScript 项目里的 OAuth/OIDC 集成，测试起来都非常鸡肋。常规操作就是 moc

DETECTING FABRICATED TWEET IDS FROM LLM AGENTS: A SNOWFLAKE-DECODE FIELD GUIDE We run a small multi-agent system on Base mainnet. One of those agents was supposed to scout X (Twitter) for fresh bug-b

测试

译者按：作者踩的坑相当典型——月度账单爆掉，但不知道烧钱的是谁。我读完觉得最有价值的是他把「计费」这件事从应用层抽到了凭证层，这套思路在国内多供应商（阿里云百炼、百度、腾讯混用）的场景下同样适用，整理出来供国内做 AI 应用的朋友们参考。 上个月的 AI 调用账单：47300 元。我原本的预算：9000 元。凌晨两点收到微信支付的推送通知，整个人清醒了——这个数字怎么可能？ 但数字没错。更要命

每装一个 MCP 服务器，你都在自己的电脑上给陌生人开了一道门。这不是危言耸听，是 2025 年已经发生的事实。本文介绍一种不需要改代码、不需要换工具、一键完成的隔离方案。 -------------------------------------------------------------------------------- 装 MCP 服务器 = 在自己电脑上跑别人写的代码 所有

这周AI圈是真的热闹。 早上OpenAI扔出GPT-5.5，下午DeepSeek V4就上线了。前两天DeepMind还整了个视觉香蕉，Cai Haoyu（新米哈游创始人）发了篇数字人的论文。一周干了过去一个季度的活儿。 挑几个重点聊聊。 DEEPSEEK V4 V4发布前我参与了内部测试，之前一直憋着不能说，现在 embargo 解除了。 先说参数。这次出了两个版本：V4-Pro 总