上次写了一篇《爬取 CT 云影像的 DICOM 原始文件》，本以为是个小众需求，毕竟相关教程很少，但没想到很快就收到了些回复，其中就有人问我怎么爬另一个网站。粗略一看该网站界面比上次的好些，至少布局是对齐了，它的域名是 medicalimagecloud.com，能搜到叫海纳医信。不管怎样，这种小网站一般都没什么反爬措施，弄起来都挺简单的——我一开始也是这么想，但后来发现这回的网站还要真费点功夫。本文记录下爬取该网站的思路，具体的代码见cloud-dicom-downloader。爬虫思路第一次进去就立刻点开 F12，在网络一栏里找可能是影像文件的请求，这个网站倒是没整 WebSocket 之类的东西，很容易找出关键请求：响应体保存到文件，打开看了下不是 DICOM 的文件：但是一眼瞅到个ftypjp2，说明下载的是 JPEG 2000 格式的图片。再回去把网页上的按钮都摸一遍，发现菜单里能选格式：看到熟悉的 Dicom 字样，我以为这次的爬虫就已经搞定了，只要写个脚本批量下载即可，于是便安心地睡去。直到第二天阅片软件打不开时我才发现下载的并不是 DICOM 文件。这个下载下来的文件内容比较稀疏，大部分是 0x00，隔一段有一些其它的值，很明显没有压缩，看上去页不像是加密后的数据，同时它无法解码为字符串，大概率还是二进制的格式。另外文件的大小也引起了我的注意，都是 524288 字 ...继续阅读 (1)

考虑下面的代码，它测量了几个完全一样的函数的用时。function timeit(fn) { console.time(); for (let i = 0; i < 5e7; i++) { fn(123); } console.timeEnd(); } timeit(x => x + 1); timeit(x => x + 1); timeit(x => x + 1); // More timeit(x => x + 1) calls...想象一下控制台的输出是怎样的，由于干扰的存在时间不会相等，但至少应该差不多，不会出现某个比另一个快几倍的情况。但如果你实际运行一下（对于浏览器不要开发者工具里运行，要写一个 HTML 文件然后打开），根据引擎的不同，输出是这样的：在 NodeJS 22.9.0 上第一个比后续的快 10 倍：default: 21.129ms default: 205.575ms default: 203.184ms在 Firefox 131 上得到了相似的结果：default: 19ms - timer ended default: 130ms - timer ended default: 129ms - timer ended在 Bun 1.1.30 上，前五次调用拥有最快的速度，后面会慢一些：[31.56ms] default [27.79ms] ...继续阅读 (1)

Gird 是我很喜欢的一种 CSS 布局，它可以同时控制两个坐标轴的位置，相比传统的一维布局可以省掉大量的包装元素；对于做表格而言，也比元素简单得多。最近实现了一个仿 GitHub 的热力图，再次体验了一把 Grid 布局强大的功能，结果如图：接近像素级复刻了，而代码仅需 160 行（不含注释），如果用做没个 250 行是很难搞定的。完整的源码见https://github.com/Kaciras/Resume2/components/ContributionCalendar.jsx需求背景惯例说一下为什么要搞这个，就是最近更新简历，想把 GitHub 的热力图加进去，毕竟每天都写代码，全绿，多看看对视力好。最开始想到的是直接复制 GitHub 的 HTML，这当然可行，而且我见过一些地方就这么搞，不过没啥意思，既然我会前端，那就自己实现一个看看这玩意有多少含金量。实现过程好的废话不多说，直接来看怎么搞吧。首先一眼就知道 GitHub 的热力图是张表，横轴是月份，纵轴星期；再加上下面的图例。该表显示了一年中每天的贡献数，按星期分列，同时后面可能会多不完整的一周所以一共是 53 周，加上表头一共 54 列。行的数量就是 7 + 1个表头 + 1行下面的图例（为了方便把它也放进去），总共 9 行。是不是很简单？确定了布局，后面要解决的就是填元素了。数据结构既然决定自己做，就肯定要支持动 ...继续阅读 (2)

