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