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