最近给本站升级 HTTP3，这个东西出来有两年了，浏览器和很多平台都支持完毕，可惜本站所用的Node.js 仍没支持，没办法还得在前头整个 Nginx。升级完成之后的效果还是很可观的：可以看出 h3 协议的首屏图片加载用时在 200ms 左右，而 h2 的在 400ms 到 500ms 之间，说实话提升这么大我是没想到的，应该跟本站服务器在美国有关，这也展现出了 HTTP3 的威力，新技术，赶紧冲！Nginx 配置开启 HTTP3 的过程其实不复杂，本文以本站使用的 Nginx 反代为例，同时它也是最流行的 HTTP 服务器，要是你用的库还没支持的话也可以搞一个放前面反代。Nginx 从 1.25 版本开始才支持 HTTP3，可以使用以下命令先检查一下：nginx -V 2>&1打印的输出中有--with-http_v3_module即支持 HTTP3，也可以用grep命令来搜索。在写本文时 Nginx 官方源的版本是 1.26，Debian stable 才到 1.24，如果你的源太旧可以切过去。至于怎么反代就不讲了，教程到处都是，这里仅说下如何开启 HTTP3 。给反代加上 HTTP3 只需两行：# 这是 Nginx 的站点配置文件。 server { server_name blog.kaciras.com; listen 443 ssl; + listen 443 ...继续阅读 (5)

前天 Vue 出 3.5 了，新增了一些功能（完整的 ChangeLog），来看看都有什么吧。Reactive Props DestructureuseIddata-allow-mismatchonWatcherCleanup跟 onCleanup 的区别？Watch 返回值增强Deferred TeleportuseTemplateRef异步组件的 Hydrate 策略@vue/reactivity 导出 watch 函数watch 指定深度优化总结：小打小闹Reactive Props Destructure#这次更新的吸引力没有 3.4 那么大，首先最大的更新就是这个 props 解构了，这是一个编译器特性，能够追踪 props 结构出来的变量，然后把用到的地方自动添加props.前缀。javascriptCopyconst{ count =0, msg ='hello'} = defineProps<{ count?: number message?: string }>()functionhandle() {doSomething(count); }上面的代码等价于：javascriptCopyconstprops =withDefaults(defineProps<{ count?: number; message?: string; } ...继续阅读 (8)

解码图片到像素，做图片处理的话是必不可少的过程。大家都知道浏览器就能看图，所以自带解码功能，而 Node 也有许多库可以用，这通常不是什么难题。我最初也是这么想的，在我的一个网页项目 ICAnalyzer 里是这样写的：javascriptCopyasyncfunctiondecodeImageNative(blob) {constbitmap =awaitcreateImageBitmap(blob);constcanvas =document.createElement("canvas");const{ width, height } = bitmap; canvas.width= width; canvas.height= height;constctx = canvas.getContext("2d"); ctx.drawImage(bitmap,0,0);returnctx.getImageData(0,0, width, height); }不必多讲，这段代码非常简单，去 Google 搜的话靠前的回答都是这么做的，而且找了几张图试下也没有问题……直到某次找了张半透明的图做无损压缩测试，发现这无损的输出竟然跟原图不同。经多方对比之后，确定了压缩的结果没有问题，那误差只可能出现在解码上，而且只有半透明的图才有这问题。经一番搜索终于确定了原因：canvas 2d AP ...继续阅读 (12)

