可视化未来的应用方向
现在炒股软件的产品功能已经比较完善了，基本没有什么可做的了，剩下的无非就是两个大方向：
#数据可视化
共 189 篇文章。
为什么不同的人对AI能力的体感完全不一样？
有人感觉AI已经能替自己干掉大部分工作了，有人觉得确实有用，但是离替代人还差得很远。对于同一个AI，大家的体感可以完全不一样。
从模块化走到生成式
公司最近在做 Widget，也就是一些小的功能控件。看完之后我的第一反应是，这其实就是模块化、组件化思路的又一次形态变化。这个理念从软件开发早期就有，只是每过一个阶段，名字和形态会变一变，回到第一性原理上看，讲的还是同一件事。
Jev 与可视化
最近 Jev 很火，火到 Reddit 和 X 上到处都是讨论。我第一时间申请了 waitlist，第二天就通过，把它实际用了起来。它和我们熟悉的 GPT、Claude、Gemini 很不一样：不会写文章，不会写代码，甚至不会真正意义上“回答问题”，只干一件事情，判断。
Lieflat Charts 技术拆解：惊艳的可视化是怎么被工程化出来的
最近我在给团队找一套能稳定产出高质量可视化的方案，试到一个开源 skill，叫 Lieflat Charts。同一份数据，不给 Agent 这套 skill，它很容易回到默认蓝、渐变色和拥挤图例。加上之后，出图就像换了一个人。
AI时代的数据可视化生成方式
有了新的业务需求，产品经理先整理需求点，大家讨论大致形式，设计师再出设计稿，最后交给开发编码，做成一个数据可视化组件，然后应用到具体业务里。
提取博客知识为Skill
按此标准，博客中约 5%(~60 篇) 有 Skill 价值，其中真正高价值、可直接抽取的约 15-20 个。
Pretext深度解析
https://github.com/chenglou/pretext !Pretext 学习从隐藏结构到表征的机制
如何沉淀Skill
我建议你们内部不要只分成“两类”，而是分成下面四类。这样后续盘点项目资产时会清楚很多。
从AniClipart学习梯度下降
简短答案: PointMLP 不知道目标在哪里！
浏览器渲染性能优化
在高性能前端开发（尤其是涉及 WebGL、大量 DOM 标注的场景）中，理解浏览器的渲染流水线（Rendering Pipeline）是性能优化的基石。本文将结合实战案例，深入探讨如何利用渲染逻辑和 Chrome DevTools 解决页面卡顿问题。
Prompt-ScrollTelling
网页内容： 1、滚动叙事网页内的文案 2、滚动叙事网页内的图像 3、文案和画面风格、交互参考纽约时报或南华早报网站中叙事可视化内容
技术拆解-Simply-Wall-St
在传统的金融技术（Fintech）领域，数据展示长期被密集的表格、复杂的K线图和枯燥的财务报表所主导。这种“机构级”的界面设计虽然信息密度极高，但对于普通个人投资者而言，存在着巨大的认知门槛。Simply Wall St（以下简称SWS）的出现代表了金融数据可视化的一种范式转移：它不旨在提供毫秒级的
AG-UI
AG-UI 对我最大的启发，不是又多了一个协议名，而是它把 Agent 和前端 UI 之间的边界讲清楚了：模型怎么想是一层，工具怎么调是一层，运行过程怎么让用户看见、确认和接管，又是另一层。
研究员的工作范畴
👉 研究员不是只想 idea，而是要能设计实验或原型验证
关于VISALL改版的想法
回溯过往，我们将所有用例（Case）的逻辑都堆砌在 iFinD 的 spec 主题下。例如，单份文件可能包含 5000 多行代码，其中充斥着大量的 if-else 判断。这些逻辑的本质，实际上就是针对不同 Case 进行差异化的主题配置。
可视化能力构建
第一部分是关于组件能力。我们提供了许多可视化组件，主要落地在公司to B和to C的业务中。业务方通常在我们的平台上进行一站式的可视化配置，完成后以代码形式将这些组件应用到他们的项目中。此外，我们对这些组件进行了上层封装，提供不同主题以适配各业务线，比如海外业务线、首长的业务线、资讯业务线等；同时也
2025年SeeConf参会记录
5 年前，偏右在做 Ant Design，现在他在探索 AI 工程和前端的职责边界。他将在 SEE Conf 2025 分享《AI for Frontend》。
Debug-HXKLine在低端机型卡死
如何避免上来就钻入细节，这里有2个技巧： - 先逮着问题反馈方，问10个问题 - 自己反复使用和测试出问题的页面，详见下一个章节 ### 没有明确现象和问题的范围域 >排查问题和架构设计一样，都应该遵循这个原则：自顶向下，逐步求精。
ECharts学习的本质框架
这个文章是将[[元框架-ECharts]]中基于「第一性原理 + 数学建模 + 形式化方法」的框架 简化为可用于团队培训的版本，目标是：不丢核心思想，但让工程师能听懂、能用、能落地、能快速掌握。
ECharts的配置优先级策略
1. General Component Options:
元框架-ECharts
你不是在“学习如何配置”，你是在“学习一个用来描述图表的领域特定语言（DSL）的语法和语义”。
Haskell学习笔记
Haskell 是一种纯函数式 (purely functional) 编程语言。
如何构建可迁移的学习元框架
需要提炼出核心要素，使其适用于任何领域，无论是技术（如前端框架、数据库、机器学习）还是非技术（如语言学习、乐器、商业分析）场景。
技术英语信息来源
对于“有哪些知名的英文技术博客网站、论坛？我想通过阅读这些技术博客网站，提升自己的技术英文水平”这一查询，本报告旨在提供一个超越资源罗列的战略性回答。仅仅“阅读”技术博客是实现语言精通的必要非充分条件。真正的精通在于将英语从一种被动接收的“工具”转变为一种主动运用的“核心竞争力”。
模板-ECharts业务配置
请从当前项目代码中，抽取可复用的工具函数，加入这个模板代码（visualization-framework）的合适位置中去
datav服务端改造方案
本文档旨在分析当前后端项目的结构问题，并基于领域驱动设计（DDD）思想，提出三种可行的重构方案，以提高项目的模块化、内聚性和长期可维护性。
ECharts配置的范式演进-从对象规约到意图驱动的系统性方法论
这篇不是抱怨 ECharts 配置项太多。真正的问题是，series、axis、grid、visualMap 这些东西的依赖都藏在一个 JSON 里，复杂图表一多，就像在维护一份隐式场景图。
如何突破前端发展的困境
前端不会突然消失，但只会堆页面、追框架的人会越来越被动。更现实的出路，是把业务问题往架构、组件、工具和可衡量价值上推。
单向数据流
单向数据流（Unidirectional Data Flow, UDF）是一种软件设计模式，其核心思想是数据在应用内的流动是沿着一个单一、可预测的方向进行的。该模式的精确定义是"将单向的变更（one-way mutations）应用于一个不可变的数据状态（immutable data state）"
技术拆解-PacificVis2025的状态管理与事件机制
本文档分析了 Pacific Vis 2025 可视化项目中使用的状态管理和事件系统模式，并将其与传统的 Flux/Redux 架构模式进行比较。
技术拆解-Recharts
这篇最有价值的地方，是用源码证据把 Recharts 的架构讲清楚：它更像一个 Redux 驱动的可组合声明式图表库，而不是一个可以随手套上“微内核”名词的系统。
招聘成本问题与内向型招聘策略
您提出的关于成本和精力投入的顾虑非常实际，尤其对于一个精干的小团队来说。这确实是推行任何新战略时需要优先考虑的核心问题。让我们来深入探讨这两个方面，并为您提供一套适合小型团队、低成本且高效的执行方案。
VISALL和StandardChart主题机制设计
可以提供一个default theme，即跨业务线通用的那部分主题。
可视化业务开发框架解析
一般是把2、3、4提出来做个链接，其目的是为了解决查询、管理问题，提高可维护性，可以理解为是一个微型数据库，算是个cache。
可视化项目架构分析
常规的前端开发，大家借助 Vue/React 等框架，可以极大的提升开发效率和质量，这些框架本身就融入了前端的架构设计在里面，也就是定义了一套程序设计的原则和约束，因此才能保证非功能需求的质量。
混合架构-基于D3.js的程序设计
这篇是一次 D3 代码整理。原来的时间线代码把数据处理、路径生成、样式设置、事件绑定都塞在一个类里，写第一版很快，但后面加交互、换主题、做测试都会慢下来。
Prompt-定制化可视化组件
您是一位资深的前端架构师，专门负责设计企业级数据可视化组件。请基于以下完整的架构指导，为用户设计一个高度定制化、可维护、高性能的单体可视化组件。
前端裁剪-Clip
本文汇总 Web 前端可用的裁剪技术、实现原理、特点对比、典型应用场景与代码示例，便于在实际需求中快速选型与落地。
weekly-summary-20250921
@Abby鹿子野: 我英语高考147，从不学语法。都是整篇整篇背课文，我喜欢背课文，基本上读三四遍我就可以背下来。先读一遍，然后边读心中边翻译。然后再读两遍，再用自己的语句翻译出来，然后再打开课文对照一下。这样几遍下来很长的高中课文我都可以会背。
数据可视化组件库的架构模式
这篇把问题从“图表怎么画”往前推了一层。做组件库时，真正先决定的是用户是谁、API 长什么样、渲染层怎么抽、扩展机制要不要开放。
VISALL组件库的微内核架构分析
VISALL这个项目本身是基于微内核架构去设计的，但是随着多次版本的迭代，功能越来越多，其架构已经存在一些偏离了,因此准备对其进行系统的分析，找出里面存在的问题，然后我们计划对其进行一次重构。使其更加符合微内核架构的设计理念，以增强其程序质量和可维护性、可扩展性。
OpenDeepWiki的文档生成策略
OpenDeepWiki 是一个基于 .NET 的智能文档生成平台，采用模块化管道架构，主要组件包括：
InversifyJS重构3D项目
Pacific Vis 2025 是一个基于 Three.js 的复杂数据可视化项目，用于展示全球女性投资者相关的社会经济数据。随着项目复杂度的增长，我们面临着严重的架构问题：循环依赖、手动依赖管理、模块间耦合度过高等。本文将分享我们引入 InversifyJS 进行重构的真实经验，包括具体的代码对
架构驱动的软件方法论演进轨迹
在软件工程的早期发展阶段，开发过程主要遵循传统的软件开发生命周期（SDLC）模型，如瀑布模型。这些模型通常将设计视为编码之前的一个单一、宏大的阶段 。在这种线性思维下，软件开发被视为一个从需求到设计再到实现的顺序过程。然而，随着软件系统的规模和复杂性呈指数级增长，这种方法的局限性日益凸显。实践表明，
通过一个项目掌握Agent开发的全部内容
目前，Agent 相关的开发已经成为主流趋势，因此出于多方面考虑，我们必须掌握 Agent 开发的流程以及相关的技术细节。
从J2EE思考可视化的基建该如何建设
在当今数据驱动的时代，可视化系统已成为企业决策和用户体验的核心组成部分。然而，构建一个健壮、可扩展的可视化平台并非易事。本文将借鉴J2EE（Java 2 Platform, Enterprise Edition）的架构思想，探讨如何构建现代化的可视化基础设施。
资讯可视化-如何提升生成内容的质量
目前，我们对 prompt 的依赖程度过高，大部分逻辑都通过 prompt 来实现，这一现状带来了大量的不确定性与稳定性问题。对此，我认为较为合理的改进方向应从两个层面着手： 第一，将部分工作从 prompt 转移到工程化层面，尤其是那些具备确定性的工作，比如一些程序化计算流程的管理等； 第二，对于
AI Coding-2025年8月
用 AI 写代码以后，我最大的感受不是“终于不用学习了”，而是更容易误以为自己已经掌握了。代码能跑出来，只说明模型完成了一次生成；需求有没有讲清楚、边界有没有守住、改动能不能验证，还是人的责任。
weekly-summary-20250831
https://www.ruanyifeng.com/blog/2025/08/weekly-issue-363.html
资讯可视化-基于沟通日志的AI复盘
同时，请依据这些问题的严重程度、出现频率等维度做出分析排名；在此基础上形成一份总结表格，并将上述所有分析结果写入本地 Markdown 文件。信息越详细越好，不要丢失任何信息。最后，请再反思文档与已分析的问题，确认是否还有可以补充的内容。
技术拆解-时间轴曲线组件
这是一个基于 Stencil 框架的高级时间线组件，实现了蛇形布局和复杂曲线连接效果。组件使用 SVG 遮罩技术、多层渲染架构和渐变色系统，提供了专业级的可视化体验。
一个思维惯性导致的问题
最近的资讯可视化项目，在将测试页面部署到服务器的过程中，我遇到了一些问题，现在记录下来作为经验总结。
本地依赖分包踩坑经历
最近在 HIVIS 可视化组件库项目中，我们遇到了一个典型的本地依赖分包问题。这个问题看似简单，但背后涉及到了现代前端工程化的诸多核心概念：模块解析、构建系统、依赖管理等。
文档驱动开发
文档驱动开发的核心思想是：No Code - 先用 AI 生成完整的技术文档，再基于文档生成代码。这种方法论源于我在实际项目中的探索和思考。
资讯可视化流程分析
这篇想解决的是一个很具体的阅读问题：用户读资讯时，遇到数字、公司、术语和事件线索，经常要跳出去查。我的方案不是另做一个大而全的 Agent，而是把文章拆成可追踪的 chunk，再把解释、图表和时间线嵌回原文附近。
ESM分包
我们最近要开发一个组件给业务方使用，网页对于性能有较高的需求。而我们的组件代码量比较大，会导致组件的 CDN 比较大，加载耗时较长。因此我们需要对组件进行分包处理，将原本较大的 CDN 拆分为多个相对较小的 CDN。
如何设计一个前端组件库
这篇不是在说“封装几个组件”。我真正想拆的是：一个可视化组件库怎么跨框架使用，怎么同时支持 CDN 和 npm，怎么按需加载，组件销毁时怎么把事件、动画和资源清理干净。
近期的学习和工作流
这段时间最大的收获是形成了「早上听 -> DeepResearch 调研 -> 生成可视化网页巩固理解」这条信息获取闭环，以及用多窗口并行写代码来压榨 AI Coding 的效率。代价是同时处理太多线索容易被【打断】后失忆，所以提前一天梳理第二天的工作、保持单一时间线，比单纯堆窗口更重要。
技术拆解-LangExtract
LangExtract 是由 Google 开发的一个 Python 库，专门用于使用大型语言模型（LLMs）从非结构化文本中提取结构化信息。该项目提供了一个完整的信息抽取流水线，具有高度的准确性和可扩展性。
Chrome插件开发技术选型
在过去的几周里，我和我的团队深度参与了一个 Chrome 插件开发项目，从最初的技术选型到最终的 POC 验证，踩了不少坑，也积累了一些经验。今天我想把这些经验分享给正在考虑 Chrome 插件开发的你。
技术拆解-CozeStudio
Coze Studio 最值得看的不是“低代码 Agent 平台”这个标签，而是它怎么把模型、工作流、插件、知识库、数据库和发布管理放到一个工程系统里。它的问题也很典型：Agent 产品一旦从 demo 走向平台，就不只是 prompt 和工具调用，而是领域模型、资源管理、运行时、权限和运维一起上桌
AI可视化增强分析助手开发实践
这篇记录的是一次“把 AI 分析放回阅读现场”的尝试。用户不用复制到别的工具里，选中文本后就在浏览器侧栏里看到分析结果、图表、流程图或者富文本解释。
更安全的解析function字符串
在开发基于 AI 的 ECharts 配置修改器时，我遇到一个问题：当 AI 返回包含 JavaScript 函数的图表配置时，这些函数在传输和解析过程中丢失，导致动态配置（如颜色函数、格式化器等）无法正常工作。 关联内容：[[流式输出]]
weekly-summary-20250720
F10的技术选型： https://fellou.ai/eko/docs/getting-started/eko/
VISALL改造记录
VISALL项目目前配置了npm workspace，但未真正使用pnpm workspace：
weekly-summary-20250705
文档转PPT https://stackblitz.com/github/slidevjs/new?file=slides.md 帮我基于 /Users/leozhou/git/VISALL/docs/refactor/MCP 下的内容，用 Slidev 这个专门用来用 Markdown 格式生成幻
Vibe Coding Experience Summary
Recently, in my development work, I have extensively used Vibe Coding, continuously engaging in a demand-feedback-correction cycle with AI IDEs. Durin
Vibe Coding经验总结
最近在开发工作中，我大量使用了 Vibe Coding，不断与 AI IDE 进行需求-反馈-修正的循环交互。在这个过程中，我一直在思考如何能够将 Vibe Coding 的效果发挥到最大。我认为最关键的是需要整理出一套方法论，解决以下两个核心问题：
技术拆解-大事标记折线图
// - 自定义标记图元（dvMarker，显示事件详情）
Unreal-不同版本的特性
weekly-summary-20250615
最酷的是，这打破了技术壁垒。比如，Claude Code 是用 TypeScript 写的，但我们公司大部分项目用的是 Python。昨天我在 Slack 上看到一个同事，他不懂 TypeScript，但他想修复 Claude Code 的一个问题。于是他直接和 Claude 对话，一个小时内就生成
可视化图表生成MCP
这篇不是在讨论“再做一个图表生成器”，而是在记录一件更实际的事：已有图表能力怎么变成 AI 可以稳定调用的工具。我的判断是，先把成熟 case、schema 和渲染出口整理好，比从零开始训练一个“会画图”的模型更靠谱。
阅后即焚类型的可视化
解决<font color="#ff0000">长尾</font>可视化需求、<font color="#ff0000">一次性</font>需求。 目前AIGC暂时不能解决复杂可视化问题，就先解决简单可视化问题。 展平式的SVG + Claude ## 适用场景 不同的方向，产品规划和技术路线是不
weekly-summary-20250323
这周我的睡眠时间严重不足，每天基本只睡了6个多小时，但令人惊讶的是，我整体精神状态却非常好。白天也不犯困，这主要归功于我感觉正在做的事情对我而言非常有意义——每天都在花时间准备系统架构设计师的考试。
2025年D2参会感想
所有工作能够集中在一个IDE内部完成，而不需要跳转到其他地方时，效率会大大提高。例如，之前使用AI工具时，我们通常需要在ChatGPT中对话，然后将返回的结果复制粘贴到其他地方进行后续处理。这种操作方式不可避免地会导致思维被打断，专注力也因此被分散。 相比之下，如果所有工作都能在同一个IDE中完成，
weekly-summary-20250302
Ant Design X的Vue 版本： https://github.com/wzc520pyfm/ant-design-x-vue
FFCreator学习笔记
一些registry.m.jd.com的包报502，但是没管也能继续跑。 ## 依赖 Node版本：v18 ## 技术拆解
LLM开发经验
LLM 适合做的两种事情：抉择+多样性(比如：生成搞笑的风格)。
AI项目开发总结-叙事可视化
比如动画类型。 之前东明的可视化推荐也是这个问题，搞了很多图表，但是场景无法命中。
weekly-summary-20241110
Manim：命令式(怎么做) ZRender：声明式(做什么)
技术拆解-Mermaid
D3.js 可以参考饼图的代码： mermaid/packages/mermaid/src/diagrams/pie/pieRenderer.ts
AIGC组件的拆分粒度
第二层就是 Tailwind CSS，第四层就是组件了。 越往下走，颗粒度越来越大，约束性变高，自由性不足。
可视化开发和前端开发的区别
更注重抽象(Core)与扩展性(让业务方可以基于我们提供的 Core 机制，快速扩展自己的个性化需求)
weekly-summary-20240915
单元测试用于验证正确性，Self-play 用于尝试和学习，两者结合，可以实现 AI 可视化配置！ UI 稿/截图-LLM 试错-单元测试验证-LLM 试错-单元测试验证...... 将可视化配置任务转换成一个类似围棋的自我对弈任务，通过强化学习解决。 这个是一个很好的思路，可以尝试一下，有搞头！
排查动态柱状图的动画问题
我们基于 ECharts 的竞赛图 封装了一个动态柱状图组件，用于对多周期数据进行动态展示。这是之前的同事封装的，现在业务上线之后，发现当本周期有新数据出现时，效果非常差：
ECharts扩展新的生命周期
这篇不是在整理 ECharts 的通用扩展教程，而是记录一次具体需求的实现过程：在不直接修改业务代码的情况下，为 ECharts 扩展出新的生命周期，并在这个过程中处理组件类型识别、坐标系渲染时机和 patch-package 的问题。
Weekly Summary(20240714)
https://www.zhihu.com/question/660384108/answer/3551179520
Weekly Summary(20240623)
不管是业务领域的程序设计(比如我就是可视化库和功能的领域)，还是诸如写 CSS 这种细节的实施上，最高效的方式都是对你的工作内容进行抽象，形成套路。
Weekly Summary(20240428)
https://ai.meta.com/blog/meta-llama-3/
可视化技术架构升级
现在处于类似jQuery和三大框架之间的那个框架层出不穷的阶段，后面会有一个或者几个牛逼的技术框架来统一整个开发领域，Agent可能会是一个选项。
关于AI产品的关键因素的思考
这一年，公司在全力推动 AIGC 产品。似乎每个部门都在做，但是真正成功的产品几近于零。
技术拆解-叙事流程图
抽象出了FlowchartStore这个 store 类，提供数据结构和响应的数据处理方法。
AI浪潮下开发模式的变革
AI 浪潮正在改变软件开发模式，为开发者带来新的机遇和挑战。本文通过实际工作案例讲述了 AI 对个人开发工作的影响，以及 AI 时代下产品开发模式的变革，并分析了大模型时代程序员与 AI 工具的定位，希望能帮助开发人员提前布局，抓住新一轮发展机遇。
技术拆解-贪吃蛇
self.bordersize = 20 self.displaywidth = self.width + 2 self.bordersize self.displayheight = self.height + 2 self.bordersize + 40
前端的架构设计
https://www.zhihu.com/question/26646855/answer/68503768
移动端initial-scale导致图表文字过小的问题
投顾部门用到了我们的可视化图表库D3Charts，发现在iOS下文字会变得很小。
3D项目开发流程
以这次的3D关系图为例，我发现做的时候比较迷茫，缺乏一个流程指引。
Three.js-3D关系可视化
这次的文本就是用的CSS2DObject绘制的，事件绑定需要这样处理：
Three.js-汽车产业链
比如我之前做的质检扫光小飞机、React的汽车Demo里面的发光圆环等，都是起到的这个效果。
Three.js-描边
这是我们初始想到的办法，实际上并不合适，性能差，效果也达不到预期。
可视化组件的状态管理
这里的交互指的并不一定是常规的鼠标交互行为，其代表的是我们将一种事物变更为另一种状态的行为，例如一个列表中文本的搜索、筛选高亮，交互则指的是搜索和筛选的这两种用户行为。
现代化开发模式
之所以问这2个问题，是因为就我观察到，公司目前大部分前端开发人员，都是在做体力活，陷入了无尽的业务开发中。这些低效的工作浪费了大家大量的时间。
关于可视化技术选型的思考
最近给海外组做图解财报的3D组件，陆陆续续耗费了我不少时间，但是最终回头来看，这个需求实际上可能只需要1天就能搞出来。究其原因，在于我的技术方案选型上，误入歧途了。
Three.js-性能优化
最近做了一个集群目标策略的3D可视化项目，前面花了2周时间出了个Demo来进行演示，性能极差，在我的i7-12700H+RTX2050的笔记本上，也会出现卡顿。后面这个还要迁移到移动端，性能问题就更严重了，因此借助解决这个需求的性能问题，把Three.js的性能优化方面的内容整理下，方便今后参考。
Three.js-Gallery
https://sketchfab.com/3d-models/sci-fi-girl-v02-walkcycle-test-07ac452d75cc47969234b224422ea85d
Weekly Summary(20220619)
咖啡有个生效过程，如果到了公司才喝，要等到一个小时之后才起效。因此应该起床后就喝。
动态折线图开发问题汇总
最近在给业务方开发动态折线图，期间遇到N多问题，这里做个记录，就当是技术复盘了，避免下次重复踩坑。
一个关于组件配置项的糟糕设计案例
最近在做范式组件，我写了动态柱状图和折线图，在考虑如何给使用者开放配置项的时候，考虑到如果全部配置都给用户，我感觉他们的理解成本会比较高，因此我想将配置封装为Theme类，只开放设计规范中允许的配置项给用户。
数据可视化的设计方法
3、多挖掘数据之间的关联关系，用关系图/桑基图展示单个周期的数据之间的关系(关联、流向、强弱等等)
Unreal-Blueprint
https://www.bilibili.com/video/BV11o4y1C7aW?spmidfrom=333.999.0.0
Unreal-学习笔记
房大佬说一个月就带着前端团队转UE开发了，这个是很可信的。二者本质上都是一样的。
Weekly Summary(20220220)
参考资料：https://zhuanlan.zhihu.com/p/87598465
牛逼的前端是什么样的
https://2022.stateofjs.com/zh-Hans/
Unity学习笔记
另外，Unity界面中的每个功能，都去试一下，比如各个导航栏、操控场景和界面等等，手熟了效率才高。
WebGL学习笔记
https://www.cnblogs.com/wanbo/p/6754066.html
技术拆解-3D饼图
https://threejs.org/docs/index.html?q=line#manual/en/introduction/Drawing-lines
Weekly Summary(20211121)
想要过得不匆忙，就得每天设置个截止条件，也就是当日目标。别没有界限的一直干，效率既低，状态又差。
Weekly Summary(20211114)
上周四突发的几个事情，占据了我不少时间，包括更新展示大厅的 PPT、和设计师核对交互细节、新的发布流程(起码 3 小时)等。
如何做好F10的数据可视化
F10有大量的公司财务数据，而非专业人员在查看这些财务数据的时候，是很吃力的，包括概念难以理解、难以从数据中发现规律和逻辑、难以得出结论辅助自己决策等等。
问题排查复盘-大屏自选股数据错误
用户那边展示的 Web 大屏，其中自选股页面的数据显示错误了。这个问题之前也出现过。
可视化组件复盘-海外版
这篇记录的是海外版可视化组件从 10 月 18 日开始开发，到 11 月 1 日交付过程中的一次复盘。中间经历了排期压缩、需求和设计反复、技术方案调整，以及最后的联调和交付问题。
可视化组件设计
应该先画图，有哪几个生命周期，每个阶段应该做什么，不应该做什么，把这个想清楚，形成原则，就是设计了，框架也就出来了。
如何做好CodeReview
参考散点图的案例
智能短视频-组件设计
比如我们的D3Charts，就是一个组件库；而其他零散的组件，比如动态折线图、柱状图这种，并不算是组件库。
跟月影学可视化
反思：我之前把可视化理解得太狭隘了，没有抓住本质；还是给自己找个老师(陈为、月影)更靠谱。
数据可视化的探索方向
我们团队被定义为A系列团队，即探索型团队，因此我们的年度目标和计划，肯定有很大一部分比重是需要投入到可视化探索中去的。那数据可视化有哪些方向可以探索呢？这是我们必须明确的一个问题。
weekly-summary-20210131
起因是昨晚听了 WZB 的管理分享，然后我意识到，其实绝大部分开发组长都是没啥管理意识的，包括我自己，也是属于有一些意识但是并没有完整的策略模型，很多事情也是了解但是没去做。这就是典型的一个傻子和一堆傻子一起玩，那么这个傻子不可能变成聪明人。
Weekly Summary(20210124)
2021 怎么走？还是这样肯定不行，得变更，得跳出舒适圈。
2021读书计划
2020年读的书太少了，读书计划也没有完成。2021继续加油！
开发人员工作标准
presentation: night.css width: 800 height: 600
可视化与前端基建和效能的结合
presentation: night.css width: 800 height: 600
前端团队的问题到底是什么？
现在前端团队都是分散到各个具体业务中的，这就导致信息互通、技术工具的整合推广，都存在问题。前端年初都会列出很多待解决的问题，我们也知道有很多事情应该去做，但是究竟这些问题里面，最影响开发效率、性价比最高的20%内容是什么，其实是没有数据来支撑验证的，因此我们的改进还是稍微有点拍脑袋。 形成对比的就是
Puppeteer学习笔记
比如手机页面，高宽分别放大5倍(实际截屏面积应该是放大了25倍)，9秒的视频，截了近500秒，差不多是50倍的时间，太夸张了。
可视化组件的配置设计思路
刚接触数据可视化的组件开发时，往往会遇到一个问题，就是不知道该如何设计组件对外开放的配置项。我根据最近写组件的一些经验，对配置项的设计做个总结，方便后面参考。
技术拆解-时间轴折线图
http://jira002.iwencai.com:8080/browse/DATAV-2055
如何在拖动节点时，让连线随之移动
这是用 D3.js 做关系图时遇到的一个具体需求：节点可以拖动，拖动后连在这个节点上的线要跟着移动。这里记录的是当时采用的方案，核心是利用 JavaScript 的对象引用传递特性来实现【数据驱动】。
Flutter安装笔记
我平时喜欢看小说，但是现在的小说APP广告太多了：启动应用有广告，从其他APP切换回来又有广告，体验很不好。因此我想自己写一个简单的文档阅读APP。考虑到现在Flutter挺火的，就准备用这个试一试。因此这里记录下安装Flutter的过程中遇到的一些问题。
动态视频自动生成方案
https://hanabi.data-viz.cn/index?lang=zh-CN
马良项目的总结
docker、可视化搭建、sequelize、TypeScript、老项目的熟悉等等。
Weekly Summary(20200816)
最近一时兴起想买个笔记本，结果筛选的过程中一发不可收拾，每天都会花费不少时间去查看笔记本信息，但是直到现在，我也没有明确定下来买什么笔记本。我之所以花时间去查看这些信息，是希望能够以较低的价格买到适合我的笔记本，但是如果算一下我耗费在这上面的时间，其价值已经远远超过能给我节省的钱了。虽然这个过程能让
Weekly Summary(20200719)
我喜欢做简单的、收益又不错的、正向反馈快的；这样筛选下来，只剩下业务开发了。
工作乐趣的丢失
我工作已经有九年半了，在此期间，也经历了国内互联网行业的各种变更。总体的感觉，大家在工作中的乐趣正一点点的丢失。造成这个问题的原因有很多，我按照自己的想法总结了下：
数据可视化的TOP10需求
这里的TOP10需求，是我们整个组的，不一定就是可视化相关的需求，因此提效方面的内容也是可以加进来的。
关于2020上半年工作汇报的思考
给基金团队带来多少帮助？ 给资讯团队带来了多少帮助？ 给 F10 带来了多少帮助？ 他们本来开发一个项目要多久，现在由于我的加入，需要多久？
weekly-summary-20200712
明确业务方向->明确需要什么样的人->明确需要多少人->明确招聘需求->干就是了！
数据可视化上半年总结与下半年计划
这个是最大的问题。方向不确定，感觉我们组就像浮萍一样，随波逐流，每一天都战战兢兢，如履薄冰。
如何写好代码-抽取流程
之前写了一段解析网页的代码，现在回头重构，发现烂得不行。这里选取一段关于流程的做个分析改进。
从拓扑图案例来分析如何写可视化组件
我准备今后每一周都给自己一个技术方面的尝试主题，来提升自己的技术能力。
统计PDF的词频
可视化领域，有一本非常经典的书籍《The Grammar of Graphics》，一直都想仔细读一下。但是这本书似乎没有中译本，只有英文版。就我目前这么烂的英文阅读水平，啃起来绝对很吃力。因此我想先统计下这本书里面的单词词频，找到高频的生词，我先通过比如扇贝单词等APP将这些生词背下来，这样看书的
D3Charts-日历图的实现原理
component下的calendar的代码，并没有实现散点图的功能。
近期英语学习的总结
好久没有学习英语了，翻了下扇贝打卡日历，发现上一次坚持学习，是截止到2020.1.24，也就是去年的除夕这一天。其实去年后面几个月的学习，已经是马虎了事，每天打个卡而已，并没有真正收获什么。现在距离我的小目标(2021.02.14)，时间越来越近了，现在必须得重新将英语学习拾起来了。
weekly-summary-20200517
我现在已经属于触底反弹期间了，但是如果我不将自己的主动性调起来，那么肯定是反弹不上来的。
为什么拓扑图项目的进度管理做得这么烂
拓扑可视化平台这个项目的进度让我很不满意，比预期的时间整整多了三天。究其原因，在于我的项目管理做得太烂了，基本上没有什么规划可言。
Weekly Summary(20200419)
我们希望上班能带来精神和物质上的收获，希望周末能愉快的和家人一起出游。
疫情地图开发总结
在一知半解的情况下，凭感觉去评估难度、工作量和时间，结果很多细节上的问题都没考虑，估算的时间可能只有真实工作量的三分之一(甚至更少，比如这次我预估半天不到就能搞定，结果搞了整整两天，且第一天还是三个人一起搞)。
平台即服务
这是缘于最近SMM给我提的需求：提供一个通用的拓扑结构，展示不同业务方的数据。经过跟SMM的沟通，我发现他期望的其实不是一个拓扑组件，而是一个涵盖了数据接入标准、存储、可视化呈现的平台。通过平台对外提供服务，服务于公司所有的业务。结合最近在关注的前端平台搭建相关的内容，我突然想到，这个需求不就是一个
Weekly Summary(20200412)
现在技术更新越来越快，工作压力也与日俱增，再加上自己年龄逐渐增大，这两年考虑这方面的内容比较多。其实这个问题的答案很早就有了，那就是持续学习才能让自己不被淘汰。但是光是学习还不够，你学习的速度、产出的价值还需要能跟得上业界的发展、公司的发展速度，否则就意味着竞争力的下降，最终只是迟一点被淘汰而已。
如何编写方案设计文档
我们需要在一开始，就把这三要素给讨论确定下来。这部分内容花费的时间多一点也是很值得的。
Weekly Summary(20200329)
业务组件的建设和推广，结合结果页，找几个新业务实践下，我们不只是提供可视化组件，这样才能扩大团队规模，才能发展。
Weekly Summary(20200322)
因为有所求，希望能快点搞定，早点回家。 这说明我自己想去做的事情，动力还是很足的。
如何快速绘制带动效的定制版流程图
上周有个业务组让我们做一个流程图，数据是固定不变的，但是要求流程之间的线条可以动起来。考虑到这个不通用，且我们这边也抽不出人力，因此我让他们自己的开发去学一下，自己写。
Echarts地图使用笔记
上周末Boss要求做一个全球疫情的项目，产品经理准备通过一个全球地图来展示疫情情况，我们考虑了下，选择了沿用之前全国疫情的技术选型，即ECharts来实现该地图。
Weekly Summary(20200315)
今后如果其他组借我们的人进行业务开发，除非我们真的很空，否则坚决不借人。
2020读书计划
PS：标题为<span style="color:red">红色</span>的书籍，是我还没看完、但是后面会继续看下去。
Weekly Summary(20200216)
如何将自己这个项目做好，是我需要投入毕生精力去考虑的事情。
关于组件化、可视化的思考
这种一般会组建一个专门的团队，和我们现在类似。该团队对外的输出就是可视化作图组件，比如折线图、柱状图、饼图之类的。
《阿里巴巴中台战略思想与架构实战》读书笔记
公司在金融市场发展到现在，接下去的路可能是如下三方面(都是营造差异化的竞争力)： 1、中台战略：借助中台，快速试错、大量试错，不因为开发、效率等问题放过任何一个创新点，找到创新点进行突破 2、可视化战略：视觉、交互的升级，公司发展到一定阶段，这部分内容的重要程度会越来越高 3、技术战略：通过AI技术
如何按需加载D3.js中的模块
最近有个组件需求，是用D3.js写的，自己写的代码总共就几KB大小，但是最终打包出来的压缩版JS居然有98KB。考虑到D3是按照模块化编写的，因此我想尝试下通过按需引入模块，来精简最终的JS。
近期写总结计划过程中的一些想法
企业最关心的（或者说唯一在乎的）事情，就是增加收入、降低成本。 企业实际上需要的不是程序员，而是能够帮助它们增加收入、降低成本的人。 企业雇佣你，是为了让你帮它们完成某个可以增加收入、降低成本的项目，而不是为了让你追求个人的软件成就。
如何将一个非模块化的项目转为模块化项目？
最近写一个行业关系图的组件，写的时候我是直接拆分为几个JS文件，然后在html页面中引入这几个文件，没有采用模块化的方法。开发到后期时，准备处理打包相关的事情了，然后就得将这些程序转为模块化的形式。这个过程耗费了我不少时间，因此这里记录下，用于今后参考。
并购重组动画的教训
最近做了一个动画，用于 PC 端的并购重组网页，展示并购重组的过程。今天给 Boss 看了下，结果比较悲剧，被称为是看过的世界上倒数第二烂的设计......
如何阅读前端代码
在之前的笔记《D3Charts-给legend实现动画分页效果》中，已经提过了自己了解项目时踩过的一些坑：
如何画出优秀的架构图
Office的PPT在画图时其实是很强大的，这个已经能够满足常规需求了，因此直接选择PPT作为画图工具即可。
Chrome扩展开发笔记
又到招聘季了(其实秋招已经过了...)。今年我们组照例没有意外的分到了0个秋招的实习生(其实分到了一个，结果第一天分给我，第二天这位同学就说不来了)。没办法，只能自己散招了。
关系图的现状
随着数据的暴增以及数据搜集技术的发展，目前各个公司都积累了很多的数据。从这些数据中挖掘信息，进而发展出产品，或者分析用户信息，对用户进行画像，类似这样的需求越来越多。
如何用D3.js画一个可交互的关系图
1、每个节点都是可以拖动的，且拖动的时候，与该节点关联的线条、箭头，都要随之同步移动；
2019读书计划
工作这么多年，一直都没有读书计划。今年因为一些工作上的原因，迫切的感觉到了读书的重要性，因此这里列下我的读书情况，等到年末回头再检验下。
数据驱动
数据可视化是数据驱动的领域，不过我发现不仅仅是数据可视化，在很多其他场景，也应用到了数据驱动的理念。
用D3.js实现一个图形的套路
现在接到一个可视化的图形需求，我会比较慌，思考了下，是因为我在具体实现上，还没形成自己的编码套路，导致无法快速对图形进行技术上的拆解。
ZRender学习笔记
注意，HTML 引入 dist 下的文件；如果遇到 TS 报错，设置@ts-ignore 即可。
一周总结20190830
你坚信的、不会因为别人的言论改变的、十匹马都拉不回来的，才是目标。
一周总结20190816
不管是数据新闻也好、大屏也好、组件也好，如果仍然仅仅只是停留在开发的思维上，是没法做成的，因为这些东西都是需要有用户量、有收益，才能体现价值的，所以不光要做出产品，更要去宣传和推广。
一周总结20190728
20190722-20190728的周总结
FreeCodeCamp学习笔记
记录我通过FreeCodeCamp学习前端技能的一些经历和感想。
CSS学习笔记
记录一些常用的CSS技巧
我的压力来自何方
今年上半年是我工作以来，甚至可以说是有生以来，压力最大的半年。
未来哪些人会被淘汰、四件事情、为什么要招研究生以上的人
这里的“淘汰”，可能并不是指无法生存，而是指无法自己掌握主动性，只能随波逐流的人；一旦你所处的环境发生变化，很可能就会对你造成非常大的打击(比如失业)。
vis.js学习笔记
vis.js包含了很多类型的图形，我这次主要是使用其network类型的可视化图形。