前端工程与交互
关注语义化结构、响应式布局与可访问性。写页面的顺序是先想清楚信息层级,再考虑动效;动效只服务于阅读节奏,不做无意义的装饰。
个人研发笔记 · hoshino.fun
摘 要
这是一份关于「用代码解决科研里的小麻烦」的公开笔记。作者并非计算机科班出身,习惯把踩过的坑、试错的中间态和最终跑通的方案按时间顺序记录下来,希望对同样走在半路上的人有点用。
内容以个人研发实践为主,覆盖前端工程、数据可视化、科研工具链与自动化脚本四个方向;每篇日志都尽量给出可复现的步骤和取舍理由,而不是只贴结论。
关键词:前端工程;数据可视化;科研工具链;自动化脚本;个人研发日志
我叫宋佳伟,目前常驻新疆乌鲁木齐。日常工作围绕数据处理与分析展开,写代码的起点其实很朴素——重复的表格整理太耗时间,于是开始学脚本,后来越写越多,索性把这一路的过程整理成了这个站点。
我偏爱简单的做法:一个静态页面能说清楚的事,就不上框架;几十行脚本能解决的问题,就不引入一整套系统。这份偏好也体现在站点本身——整站是单文件实现,样式与脚本全部内联,不加载任何外部资源,因此在弱网环境下也能很快打开。
日志按「问题 — 尝试 — 结论」的顺序书写,失败的尝试同样保留。那些走不通的路,往往比成功的那一条更有参考价值。
关注语义化结构、响应式布局与可访问性。写页面的顺序是先想清楚信息层级,再考虑动效;动效只服务于阅读节奏,不做无意义的装饰。
把实验数据从表格搬到浏览器里的可交互看板。习惯先做数据清洗与口径核对,再谈图表类型——口径不一致的图,画得再漂亮也没有意义。
文献归档、批量重命名、格式转换、实验记录整理这类琐事,能用脚本解决就不手工。目标是把每天重复的十分钟,压缩成一次性的十分钟。
定时任务、日志归档、站点构建与部署流程。偏爱小而稳的工具:能长期稳定跑下去,比功能堆得多更重要。
用 IntersectionObserver 做一版克制的滚动渐显
记录如何让内容默认可见、只在脚本可用时再淡入,避免脚本失效后整页空白;附完整的降级判断与 prefers-reduced-motion 处理。
把实验数据从表格搬到浏览器里的可视化看板
一次完整的迁移:指标口径对齐、缺失值处理、坐标轴取值,以及为什么最终放弃了大而全的方案,只保留了四张核心图。
给文献整理写了一个自动归档与重命名脚本
按「年份—第一作者—关键词」统一命名,并自动去重。附带踩坑记录:中文文件名的编码问题,以及重命名前必须先做一次全量备份。
从零搭起 hoshino.fun 的构建与部署流程
单文件站点的取舍、静态资源的缓存策略,以及一套足够简单、出错时能一眼看懂的发布流程。
关于日志内容的技术讨论、勘误与选题建议,欢迎发邮件;一般会在 1—2 个工作日内回复。