很久之前我就觉得那个单张的实体胶片很不方便，不仅易损坏，信息量还很有限，那么小一点地方根本就不能展示所有的切面，而且转诊也很不便，换一家医院就得重做，不仅费钱还伤身，当然我没问过能不能提供其它载体比如光盘 U 盘之类的。要是能建立一个医疗数据共享机制就好了，将数据保存成通用的格式，这样无论哪家医院都能读取。实际上这样的系统已经有了，叫医疗数字影像传输协定（DICOM）。DICOM是以TCP/IP为基础的应用协定，并以TCP/IP联系各个系统。两个能接受DICOM格式的医疗仪器间，可借由DICOM格式的档案，来接收与交换影像及病人资料。拍片#最近去做了个鼻子 CT，终于查出了经常头痛的原因，完事了发现报告单上有个二维码，记得去年还没这东西。report扫了进去一个叫云影像网站，里头能查看诊断报告和在线阅片，其中阅片的页面张这样：云影像看这瞎眼的配色、还有按钮的边距，好像是十八层转包给一个培训班做出来的，正好网站名字也叫青鸟，不会是什么北大青鸟吧……不过网页再怎么垃圾，也比那一张胶片好，至少所有断层都能看到，通过滚动鼠标还能连续切换，再也不怕找不到位置了。把它的功能都试了一遍后我发现没有下载，也不知道是不是故意的，让你非使用他的破网站不可。但重要的资料必须自己保存，首先不能断定他这网站能永远活着，万一哪天倒闭了，或者超过了存储限定日期，那再想看就没辙了。另外阅片软件还有很多，某些拥有 ...继续阅读 (26)

你做项目写基准测试吗？就是测一个函数调用花多少时间。据我在 GitHub 上的的观察大部分人是不写的，毕竟做功能和单测就够费时间了。对于 JavaScript 的来说更是如此，毕竟它不像些编译型语言对性能这么敏感。也就我这几年家里蹲，才会闲得无聊去比较各种写法的性能吧。就这样我写了不少 Benchmark 零零散散在各个项目里，在这个过程中我越来越感觉 JS 生态里没有一个像样的 Benchmark 框架，于是就自己动手丰衣足食！本项目开源：https://github.com/ESBenchmark/ESBench现有方案的问题比较结果精确度多工具链IDE 集成火焰图？架构设计主体流程执行和通信构建过程工具链配置套件的 API数据结构保存使用其它关于内存的测量在手机里运行Logo未来的想法扩展性分布式运行开发时长测个用时为什么要用框架？看我三行就给你测出来：javascriptCopyconststart = performance.now();fn();console.log(performance.now() - start);这段代码有什么问题呢？首先它有 4 个坑：为了支持浏览器这里用了performance.now()，它的精度是这样的：NodeJS 里它跟process.hrtime一样底层调用uv_hrtime(1)(2)，精度很高，跟系统相关。浏览器里最高 5us ...继续阅读 (35)

随着 JavaScript 的项目越来越复杂，类型约束的优势就逐渐的体现了出来。放眼望去，现在的新工具 Deno、Bun、Vitest 等等，都把直接运行 TypeScript 文件作为卖点，唯有老态龙钟的 NodeJS 还在冥顽不灵。于是咱来扶它一把，让 Node 也能直接运行 TS 文件。本项目地址https://github.com/Kaciras/ts-directly需求场景方案分析ESM Loader Hooks核心流程决定编译选项解析模块转换代码其它事项编译参数优化性能测试还在实验中总结需求场景#最近写了一个 Benchmark 框架ESBench，Benchmark 跟单元测试差不多，为了让用户省一步构建，我决定让它直接运行 TS 源文件，就像各个单测框架一样。更进一步，我希望它能保持轻量和兼容，最好别捆绑编译器，用户的装了哪个就用哪个，跟已有的技术栈整合。要知道 Vitest 开发的初衷就是为了和 Vite 搭配。另外它还得快，所以新一代的编译器SWC和esbuild必须得支持，同时为了兼容性也要能使用 TypeScript 的 API 来转换代码，在运行时优先选择最快的。方案分析#提到在 Node 里直接运行 TypeScript，首先就能找到两个库：ts-node和tsx，可惜的是它们不能完美的满足我的需求。tsx 钦定了 esbuild 作为编译器，这直接就 ...继续阅读 (25)

