公司有专门做智能短视频的同事，今天跟他聊了下关于可视化在短视频中的应用问题。 其实几个月之前我就给他展示过我们这边能做的事情，包括我们的组件库、大屏、动态图表、数据新闻、图说新闻平台等。不过最终他并没有使用这些，据其反馈，主要有两个方面的因素： 我们的功能(比如动态图表)，没有数可视的花火好用，主要体现在模板太少 可视化在短视频中的作用有限，尚未找到一个好的突破口 关于第一点，问题倒不是很大，

今天晚上和设计团队的组长，一起给产品总监演示我们近期做的设计标准平台。产品总监给我们讲了很多东西，获益颇多，这里记录一下。 提升下限 vs 提升上限我们现在做的 HUX 平台、组件化等等，都是在提升下限。但是现在想要做出成绩，仅仅只是提升下限，是远远不够的。 产品经理 vs 设计/开发产品经理会自己主动琢磨如何将产品做好，而设计和开发往往不会。 这里总监讲了一个产品经理给标签起名字的案例

上周有个部门招了一个前端进来，领导对于他们给这个人员制定的试用期考核目标不满意，希望这个人能深挖技术，并给公司的前端带来一些实质上的改变。然后这个部门的开发主管就找我一起讨论怎么给这个人定目标。我们在讨论的过程中，遇到一个问题：前端技术深入的方向有哪些？该如何深入？ 我们经常讨论着就不自觉陷入了细节，然后又陷入了低标准、低眼界的困境，最终得出来的结论都很 low。 我觉得要想解决这个问题，得弄清楚

有东西被加密了, 请输入密码查看.

之前的同事用 Three.js 画了一个地球效果，感觉挺炫酷的。正好我最近在学习 Three.js，因此对其源码做个拆解，参考学习下。 设计思路同样还是采用结构分解法，先用结构图把页面元素和交互拆分出来。 着色器绘制地球边缘的大气层光晕 结构拆分

不同阶段应该有不同的套路比如开发阶段，应该有一个地方可以查看到所有常用链接的地址，方便大家进行调试。 比如进入 BUG 修改阶段，就应该先创建一个石墨文档，然后及时跟进 BUG 修复的进度，保证大家(需求方、开发人员、测试人员)信息透明。 比如这次的 BUG 修复日志，就很有用： https://shimo.im/docs/j6rJrhvhhrx8qGpj 为什么项目实际开发时间远大于评估时间？为

制作模型的流程是什么模型的分类，有哪些格式，区别是什么？一个完整的模型，包含哪些文件？各自有什么用途？怎么建模(model)怎么做素材(texture)##怎么打灯光(lighting) 怎么烘焙(bake)模型怎么与程序结合，实现交互模型和程序各自应该负责什么我们具体能做到什么程度(上限)

这个从代码上来看，是比较简单的，关键在于思路和几个库。 这份代码写得非常好，完全可以当做我们后续动画的模板代码。 设计思路 通过数学函数计算不同结果的空间坐标值(x, y, z)和旋转值(rotation) 通过 Tween 来进行两个状态的动画变更 几个概念THREE.PerspectiveCameraTHREE.SceneTHREE.CSS3DObjectTHREE.Object3DTHRE

上半年总结产出更好的 DataV 设计标准平台 疫情相关的项目的开发以及地图组件的支持 B2C 的 UI 组件和业务组件，以及配套的数据统计平台 几个大屏 最后悔的事情方向没有及早明确这个是最大的问题。方向不确定，感觉我们组就像浮萍一样，随波逐流，每一天都战战兢兢，如履薄冰。 下半年应该把目标计划打印出来，每天早上读一遍。 人没有招好总共有 2 个问题： 1、开发人员没有层次，全部招了应届生，导致