可视化未来的应用方向
现在炒股软件的产品功能已经比较完善了，基本没有什么可做的了，剩下的无非就是两个大方向：
数据可视化
共 30 篇文章。
Lieflat Charts 技术拆解：惊艳的可视化是怎么被工程化出来的
最近我在给团队找一套能稳定产出高质量可视化的方案，试到一个开源 skill，叫 Lieflat Charts。同一份数据，不给 Agent 这套 skill，它很容易回到默认蓝、渐变色和拥挤图例。加上之后，出图就像换了一个人。
AI时代的数据可视化生成方式
有了新的业务需求，产品经理先整理需求点，大家讨论大致形式，设计师再出设计稿，最后交给开发编码，做成一个数据可视化组件，然后应用到具体业务里。
如何沉淀Skill
我建议你们内部不要只分成“两类”，而是分成下面四类。这样后续盘点项目资产时会清楚很多。
关于VISALL改版的想法
回溯过往，我们将所有用例（Case）的逻辑都堆砌在 iFinD 的 spec 主题下。例如，单份文件可能包含 5000 多行代码，其中充斥着大量的 if-else 判断。这些逻辑的本质，实际上就是针对不同 Case 进行差异化的主题配置。
单向数据流
单向数据流（Unidirectional Data Flow, UDF）是一种软件设计模式，其核心思想是数据在应用内的流动是沿着一个单一、可预测的方向进行的。该模式的精确定义是"将单向的变更（one-way mutations）应用于一个不可变的数据状态（immutable data state）"
数据可视化组件库的架构模式
这篇把问题从“图表怎么画”往前推了一层。做组件库时，真正先决定的是用户是谁、API 长什么样、渲染层怎么抽、扩展机制要不要开放。
架构驱动的软件方法论演进轨迹
在软件工程的早期发展阶段，开发过程主要遵循传统的软件开发生命周期（SDLC）模型，如瀑布模型。这些模型通常将设计视为编码之前的一个单一、宏大的阶段 。在这种线性思维下，软件开发被视为一个从需求到设计再到实现的顺序过程。然而，随着软件系统的规模和复杂性呈指数级增长，这种方法的局限性日益凸显。实践表明，
近期的学习和工作流
这段时间最大的收获是形成了「早上听 -> DeepResearch 调研 -> 生成可视化网页巩固理解」这条信息获取闭环，以及用多窗口并行写代码来压榨 AI Coding 的效率。代价是同时处理太多线索容易被【打断】后失忆，所以提前一天梳理第二天的工作、保持单一时间线，比单纯堆窗口更重要。
技术拆解-LangExtract
LangExtract 是由 Google 开发的一个 Python 库，专门用于使用大型语言模型（LLMs）从非结构化文本中提取结构化信息。该项目提供了一个完整的信息抽取流水线，具有高度的准确性和可扩展性。
VISALL改造记录
VISALL项目目前配置了npm workspace，但未真正使用pnpm workspace：
关于可视化技术选型的思考
最近给海外组做图解财报的3D组件，陆陆续续耗费了我不少时间，但是最终回头来看，这个需求实际上可能只需要1天就能搞出来。究其原因，在于我的技术方案选型上，误入歧途了。
数据可视化的设计方法
3、多挖掘数据之间的关联关系，用关系图/桑基图展示单个周期的数据之间的关系(关联、流向、强弱等等)
如何做好F10的数据可视化
F10有大量的公司财务数据，而非专业人员在查看这些财务数据的时候，是很吃力的，包括概念难以理解、难以从数据中发现规律和逻辑、难以得出结论辅助自己决策等等。
可视化组件复盘-海外版
这篇记录的是海外版可视化组件从 10 月 18 日开始开发，到 11 月 1 日交付过程中的一次复盘。中间经历了排期压缩、需求和设计反复、技术方案调整，以及最后的联调和交付问题。
可视化组件设计
应该先画图，有哪几个生命周期，每个阶段应该做什么，不应该做什么，把这个想清楚，形成原则，就是设计了，框架也就出来了。
跟月影学可视化
反思：我之前把可视化理解得太狭隘了，没有抓住本质；还是给自己找个老师(陈为、月影)更靠谱。
数据可视化的探索方向
我们团队被定义为A系列团队，即探索型团队，因此我们的年度目标和计划，肯定有很大一部分比重是需要投入到可视化探索中去的。那数据可视化有哪些方向可以探索呢？这是我们必须明确的一个问题。
开发人员工作标准
presentation: night.css width: 800 height: 600
可视化与前端基建和效能的结合
presentation: night.css width: 800 height: 600
可视化组件的配置设计思路
刚接触数据可视化的组件开发时，往往会遇到一个问题，就是不知道该如何设计组件对外开放的配置项。我根据最近写组件的一些经验，对配置项的设计做个总结，方便后面参考。
从拓扑图案例来分析如何写可视化组件
我准备今后每一周都给自己一个技术方面的尝试主题，来提升自己的技术能力。
平台即服务
这是缘于最近SMM给我提的需求：提供一个通用的拓扑结构，展示不同业务方的数据。经过跟SMM的沟通，我发现他期望的其实不是一个拓扑组件，而是一个涵盖了数据接入标准、存储、可视化呈现的平台。通过平台对外提供服务，服务于公司所有的业务。结合最近在关注的前端平台搭建相关的内容，我突然想到，这个需求不就是一个
关于组件化、可视化的思考
这种一般会组建一个专门的团队，和我们现在类似。该团队对外的输出就是可视化作图组件，比如折线图、柱状图、饼图之类的。
如何按需加载D3.js中的模块
最近有个组件需求，是用D3.js写的，自己写的代码总共就几KB大小，但是最终打包出来的压缩版JS居然有98KB。考虑到D3是按照模块化编写的，因此我想尝试下通过按需引入模块，来精简最终的JS。
并购重组动画的教训
最近做了一个动画，用于 PC 端的并购重组网页，展示并购重组的过程。今天给 Boss 看了下，结果比较悲剧，被称为是看过的世界上倒数第二烂的设计......
关系图的现状
随着数据的暴增以及数据搜集技术的发展，目前各个公司都积累了很多的数据。从这些数据中挖掘信息，进而发展出产品，或者分析用户信息，对用户进行画像，类似这样的需求越来越多。
如何用D3.js画一个可交互的关系图
1、每个节点都是可以拖动的，且拖动的时候，与该节点关联的线条、箭头，都要随之同步移动；
用D3.js实现一个图形的套路
现在接到一个可视化的图形需求，我会比较慌，思考了下，是因为我在具体实现上，还没形成自己的编码套路，导致无法快速对图形进行技术上的拆解。
vis.js学习笔记
vis.js包含了很多类型的图形，我这次主要是使用其network类型的可视化图形。