我玩这类游戏有 8 年了，总共 391 部，过去一年里 84 部，数字不太准因为有的系列合一起了。说实话今年玩这么多我是没想到的，这个数字超越了历史，也应该不会再被超越。当然每个游戏都写就太多了，我要分个类，挑几个有印象的锐评一下。另外本文要转发到中国的平台，所以图片可能打码。（原计划过年发的，结果鸽了 5 个月……）印象最深的Demons RootsSEQUEL 系列神之天平带游戏性的圣骑士莉卡魔女之泉R兰斯系列软房子的几部NTR魔剑士莉奈2除灵猎人主动送的擦边作不满意的YU-NO 重置版樱云🌸绯恋其它姐系作品恋爱家庭教师露露美一句话简评印象最深的#Demons Roots#这一年唯一让我受到感动的作品，前传 King Exit 是 4 年前玩的，当时我觉得它虽然不错但在虐妹上用力过猛，有为了卖 HS 而编剧的感觉。而玩了 Demons Roots 后我必须对紅唯まと致以崇高的敬意，这部 5 年磨一剑的作品，彻底超越了它的前作。设定上本作以前作的反派魔族为视角，却又不洗白，而是展现了不一样的故事。在看腻了王道剧情的今天，这种反派视角，失败者去征服世界的故事天生就非常有趣。而紅唯的感染力在 King Exit 就初现锋芒，到了 Demons Roots 则是更进一步。游戏从开始就莉莉相遇，断断续续的歌词和不正常的行为为身世埋下伏笔，中间死亡才是解脱的一幕让洋葱重新想起了自己的理想。 ...继续阅读 (28)

Monaco Editor 是什么呢，是一个网页端的文本编辑器，VSCode 里面写代码的那一部分。Monaco Editor 在哪众所周知 VSCode 是个 Chromium 套壳应用，里头的很多东西可以在浏览器上运行，这个编辑器部分就是如此。这东西出来也有几年了，但是官方的文档却很少，很多地方得去它源码里看，总之想用好没那么简单。再把它集成到本站时也花了些功夫，特写本文总结一下经验。Monaco Editor 的仓库是https://github.com/microsoft/monaco-editor，但实际上该仓库只有少部分组件和示例，它的主体部分仍然在 VSCode 里https://github.com/microsoft/vscode/tree/main/src/vs/editor。本文的完整代码见https://github.com/kaciras-blog/markdown文本框不行吗？所见即所得？包结构创建编辑器其它功能计算选择范围选项开关同步滚动编辑按钮文本框不行吗？#曾在三年前，本站刚做好的时候我就想过把 VSCode 的编辑器给弄进来，但因为文本框也能用，这事就一直鸽着。直到某天不知道哪里更新之后光标总是乱飘，我才觉得与其在文本框上修修补补，不如直接搬个更高级的……当然上面是本站的事情，你自己想用的话，最好先弄明白一个问题：为什么不用？如果要在页面上写代码 ...继续阅读 (29)

因为左边的智齿顶得脸疼，就决定去医院解决这个祸害。小学的时候因为牙齿多长了几个，也拔过几次牙，印象里拔牙是个挺轻松事，无需注意什么。于是我马上就去了附近的公立医院，先拍了张片子，一看下头没有，上面的也都伸出来了，属于简单难度。拔牙费 480 一颗，遂决定立即开搞。X-Ray拔牙当天#先是打了针麻药，扎得时候没啥感觉，5 分钟后拿了个挺子开撬，只听见嘣的一声，牙齿断了……然后就是各种掏和撬，还拿锤子砸，弄的我头都晕了，一段时间后又叫来另一个人撬，总共搞了一个小时。期间还担心牙根断在里头，又拍了张X光。最后叫我鼓气，但我不知道鼓气是什么意思，嘴还被撑着没法说话，于是就使劲往外呼了一下。后来才知道这是测试有没有穿孔的，因为这里没有做好才导致了后续的问题。结束后给了头孢和一个冰冻的盐水袋敷脸，我贴了一个小时就扔了，也没感觉很痛或是脸肿。越来越疼#在拔牙前我也查过注意事项，知道术后应该如何保养，还了解了神经损伤和干槽症，但是关于上颌窦穿孔却鲜有提及（做好鼓气测试的话当场就能处理，遇到的人可能不多）。拔牙后的第一天，疼痛丝毫没有减轻，这可以理解，无视。第二天一起床，突然就从洞里流出一些酸酸的水，淡黄色，我以为是正常现象，毕竟洞里可能积水嘛，而疼痛不但没有缓解反而更严重了。第三天同样又流水了，而且半边脸都疼了起来，在水流出后会舒服点。此时我感觉不对劲，别人都是三天消肿，我这不会是干槽症了吧。于是 ...继续阅读 (31)

