盒马数据产品反思

首先吐槽算法可视化项目,其本质上就是一种传统的cube的可视化类型;唯一不同的是一颗可展开互动的树结构。树会包含预警展示信息(理论上是森林结构)。

产品的开发链路为 产品->(交互)->UI->研发。这个开发链路是盒马惯用的开发模式,但是由于盒马的交互/UI风格非常传统保守,且极度匮乏数据产品的知识,基本上在设计产品时采用在图表库中查找能用的图标来强行套用。很多图标对数据的展示能力极度匮乏。与此同时,基于图表的思考方式会极大程度降低分析人员对数据与图形的理解能力(这一点在GoG中有提到)。也导致G2本身的价值完全丧失,也就是集团消耗高成本投资的新式图形系统资产完全被浪费掉,同时会使得底层开发人员对G2本身产生极大的质疑,在技术选型上内心甚至会更倾向于echarts。

数据产品,在进入研发前,必须由数据分析/数据可视化(来自通用式BI/GS一线研发团队)的专业人员进行产品原型的设计。这一环节也是反馈到集团图形系统研究的重要环节,帮助构建图形系统的开发理论与方法。

非可视化开发专业人员在进行数据可视化时,往往缺乏对任意数据情况下的可视化效果的思考。对于数据特性(数据量、特征值、维度、度量、层级结构)发生变化时不能给出可视化自动切换或检测的边界条件。使得可视化产出是“死”的,不够灵活。对于什么原因会导致可视化性能降低、如何避免此问题完全不知,所以在可视化设计这一环节,必须交由专业的可视化开发人员进行。否则团队永远难以积累可视化开发经验,只是在自己的安逸区开发着马马虎虎可以应付交差的产品。

另外,数盒竟无法支持这样一个产品,而需要专门配置开发人员,为何不反思数盒在此的局限性?这也是数盒团队中缺少一个专业的可视化leader来持续跟进优化产品,单纯只是对一些用户提出的必须解决的需求逐个解决,不思考其中的共同性,不去总结,不去反思。那么这个产品又死掉了。

数盒究竟能否成员盒马内部可视化团队中的可视化开发人员的原型开发工具,tableau是否可以,数盒与tableau在原型产品开发上的区别在哪里,各自的优势劣势在哪里?

当然,一味的抱怨是没有用的,这里对目前来说更为有价值的反思是自身如何对当前环境做出决策。首先,研究数盒目前内部有价值的部分,结合盒马的业务做出客观的分析。然后看哪些优势是可以集成到canary中的。思考如何设计GoG的图形系统,开发GoG目前所遇到的局限性在哪里,有哪些部分是G2导致的,哪些不是,其他可视化库能否解决该问题,不能的话,是为什么,自己手动解决该问题的难度评估。

另外,在这样的环境中,如何尽力影响团队。在当前体制下,这种影响会受到哪些阻碍,有什么方法减小这些阻碍的影响。


项目开发思考

注意组件大小

确认组件的智能拆分足够足够细致,智能分配专一。通用组件封装到资产库以便复用。部分组件注意ui和逻辑的解耦。

react虽然没有vue的组件逻辑清晰,但是可以参考vue组件的结构来编写react组件:

  • 拆分methods, computed(目前还没有集中管理好方案,建议暂时均以getter的方式直接注册在当前组件中)
  • 简化表单场景,统一由一个函数负责设置setState,毕竟组件内事件没有像redux那种监控溯因机制。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    constructor (props) {
    super(props);
    for (let method in this.methods) {
    console.log(method)
    this[method] = this.methods[method];
    }
    }
    methods = {
    testThis: () => {
    console.log(this.state)
    },
    testFunc () {
    console.log(this.state)
    }
    }
    render () {
    this.methods.testThis() // state
    this.methods.testFunc() // undefined
    this.testThis() // state
    this.testFunc() // state
    }
Read more
喉结手术日记

喉结手术日记

萝北是一个某个部位很大的女孩子,这使得萝北非常的困扰,一直希望把它切掉。

目前萝北获得的情报:

  • 北医三院-潘柏林,8000,术后住院一天观察
  • 上海411-赵博,6000,术后观察2-3小时

萝北是在3.4在微信上联系到了赵博,得知当周赵博下午都会在医院,可以随时去找他。于是3.6号前往上海找赵博咨询预约(路途遥远的小朋友可以提前在微信上和赵博预约好)。

事前萝北已经获得情报找赵博不需要挂号,直接去住院大楼21楼主任办公室找他就好。但是萝北是一个社交残障人士,所以还是老老实实挂了号然后去错了地方……后来几经周转见到赵博发现挂号的确没有用……

