从 REST 到 GraphQL：我们为什么最终没换

去年秋天，我们花了两周做技术预研，认真评估把主要接口层从 REST 换成 GraphQL。最后的决定是不换。 这篇算是那次决策的记录。我想尽量公平地写——GraphQL 确实解决了真问题，我们不换不是因为它不好，而是我们的处境不划算。 为什么会想换 动机很具体，不是赶时髦。当时有三个痛点： 移动端首
作者：咖啡不加糖
分类： 技术笔记

关于日志，我踩过的坑和总结的原则

我们组有个不成文的说法：一个人写日志的水平，大概等于他排查过多少次线上问题。因为只有半夜三点对着一屏毫无用处的日志抓瞎过，你才会知道该打什么。 先说几个我亲手制造或者亲眼见过的反面例子。 反例一：一天 80GB 有个接口把完整的请求体和响应体都打进了 info 日志，理由是「方便排查」。这个接口日均
作者：摸鱼的鲸鱼
分类： 技术笔记

为什么我不再迷信微服务

先说结论：过去一年，我把手上一个由 9 个微服务组成的系统，合并回了 3 个。上线三个月，P99 从 1.2 秒降到 380 毫秒，故障率下降大概六成，团队开发一个需求的平均周期从 5 天缩短到 2 天。 我不是要否定微服务，而是想说清楚一件事：我们当初拆分的理由，几乎没有一条站得住脚。 我们当初是
作者：秃头码农
分类： 技术笔记

用一周时间学一门新语言

今年三月我给自己放了一周假，目标是学 Rust 到能写出一个能用的小工具。我每天记了流水账，这篇基本是把日记整理了一下，包括所有丢人的部分。 Day 1：一整天在跟编译器吵架 上午看官方教程前四章，感觉良好，觉得不过如此。下午动手写第一个真实一点的东西——一个统计目录下文件行数的小程序，然后就崩了。
作者：早睡失败者
分类： 技术笔记

脚本写多了之后的反思

$ ls ~/bin | wc -l 137 这是我上周敲的。137 个脚本，最早的一个是 2014 年写的，叫 ff，两行，作用是 find 加 grep。 我花了一个下午把这 137 个逐个打开看了一遍。这篇就是那个下午的产物。 盘点结果 我按「最近一年有没有用过」分了个类，结果挺让我难堪的：
作者：一只猫饼
分类： 技术笔记

数据库事务：那些容易忽略的边界情况

事务这东西，学的时候觉得简单：开始、提交、出错回滚。真在生产环境用起来，坑全在那些教科书不写的地方。下面这些是我这些年实际遇到过的，按被坑的严重程度排序。 一、在事务里调外部接口 这是我心目中的头号杀手。代码看起来非常自然：开启事务、更新本地状态、通知下游、提交。 问题是这个通知走的是网络。某天下游
作者：晚风信箱
分类： 技术笔记

我怎么给项目做技术选型

我做技术选型有一张表。不是为了显得专业，是因为我吃过亏——2017 年我凭「感觉更现代」选了一个当时很火的存储方案，八个月后那个项目的维护者宣布停止更新，我们花了六周迁移出去。 从那之后我给自己定了五个维度，每个 1 到 5 分，加权算总分。这篇就讲这张表，以及它失效的时候。 维度一：退出成本（权重
作者：树懒先生
分类： 技术笔记

从零搭一个小爬虫框架

这篇按版本号写。因为这个东西确实是一版一版长出来的，一开始我根本没打算写「框架」，只想抓点数据。 v0.1：一个 while 循环 需求很朴素：抓某个公开文档站的三万多个页面，做本地全文检索。我写了 30 行： urls = [seed] while urls: u = urls.pop()
作者：秃头码农
分类： 技术笔记

我理解的抽象与过度抽象

这篇我打算用两段代码开头，都是我自己写的，相隔四年。 2019 年的我 需求：给用户发通知，支持站内信和邮件。 我当时写的东西是这样的结构：一个 NotificationChannel 接口，两个实现类，一个 ChannelFactory，一个 NotificationTemplate 抽象类和三个
作者：小满不满
分类： 技术笔记

用 Python 做数据清洗的一些套路

我每隔一段时间就要处理一批来源不太可靠的数据，几百万行的表格或者分隔符文件。这些年攒了一些固定动作，说不上高级，但能让我少返工。 动作一：先摸底，别急着洗 拿到文件我做的第一件事不是清洗，是给每一列出一张体检表：非空率、唯一值个数、最短最长长度、随机抽十个样本值。十几行代码，跑一遍心里就有数了。 这
作者：摸鱼的鲸鱼
分类： 技术笔记
共 44 篇文章
页