最近那个第一次 Pull Request 挺火的，Twitter哦不对 X 上看到好几个在秀的，正巧昨天我收到了第二个但实际上算第一个 PR，达成了收发 Issue + PR 的成就（GitHub 应该设一个），于是我也要来说一说。写代码也好多年了，才收到第一个 PR，这到底是好事还是悲哀呢……我看别人用firstpr.me看自己的第一个 Issue 和 Pull Request，但实际上在 GitHub 的左上角菜单里就能查。发第一个 Issue发第一个 PR收到第一个 Issue收到第一个 PR收到第一个 PR（真）发第一个 Issue#2021 年是前端的一个重要的转折点，以 Vite、SWC 为首的一票工具相继进入大众的视线，让更快的语言抬着 JavaScript 走成为了未来的方向。我也跟风去用它们，因为比起 Golang 我更喜欢 Rust，所以首先尝试把 SWC 整到我的项目里。好不容易改完配置，一运行直接报错。顺着 stacktrace 爬过去一看它把javascriptCopya.b=1; a =null;给优化成了null.b=1。这种优化好像叫常量传播来着，可惜传反了。无论是编译优化还是 Rust 都不是我擅长的，所以没能发 PR 而是提了一个 Issue。可能是因为压缩还是实验中的功能，SWC 过了俩月才修，这期间我已经改用 Vite 了。发第一个 PR#我 ...继续阅读 (30)

变异测试，跟单元测试、集成测试等等东西一样，都属于软件测试技术。它的核心思想就是随机修改源码，然后运行测试，如果通过则说明你的测试不完善，或者存在多余代码。最近偶然发现了这玩意，用了下感觉挺不错的，一下子在我的项目里发现了好几个问题。比如这个（本文里的代码都是 TypeScript）：stryker 的报错javascriptCopy// 对应的测试代码，测试框架 Jest。it.each(["\ta;\tb","a; b;","a; b\t","a\t; b", ])("should split and trim the value %s",value=>{expect(split(value)).toStrictEqual(["a","b"]); });这段代码的逻辑是把字符串按;分割，去除前后空白并过滤掉空串。在变异测试中，将正则里的一个\s改成了大写的\S后测试仍然通过，这表明它的代码或测试有问题。仔细一看就会发现，测试中漏掉了分号旁没有空白的情形，如果给测试数据再加一个"a;b"则变异测试不再报错。当然还有一种做法是改为value.split(";")，因为后面已经用trim去空白了。传统的单元测试，对这种错误是无能为力的，它的覆盖率一直是 100%。对此就需要另一种技术，能够对现有的测试进行测试，找出遗漏的用例和多余的代码，这就是变异测试。基本理论#变异测试首次在 19 ...继续阅读 (30)