目前可以确定的情报有:

  • 赵博在住院大楼21楼主任办公室,可以直接前往,无需挂号(挂了也没有);
  • 赵博喜欢睡午觉

见到赵博说明自己的基本情况后,赵博就像我科普了一些手术的基本知识和风险;大致要做好的心理准备就是一般不会切得太干净,具体效果术前无法确定,要在术中看具体情况一点一点切。

目前可以确定的情报:

  • 切除部位为甲状软骨,切除效果不确定,视情况而定。
  • 切除费用6000元,使用蛋白线(无需拆线)额外加200元,可以使用支付宝。
  • 手术风险主要在于切到气管导致血液流入窒息。
  • 手术只能采用局麻。
  • 手术耗时短规模小,无需住院,术后观察2-3小时即可出院。
  • 手术时间非常好预约,运气好的话当天就可以进行。

后来萝北和赵博约的周五或周日(结果周五没有成功联系到赵博,于是最终选择了周日)

手术当天的记录

手术当天8:30就从家出发,到了12:50才到411附近。然后在金拱门里遇见了可爱的fancy。稍微吃了点东西后就前往411找赵博手术了。

手术前赵博给了我一个小黄鸭,用于在术中感到不适的话(主要是口水吞咽之类的),可以捏一下小黄鸭来提醒赵博,以便赵博暂停手术。

手术过程由于是局麻,所以能感觉到一些刺痛感,比如骨头被一点一点的撕掉的感觉……赵博手术时会和护士科普一些知识,比如“这条线是气管,如果一不小心切到……”。萝北被吓得每当赵博要动刀就屏住呼吸,不敢动弹…然后小黄鸭质量也不是很好,有时候用力按也不叫…..只能默默忍耐…(建议患者自带质量过关的惨叫鸡…)

听到赵博说手术已经结束了,萝北松了一口气,然后赵博突然说“等下,我要精益求精一下”。于是又被切了一会……

术后赵博说“隔着纱布摸一摸,是不是没了?”(注,此时赵博带有很骄傲的语气)
02c52597d33a87b2d10aa817f6067c7d.jpg

下午3:30

手术大概进行了一个小时,术后麻药效果过去会变得超级疼,就好像有人一直掐住自己的喉咙一样。而且术后会莫名其妙产生超级多的口水想咽,每次都好像有人重击自己的咽喉……
176cd6ce624e49a9a6342b3ff9de7e56.jpg

然后萝北临时躺在了一间全是很活跃的ftm的房间,遇到一些笑话自己特别想笑又要忍住否则就痛痛痛……

晚上7:00

可以出院了。然后萝北要经历4小时的车程才能到家。建议其他要手术的小姐姐除非有人能送自己回家,否则最好就近找个旅店休息一下……萝北由于低血糖差点昏倒在高铁站台上(下了高铁突然耳鸣眼前全黑了……),还好有随身带糖。这也说明手术可能会消耗很多能量,建议术前多补充一些。

第二天早上就恢复了一些,没有那么痛了,但吞咽仍会很痛,所以只吃了一点东西。声音的话目前还没有恢复,音色受到一些影响(虽然感觉还挺可爱的……)。

术后效果的话目前还有点水肿,而且纱布还没有摘掉。但是喉结的部位是没有了,感觉切得挺平的。但切除的部位仅是突出来的那部分,好想把气管软骨也削一下啊(注:极度危险的想法),总体来说还是挺满意的。

后续的效果图等过几天纱布摘掉之后再发出来。


产品开发各环节的定位与反思

对整个开发环节的思考

从整条开发链路来讲,可以分为如下模式(这里只是给出一条简单的便于辅助思考的链路,实际上该关系要复杂的多)

数据采集 -> 数据存储 -> 数据提取 -> 数据理解 -> 业务服务 -> 交互页面 -> 决策支持

  • 交互页面部分是前端的主要工作,其作用是衔接人类的思考与决策,将其接入整个数字系统中。
  • AI方向的工程师会负责从数据理解到决策支持的部分
  • 后端往往会负责数据存储到业务服务的部分

当然如果对于业务最更为专精的细分,则细分职位会负责某一个环节的子部分。如数据科学家负责数据理解(数据探索性挖掘),图形学方向的工程师则负责交互页面中的一部分。每个领域下的细分都会产生许多可以深入挖掘产生知识壁垒的方向,这也说明某一个领域的深入程度与负责的业务链路长短无关。

但当从主流价值观与会计准则出发,对每个环节进行收益与成本核算,则各个环节的轻重的会有所划分。

Read more
回忆OI随想

机缘巧合,今天下午无聊,刷到机房群里在聊OI的事情,基本上就是各自回忆了一些过去的经历与感悟。