最近自己的一个前端项目里遇到了加密需求，而且要求 Node 上加密之后在浏览器上解密，期间还是有几个坑的，特写此文总结一下。需求场景#做了个网页版简历，在开发中想到个人信息这部分应该支持个隐藏功能，毕竟有时候只是想公开展示一下以求修改意见，此时应当避免显示真实的信息。要处理这种情况，最简单的方法就是用两个URL，一个显示真实的一个显示演示信息，只公开演示的，真正使用时发真实的。想做到这点也不难，如果你没有强迫症的话。但是我想啊，简历也算个项目，就直接给它传 GitHub 开源了，顺便还能上线到 GitHub Pages 上不是美滋滋。这就有个问题：真实的信息咋办？肯定是不能一起传上去的，而由于我用了 GitHub Pages 也就是说构建完的内容也要上传到公开仓库，虽然应该不会有人会跑到那里头扒压缩过的 JS，但我是有强迫症的，非得做到完美才行。所以就需要一个加密上传的方案，在需要真实信息时给 URL 加个参数作为密码，在客户端解密显示真实信息。我这简历项目使用的是 Next.js，加密自然就用 Node 的crypto模块，然后就踩了一堆坑……基本知识#首先是加密算法的选择，对称加密如果没有什么特殊要求，可以无脑选择AES-GCM，这个算法没啥缺陷。然后是AES-GCM的参数，一个用于防止彩虹表的向量IV用可以写死，另一个就是密钥，这俩长度都是固定的，我这选择最小的128位，于是 ...继续阅读 (30)

趁着 618 买了个惠普战 66，号称高扩展性两个固态位，打开一看一个只有 42mm 长，原装的盘插在 80mm 的口上，这不坑爹吗。坑爹主流的零售 M2 固态都是 2280 的，2242 的基本只有 OEM 拆机盘，售后没保障，价格也不比 2280 便宜。所以我决定还是加一块大牌自营的 2280，然后这个自带的盘嘛……看起来元件很少后面都空着，也许可以锯成 2242。调查#毕竟有风险，在动手前还是去查查有没有相关的教程，或者案例。简单搜索一下：bilibili 上有个 PM991 剪坏的。当然也有成功的。另一个成功案例。知乎上有评论 PM991 剪成功了。总体上成功的居多，那个剪坏的可能是其它地方出了问题。最后搜了下狗东，甚至有短到 2230 的款，证明 PM991a 剪成 2242 完全可行。有卖 2230 长度的开搞#先划线然后掰断手上正好有木刻刀，看了下侧面好像是电木版，也是木头没毛病。两边都划出印子后轻轻一掰即可。下一步就是锯出螺丝孔，这里直接用锯子了，然后拿砂纸把边缘磨平，最后清理一下锯出的渣子。据凹槽磨边扫一扫总的来说还是很简单的，最后插上看看口子有没有对齐。结果嘛好像歪了……拿锉刀再修一下吧.看看锯得咋样再打磨一下装好测试#最终结果Benchmark完美开机，没有发现任何问题。测试下性能只有中间两行的写入少了 100，可能是误差，或者剪短后散热面积小了？总而言之这个 ...继续阅读 (28)

本站第一版上线仅仅一年半，前端界可谓是风起云涌，Vite2、Vue3 接连发布，为了不落后于时代的潮流（前端就是事多），是时候定重构本博客了。在第一版发布时，我计划下一次大更新会重新设计界面，但奈何 Vue3 的改动实在太多：Vue3 本身完全重写，光迁移指南里的 Beaking Changes 就有几十项，想用 Composition API 的话组件还得重搞。Vue-cli 转为维护模式，官方推荐改用 Vite，这意味着基于 webpack 的构建体系被抛弃，本项目也得跟着换。全家桶的其它部分也有不同程度的迁移成本，比如 Vuex 跟 Pinia 用法完全不同，VueRouter 的 API 改变等等。以至于迁移过去几乎要求重写整个构建系统，这使得我不得不放弃原先重新设计页面的计划，最终的结果就是性能提升了不少，但页面几乎还是原样。性能优化#性能是本次更新的主要目标，上一版中难以处理的部分都被解决，4 个前台页面的 Lighthouse 性能全满：Lighthouse Reports唯一的 97 分是代码高亮的配色不满足 4.5 对比度要求，这个实在没办法，如果符合的话基本上鲜艳的颜色都没法用了。下面是具体的优化点，有点可惜的是忘了统计每一步节省了多少代码体积。版本升级#此次重构提高了浏览器的最低兼容版本，从原先的要求支持AbortController提升至至少支持Nullis ...继续阅读 (30)