md讲到自己后来搬去小黑屋里挺长一段时间,的确,当时的机房环境确实差了些,隐形的非隐形的环境因素都会对OI造成极大的干扰。我自己曾经也是迷失了一段时间的方向,导致当时也被环境干扰,倾向于与他人聊天甚至是浮躁玩游戏。有时会耍一些水题来安慰自己。md的习惯在于他每天会刷三道题,基本上每道题都会注入一定量的思考,也会随之带来更为高效的能力提升。

相比我提升最快的时候,也不是单纯每天六道题的时候,而是学习新的算法并付出实践,对每一个细节进行推敲探索的时候。搜索、平衡树、线段树,dP每一个都是付出了很多的思考与探索。这种题目的刷题效率是更高的。即没没做一道题都是为了辅助研究一个问题,最终一定要对该问题进行总结,得出可以被快速复用的结论。

另一点是持续努力是否会带来一定的枯燥与单调的心理。

答案是会的,基本上每个人都存在这个问题,所以要增加生活的多元性。如md会每周四腾出来,刷清华的网课。在平时也会每天用一个小时玩游戏来调节心情。这种调节会使得生活变得更加有节律,会养成不易被动摇的习惯,也使得在诱惑来临时不会被击垮。

思考+轻运动

这一点已经在很多优秀的人身上被发现了,很多优秀的人都倾向与在散步、骑行等轻量级运动时思考问题,这也会带来更强的灵感。适当的锻炼身体、提高身体的强度,也可以将更多场景与不同类型的运动加入的辅助思考运动的名单中。


【读书笔记】The Grammar of Graphics - 5. Algebra

5. 代数

本章主要介绍对数据的处理、重新存储与结构调整以便制作可视化图形。

5.1 语法

5.1.1 符号

符号用来表示代数中被操作的对象。变量集合(varset)代数中的符号即为变量集合。

5.1.2 操作符

操作符是代数中用来创建关系/关联的一种运算。图形系统中有三个操作符,cross, nestblend。接下来将介绍这些操作的具体定义,我们使用 A, B 来表示变量集合(varset),使用 VA, VB 来表示他们的值域。

Read more
初次见面,请多指教

这里是萝北北哦

大家好,这里是萝北北


【读书笔记】The Grammar of Graphics - 4. Variables

4. 变量(Variables)

一个变量能够关联一个具体的概念到数据上。变量与操作一起能够构成我们语法中的语句,如death*birth
在传统的统计系统中,变量代表着数据文件中的一列(column)。然而,由于这方面的规定并不统一,并没有明确的规定指名一个具体的概念是一行还是一列。唯一的规定是变量映射函数会返回有效范围内所有索引(index)对应的值。

4.1 转换(Transforms)

转化(transforms)的目的之一是对合适且有意义的变量进行统计。另一个目的则是创建新的变量、聚合或其他对数据的整体描述。
图4.1所示的就是一些常见的变量转换。其中X为变量集合。
table4.1.png

prank()会生成一列(i-0.5) i=1,2,3….的数列;zinv()会对x中的每一项求逆积累正态分布。

Read more
【读书笔记】The Grammar of Graphics - 3. Data

3. 数据

通常,数据被认为是数字性,一般通过机器、统计、测试、调查等方式获取到。

In a more general sense,
however, data are symbolic representations of observations or thoughts about
the world. As we have seen, we do not need to begin with numerals to create
a graphic. Text strings, symbols, shapes, pictures, graphs themselves, can all
be graphed. ()

“然而,从更广义的概念来讲,数据是一种对世界的观察与想法的符号化的表示。正如我们所见到的,我们不一定需要数字来创建图形。文本字符,符号,形状,图片以及图本身均可被绘制成图形。”

旧的绘图系统往往需要单纯的无结构的文件通过简单的“行与列”的方式存储。这种数据的存储方式一定程度上限制可以被绘制的图表类型(通常的柱状图、折线图、饼图、散点图)。

新的绘图系统将数据认为成数据源、这些数据源被认为是有一定潜在的内部结构的;并且可以支持流数据

本章主要将数据划分为三类:事实数据(empirical data)抽象数据(abstract data)以及元数据(meta data)

Read more
【读书笔记】The Grammar of Graphics - 2. How to make a pie

2. 绘制一张饼图

本章主要介绍如何用图形语法的思想完成从源数据到最终图形的完整工作流。

figure2.1.png
简单的讲,整个过程就是从数据源提取数据,进过”make a pie”的过程,生成图形,最终交给渲染器渲染。
对于”make a pie”的具体过程,作者给出了一个具体的方案:
figure2.2.png

Read more