Shirley

Shirley 查看完整档案

北京编辑  |  填写毕业院校  |  填写所在公司/组织 example.com 编辑
编辑

本人 冻冰美 懂得都懂

个人动态

Shirley 赞了文章 · 2月25日

万物互联的背后,有一座“数据围城”

物联网之父 Kevin Ashton 在近期的一次访谈中表示:“物联网的真正意义,不在于收集存储数据。更多场景下,在于正确高效地利用数据。”

之所以提出这个观点,是因为现阶段的物联网也被称作数据“泛在聚合”意义上的物联网。万物互联的时代造就了庞大的数据海洋,Kevin 认为应该通过对其中每个数据进行属性的精确标识,全面实现数据的资源化。

如果不能合理、合规、合情的利用这些数据,我们将会进入一座物联网时代的“数据围城”。

一、物联网时代的“数据围城”

未来学家托夫勒认为,改变世界的有四种力量:暴力、知识、金钱,以及大数据。

战争改变人类社会的走向,知识影响社会的发展轨迹,金钱操纵着世界发展的命脉。而大数据之所以能位列其中,是因为“大数据”就代表着社会的形态,如何定义和理解大数据,就是如何定义和理解这个社会。

物联网作为一种建立在互联网上的泛在网络,让互联网时代的大数据从量变发展到了质变 —— 数据既包含数据本身,也包含了物联网中的万物以及物的状态,物与物、物与人之间的交互。

“像是一座被围困的城堡,城外的人想冲进去,城里的人想逃出来。”这是钱钟书先生书中所描述的围城,而物联网时代的“数据围城”,是指数据虽然可以为我们认知社会、推进社会发展提供源源不断的动力,但却因为我们的不“善假于物”,被不合理的分析和解读。

二、为何要打破这座“数据围城”?

打破这座“数据围城”,既是互联网深入发展的必然要求,也是物联网的使命所在。

而想要打破这座“数据围城”,就需要在物联网所造就的数据海洋中,构建一种“泛在的聚合”关系,使人们不再受系统环境、外部设备和数据终端的限制,便可对各类数据执行方便的检索、计算和分析,并结合已有的数学分析模型,挖掘这些数据所代表的事务之间普遍存在的复杂联系,从而实现人类对周边世界认知能力的革命性飞跃。

打破“数据围城”的前提,是要洞悉物联网时代的数据特点,这其中包括了数据采集、数据处理、数据共享和数据的有效性甄别四个方面,只有在特定场景中进行特定的处理,数据才能转化成我们所需要的信息。

以数据采集为例,作为物联网的第一道关隘,若想打破“数据围城”,切入点必须从传感器入手。传感器是物联网感知层的数据接口,主要负责感知外界信息、响应上层指令,并配合各类终端设备完成数据的统一标准化接入。然而,不同类别的传感器所捕获的信息内容和信息格式均不相同,需要按一定的频率,周期性地采集环境信息并实时更新。随着现代物联网的发展,传感器本身也需要具备智能化处理的能力,即能够对物体实施智能控制。

因此,从传感器入手,需要思考的是如何重新定义“传感器”和“数据”间的关系。如果能将传感器和智能处理相结合,从海量信息中提取、分析、加工和处理数据,辅助业务决策,适应用户的多种需求,便能拓展出全新的应用领域和应用模式。

牵一发而动全身,仅仅从数据采集这一层切入,便要考虑如此多的因素。因此,若想真正打破物联网时代的“数据围城”,将会涉及物联网产业中的多个角色,但只要围绕着前文提到的数据特点进行突破,一定可以达到事半功倍的效果。

三、如何利用物联网时代的数据特点打破“数据围城”

物联网的本质是由众多生态、系统通过特定的规律整合而成,无论生态多么庞大、系统多么复杂,其都可以细分为一个个组件和功能模块,洞悉了这些组件和模块的数据特点,便可以推导出与之关联的物联网的“破城口”。

以现代企业智慧办公为例,来看一下在该场景如何利用各个组件和功能模块的数据特点打破这座“数据围城”。通过前文的分析,已知该场景的数据特点包含三个层面:数据共享、场景化(数据处理)和效率(数据的有效性甄别)。(详情请阅览:《纵观 Excel 演化史,开发者如何通过“表格技术”提升企业生产力》

其中的数据共享,既是该场景的特点,也是物联网时代数据的重要特征。进入物联网时代后,办公软件的使用场景从 PC 和桌面端,扩展到了移动设备、智能手机、PAD 等更多的移动端,企业所面临的智慧办公最大的难点也已经从单纯的一台操作设备,升级成跨设备以及多人之间的协作协同,越来越多的数据需要被采集、分享和运用。

在操作系统层面, HarmonyOS 借助了自身分布式软总线、分布式数据管理和分布式安全三大核心能力有效解决了跨设备的协同问题。但对于具体数据信息的采集、处理、共享和多人协作编辑,仍需要各类在线文档软件的支持。

在线文档类软件的出现,为企业办公提供了全新的工作模式,通过将办公数据从本地迁移到云端,打破了时间和空间的限制,用“更高的效率和更低的成本”实现了在线实时存储和多人协作,这一点也与物联网未来的发展不谋而合。

可见,对于在线文档类软件来说,只要能贴合物联网时代的数据特点,便可以协助打破这座“数据围城”。而无论是数据的采集、计算分析和多人协同交互等都离不开表格控件所提供的底层支持。葡萄城,作为物联网数据类应用落地“协作者”的代表之一,提供的正是这样的能力。(详情请阅览:打破技术壁垒, 用SpreadJS 抢占“表格文档协同编辑系统”的入市先机

作为全球领先的软件开发技术提供商,葡萄城以“ 赋能开发者”为使命,致力于通过各类软件开发工具和服务,创新开发模式,提升开发效率,服务企业数智化转型。

葡萄城研发的纯前端表格控件 SpreadJS ,提供了表格文档协同编辑、 数据填报和类Excel报表设计的功能支持,可帮助软件厂商和系统集成商有效应对数据处理、数据共享和数据有效性甄别等业务需要。

纯前端表格控件 SpreadJS

借助 SpreadJS“高性能、跨平台、与 Excel 高度兼容”的产品特性,可以让数据处理不再受硬件、操作系统与使用环境的限制,从而实现高效的在线填报、模板设计以及多人协同,构建出更为便捷、易用、安全的分布式数据管理架构。(了解详情:SpreadJS 纯前端表格控件

结语:物联网时代,重新审视人与世界间的关系

互联网时代让我们重塑了人与人之间的关系。而物联网时代则将这层关系网放大,需要让我们重新审视物与物、人与物之间的关系,这也是之所以需要打破这一座“数据围城”的意义所在。

了解物联网行业的朋友都知道,物联网产业链中包含八大环节:芯片提供商、传感器供应商、无线模组(含天线)厂商、网络运营商(含 SIM 卡商) 、平台服务商、系统及软件开发商、智能硬件厂商和技术服务提供商。

其中网络运营商负责的是物联网的底层通道,也是目前物联网产业链中最成熟的环节;芯片、传感器等硬件厂商则是物联网的大脑和四肢,低功耗、高可靠性的半导体芯片是物联网几乎所有环节都必不可少的关键部件之一;专供物联网的操作系统虽然仍处于起步阶段,但目前入局的都是 IT 行业的巨头,如谷歌、微软、苹果、华为、阿里等。

纵观整个环节中,目前最容易被忽视、最需要与物联网相结合的恰恰是物联网应用落地真正的“协作者” —— 技术服务提供商。他们才是万物互联时代链接人与物、人与物联网之间最直接的一根纽带。

打破万物互联时代的数据围城,既需要迎合时代大的技术背景,也需要聚焦到每个人的需求当中。我们需要华为、阿里、谷歌这类技术先锋为人类扩展技术的无限可能,也需要像 SpreadJS 这样的垂直细分产品,以人为中心,在技术大潮中服务用户的本质需求。

segmnetfault 思否

查看原文

赞 26 收藏 2 评论 1

Shirley 收藏了文章 · 2月3日

快速上手Grape:为什么每个人都应该有一套自己的脚手架?

作者:Run,总架构师
工作经验 5 年,当前就职行业知名技术公司,担任总架构师职位,擅长前后端技术栈,Ruby、Python、JavaScript 等语言。

内容目录

针对 Grape 框架的改进

深层 expose

你也许知道,expose 可以嵌套。如果传递的是个不带参的块,则会执行嵌套渲染:

class Entities::Article < Grape::Entity
 expose :user do
 expose :name { |article| article.user.name }
 expose :age { |article| article.user.age }
 end
end

如上,会渲染一个如下的数据结构:

{
 "user": {
 "name": "Jim",
 "age": 18
 }
}

如果此时传入 deep: true,则嵌套层绑定的 instance 就不一样了。下面的例子与上面的例子展示了同样的效果:

class Entities::Article < Grape::Entity
 expose :user, deep: true do
 expose :name
 expose :age
 end
end

接口返回值声明

status 用于声明接口的返回值(successfailentity 是特殊情况下的别名)。它有如下几种基本的调用形式:

status 200 do
 expose :article, using: Entities::Article
end
​
status 200, '返回文章数据' do
 expose :article, using: Entities::Article
end
​
status 400, '请求参数有误' do
 expose :code, desc: '错误码'
 expose :message, desc: '错误消息'
end
​
success '请求成功' do
 expose :article, using: Entities::Article
end
​
fail '请求失败' do
 expose :code, desc: '错误码'
 expose :message, desc: '错误消息'
end
​
entity do
 expose :article, using: Entities::Article
end

上述声明主要起两个作用:

  1. 在接口逻辑中调用 present 方法不用显示地指定 Entity 类型,它是自动解析的。

    以前,你必须这样调用:

    present :article, article, with: Entities::Article

    现在,只用这样:

    present :article, article

    因为在 status 声明中它已经知道如何渲染 article 实体了。

  2. status 声明可对应生成文档。

参数、返回值一体化

Grape::Entity 新加一个 to_params 方法,使得你可以在参数声明中重复利用:

params do
 requires :article, type: Hash do
 optional :all, using: Entities::Article.to_params
 end
end

它比 Grape::Entity.documentation 更好用,做了如下改进:

  1. type 可以写成字符串:

      expose :foo, documentation: { type: 'string' }
  2. 可混用额外参数,如同时指定 param_type 参数:

      expose :foo, documentation: { param_type: 'body' }
  3. 合理处理了 is_array

     expose :bar, documentation: { type: String, is_array: true }

针对测试的改进

现在可以用编程 style 的方式测试接口的返回值了,不需要再测试诸如 JSON 字符串、XML 文本之类的。如果像下面这样实现接口:

present :article, article

就可以像下面这样测试:

get '/article/1'
assert_equal 200, last_response.status
assert_equal articles(:one), presents(:article)

注意,这个功能不是实现在框架中的,需要克隆脚手架项目:

git clone https://github.com/run27017/grape-app-demo.git

新手如何上手

如果你是完全的新手,建议先从熟悉 Grape 框架开始。我建议您阅读我仓库下的文档。在您熟悉了 Grape 框架以后,再阅读以上我对 Grape 框架改进的部分。关于整个框架的设计理念,可阅读后文。

项目上手就从我提供的脚手架项目开始,所有功能都集成进来了:

git clone https://github.com/run27017/grape-app-demo.git

理念

面向文档的开发

当今环境下,有许多的开发范式供后端开发者选择,例如_测试驱动开发_、_行为驱动开发_、_敏捷软件开发_等等。与之相对的,我提出了一个新的想法,我将其称为_面向文档的开发_。

写 API 项目的同时是要准备文档的。我不知道大家是如何准备文档的,但往往都逃不出一个怪圈:同一个接口,我的实现要写一份,我的文档也要同时写一份。我常常在想,为什么我在写接口的同时不能将文档同步地完成呢?换个角度想,接口文档的契约精神为何不能自动地成为实现的一部分?如果,我能发明一个 DSL,在编写文档的同时就能够制约接口的行为,那不正是我想要的吗?

说干就干!

我发现 Grape 框架就已经提供了类似的 DSL 了。例如你在制定参数时可以像这样:

params do
 requires :user, type: Hash do
 requires :name, type: String, desc: '用户的姓名'
 requires :age, type: Integer, desc: '用户的年龄'
 end
end

上面的代码就可以对参数进行制约,限制参数为 nameage 两个字段,并分别限制它们的类型为 StringInteger. 与此同时,一个名为 grape-swagger 的库可以将 params 的宏定义渲染成 Swagger 文档的一部分。完美,文档和实现在这里结合了。

另外,Grape 框架提供了 desc 宏,它是一个纯文档的声明供第三方库读取,不会对接口行为产生任何影响。

desc '创建新用户' do
 tags 'users'
 entity Entities::User
end

但是,毕竟 Grape 框架不是完全的面向文档的开发框架,它有很多重要的使命,所以它和文档的无缝衔接也就仅限于此了。你能看到,params 宏是个完美结合的范例,desc 宏很可惜只与文档渲染有关,然后就别无其他了。

鉴于 Grape 框架是个开源框架,修改它以添加几个小零件还是很简易的一件事。我用了几天的时间添加了一个 status 宏,可以用它来声明返回值:

status 200 do
  expose :user, deep: true do
    expose :id, documentation: { type: Integer, desc: '用户的 id' }
    expose :name, documentation: { type: String, desc: '用户的姓名' }
    expose :age, documentation: { type: Integer, desc: '用户的年龄' }
  end
end

上述声明主要起两个作用:

  1. 在接口逻辑中调用 present 方法不用显示地指定 Entity 类型,它是自动解析的。

    以前,你必须这样调用:

    present :user, user, with: Entities::User

    现在,只用这样:

    present :user, user

    因为在 status 声明中它已经知道如何渲染 user 实体了。

  2. grape-swagger 库可以解析 status 宏生成文档。

一切还只是冰山一角。

你真的不需要 Controller 测试吗?

有关接口的单元测试,有两个观点争论不休:接口测试应该是针对 Integration 测试还是 Controller 测试?Integration 测试像是一个黑匣子,开发者调用接口,然后针对接口返回的视图进行测试。而 Controller 测试也会一样地调用接口,但会测到内部的状态。

通过下面的两个案例直观地感受一下 Controller 测试和 Integration 测试在 Rails 框架中的不同写法。

在早期的 Rails 版本中,是有 Controller 测试的:

class ArticlesControllerTest < ActionController::TestCase
  test "should get index" do
    get :index
    assert_response :success
    assert_equal users(:one, :two, :three), assigns(:articles)
  end
end

Rails 5 以后,更推荐 Integration 测试:

class ArticlesControllerTest < ActionDispatch::IntegrationTest
 test "should get index" do
 get articles_url
 assert_response :success
 end
end

注意到 Integration 测试中是没有对应的 assert_equal 语句的,因为它比较难写。如果视图返回的是 JSON 数据,可以尝试用下面的等效写法:

assert_equal users(:one, :two, :three).as_json, JSON.parse(last_response.body)

但是测试视图的代码及其依赖视图的变化,也会经常性的失效,上面只是尝试性的一种写法而已。

我不想在这里探讨 Controller 测试和 Integration 测试究竟孰优孰劣的问题,尽管你可能已经从字里行间察觉到我的倾向性。关于这个话题能够从 2012 年讨论到 2020 年,不信你可以看这个帖子。我可不想让情况变得更糟。很多次我在想,那些反对 Controller 测试的人可能仅仅把 Controller 的实例变量看成是其内部状态而已,而没有意识到它也是 Controller 与 Template 之间的契约。这不怪他们,因为用传递实例变量的方式定义契约确实不够优雅。

好在我做了一些简单的工作,让其在 Grape 框架内可以更优雅地测试接口的返回。你只需要在逻辑接口中使用 present 方法指定渲染数据:

present :users, users

然后就可以在测试用例中结合特殊的 presents 方法测试它:

assert_equal users(:one, :two, :three), presents(:users)

assigns 很像,但是它更舒服不是么?

写在最后

这就是我对 Grape 框架的改造过程,已经开始并将持续下去。我的改造理念无外乎两个想法:更好的文档结合和更好的测试。而事实上,只需要一点点工作,确实就可以起作用了。

如果你也想用到我所改造的 Grape 框架,直接克隆我的脚手架就好了:

git clone https://github.com/run27017/g...

脚手架中使用的是我 Fork 后的框架集,它们是:

点击它们的链接看一看吧,也许你也能成为开源世界的贡献者呢。

推荐

如果想了解学习更多可以看我最新录制的课程

课程链接:https://ke.sifou.com/course/1...

设计这门课的初衷
  • 当前 Web 开发的主流模式:前后端分离
  • Web API 开发,没有必要五花八门,应采用最佳实践
  • 将自己多年的实践经验总结并分享
这门课在讲什么?
  • 遵循标准:最小惊讶原则
  • 接口的完备性:输入和输出、鉴权、错误处理等
  • 与框架整合
为什么每个人都应该有一套自己的脚手架?
  1. 框架只是通用模版的提供者,并没有安排具体的解决方案
  2. 框架并没有细化到最佳实践
查看原文

Shirley 赞了文章 · 2月1日

快速上手Grape:为什么每个人都应该有一套自己的脚手架?

作者:Run,总架构师
工作经验 5 年,当前就职行业知名技术公司,担任总架构师职位,擅长前后端技术栈,Ruby、Python、JavaScript 等语言。

内容目录

针对 Grape 框架的改进

深层 expose

你也许知道,expose 可以嵌套。如果传递的是个不带参的块,则会执行嵌套渲染:

class Entities::Article < Grape::Entity
 expose :user do
 expose :name { |article| article.user.name }
 expose :age { |article| article.user.age }
 end
end

如上,会渲染一个如下的数据结构:

{
 "user": {
 "name": "Jim",
 "age": 18
 }
}

如果此时传入 deep: true,则嵌套层绑定的 instance 就不一样了。下面的例子与上面的例子展示了同样的效果:

class Entities::Article < Grape::Entity
 expose :user, deep: true do
 expose :name
 expose :age
 end
end

接口返回值声明

status 用于声明接口的返回值(successfailentity 是特殊情况下的别名)。它有如下几种基本的调用形式:

status 200 do
 expose :article, using: Entities::Article
end
​
status 200, '返回文章数据' do
 expose :article, using: Entities::Article
end
​
status 400, '请求参数有误' do
 expose :code, desc: '错误码'
 expose :message, desc: '错误消息'
end
​
success '请求成功' do
 expose :article, using: Entities::Article
end
​
fail '请求失败' do
 expose :code, desc: '错误码'
 expose :message, desc: '错误消息'
end
​
entity do
 expose :article, using: Entities::Article
end

上述声明主要起两个作用:

  1. 在接口逻辑中调用 present 方法不用显示地指定 Entity 类型,它是自动解析的。

    以前,你必须这样调用:

    present :article, article, with: Entities::Article

    现在,只用这样:

    present :article, article

    因为在 status 声明中它已经知道如何渲染 article 实体了。

  2. status 声明可对应生成文档。

参数、返回值一体化

Grape::Entity 新加一个 to_params 方法,使得你可以在参数声明中重复利用:

params do
 requires :article, type: Hash do
 optional :all, using: Entities::Article.to_params
 end
end

它比 Grape::Entity.documentation 更好用,做了如下改进:

  1. type 可以写成字符串:

      expose :foo, documentation: { type: 'string' }
  2. 可混用额外参数,如同时指定 param_type 参数:

      expose :foo, documentation: { param_type: 'body' }
  3. 合理处理了 is_array

     expose :bar, documentation: { type: String, is_array: true }

针对测试的改进

现在可以用编程 style 的方式测试接口的返回值了,不需要再测试诸如 JSON 字符串、XML 文本之类的。如果像下面这样实现接口:

present :article, article

就可以像下面这样测试:

get '/article/1'
assert_equal 200, last_response.status
assert_equal articles(:one), presents(:article)

注意,这个功能不是实现在框架中的,需要克隆脚手架项目:

git clone https://github.com/run27017/grape-app-demo.git

新手如何上手

如果你是完全的新手,建议先从熟悉 Grape 框架开始。我建议您阅读我仓库下的文档。在您熟悉了 Grape 框架以后,再阅读以上我对 Grape 框架改进的部分。关于整个框架的设计理念,可阅读后文。

项目上手就从我提供的脚手架项目开始,所有功能都集成进来了:

git clone https://github.com/run27017/grape-app-demo.git

理念

面向文档的开发

当今环境下,有许多的开发范式供后端开发者选择,例如_测试驱动开发_、_行为驱动开发_、_敏捷软件开发_等等。与之相对的,我提出了一个新的想法,我将其称为_面向文档的开发_。

写 API 项目的同时是要准备文档的。我不知道大家是如何准备文档的,但往往都逃不出一个怪圈:同一个接口,我的实现要写一份,我的文档也要同时写一份。我常常在想,为什么我在写接口的同时不能将文档同步地完成呢?换个角度想,接口文档的契约精神为何不能自动地成为实现的一部分?如果,我能发明一个 DSL,在编写文档的同时就能够制约接口的行为,那不正是我想要的吗?

说干就干!

我发现 Grape 框架就已经提供了类似的 DSL 了。例如你在制定参数时可以像这样:

params do
 requires :user, type: Hash do
 requires :name, type: String, desc: '用户的姓名'
 requires :age, type: Integer, desc: '用户的年龄'
 end
end

上面的代码就可以对参数进行制约,限制参数为 nameage 两个字段,并分别限制它们的类型为 StringInteger. 与此同时,一个名为 grape-swagger 的库可以将 params 的宏定义渲染成 Swagger 文档的一部分。完美,文档和实现在这里结合了。

另外,Grape 框架提供了 desc 宏,它是一个纯文档的声明供第三方库读取,不会对接口行为产生任何影响。

desc '创建新用户' do
 tags 'users'
 entity Entities::User
end

但是,毕竟 Grape 框架不是完全的面向文档的开发框架,它有很多重要的使命,所以它和文档的无缝衔接也就仅限于此了。你能看到,params 宏是个完美结合的范例,desc 宏很可惜只与文档渲染有关,然后就别无其他了。

鉴于 Grape 框架是个开源框架,修改它以添加几个小零件还是很简易的一件事。我用了几天的时间添加了一个 status 宏,可以用它来声明返回值:

status 200 do
  expose :user, deep: true do
    expose :id, documentation: { type: Integer, desc: '用户的 id' }
    expose :name, documentation: { type: String, desc: '用户的姓名' }
    expose :age, documentation: { type: Integer, desc: '用户的年龄' }
  end
end

上述声明主要起两个作用:

  1. 在接口逻辑中调用 present 方法不用显示地指定 Entity 类型,它是自动解析的。

    以前,你必须这样调用:

    present :user, user, with: Entities::User

    现在,只用这样:

    present :user, user

    因为在 status 声明中它已经知道如何渲染 user 实体了。

  2. grape-swagger 库可以解析 status 宏生成文档。

一切还只是冰山一角。

你真的不需要 Controller 测试吗?

有关接口的单元测试,有两个观点争论不休:接口测试应该是针对 Integration 测试还是 Controller 测试?Integration 测试像是一个黑匣子,开发者调用接口,然后针对接口返回的视图进行测试。而 Controller 测试也会一样地调用接口,但会测到内部的状态。

通过下面的两个案例直观地感受一下 Controller 测试和 Integration 测试在 Rails 框架中的不同写法。

在早期的 Rails 版本中,是有 Controller 测试的:

class ArticlesControllerTest < ActionController::TestCase
  test "should get index" do
    get :index
    assert_response :success
    assert_equal users(:one, :two, :three), assigns(:articles)
  end
end

Rails 5 以后,更推荐 Integration 测试:

class ArticlesControllerTest < ActionDispatch::IntegrationTest
 test "should get index" do
 get articles_url
 assert_response :success
 end
end

注意到 Integration 测试中是没有对应的 assert_equal 语句的,因为它比较难写。如果视图返回的是 JSON 数据,可以尝试用下面的等效写法:

assert_equal users(:one, :two, :three).as_json, JSON.parse(last_response.body)

但是测试视图的代码及其依赖视图的变化,也会经常性的失效,上面只是尝试性的一种写法而已。

我不想在这里探讨 Controller 测试和 Integration 测试究竟孰优孰劣的问题,尽管你可能已经从字里行间察觉到我的倾向性。关于这个话题能够从 2012 年讨论到 2020 年,不信你可以看这个帖子。我可不想让情况变得更糟。很多次我在想,那些反对 Controller 测试的人可能仅仅把 Controller 的实例变量看成是其内部状态而已,而没有意识到它也是 Controller 与 Template 之间的契约。这不怪他们,因为用传递实例变量的方式定义契约确实不够优雅。

好在我做了一些简单的工作,让其在 Grape 框架内可以更优雅地测试接口的返回。你只需要在逻辑接口中使用 present 方法指定渲染数据:

present :users, users

然后就可以在测试用例中结合特殊的 presents 方法测试它:

assert_equal users(:one, :two, :three), presents(:users)

assigns 很像,但是它更舒服不是么?

写在最后

这就是我对 Grape 框架的改造过程,已经开始并将持续下去。我的改造理念无外乎两个想法:更好的文档结合和更好的测试。而事实上,只需要一点点工作,确实就可以起作用了。

如果你也想用到我所改造的 Grape 框架,直接克隆我的脚手架就好了:

git clone https://github.com/run27017/g...

脚手架中使用的是我 Fork 后的框架集,它们是:

点击它们的链接看一看吧,也许你也能成为开源世界的贡献者呢。

推荐

如果想了解学习更多可以看我最新录制的课程

课程链接:https://ke.sifou.com/course/1...

设计这门课的初衷
  • 当前 Web 开发的主流模式:前后端分离
  • Web API 开发,没有必要五花八门,应采用最佳实践
  • 将自己多年的实践经验总结并分享
这门课在讲什么?
  • 遵循标准:最小惊讶原则
  • 接口的完备性:输入和输出、鉴权、错误处理等
  • 与框架整合
为什么每个人都应该有一套自己的脚手架?
  1. 框架只是通用模版的提供者,并没有安排具体的解决方案
  2. 框架并没有细化到最佳实践
查看原文

赞 6 收藏 2 评论 0

Shirley 赞了文章 · 1月21日

大佬那么多,为什么不能是我 | 卡颂2020年终总结

前几天北京公布一例确诊病例 —— 一位居住于顺义的34岁男子。伴随公告的,还有其最近一段时间的完整活动轨迹:

  • 工作日在家与公司之间往返50km,日复一日
  • 周末只有超市采购和带孩子参加早教活动才会出门,其他时间都宅在家里
  • 宅在家里是为了玩么?不,他的业余时间都用于复习考研。坊间传闻是清华大学

最终在考研前3天被公司安排去宁波出差。在出差前由于考研初试要求做了核酸检测,并最终确诊。

当前的最新情况:已放弃考研,病情稳定。祝福这位努力生活的大哥早日康复。

这是一个奋斗bi么?不,这只是漂泊在北上广深,为了更好的生活,用自己日复一日的努力与生活抗争的普普通通打工人。

成年人的世界没有轻松可言

作为一个浑浑噩噩、当过魔术师、做过机械工程师的转行半吊子前端。年初由于疫情在家,对自己发出了来自灵魂的质疑:

大佬那么多,为什么不能是我?

明明很努力在生活,为什么我还是菜鸡?

自认智商没有不如常人,那么答案只剩下一个:

我努力的方向不对

在调整了方向并奋力奔跑了一整年后,以下是我交出的答卷:

  • 写了一本开源电子书React技术揭秘,2.1k star
  • 组建了2000+人的React学习社群
  • SegmentFault合作录制课程自顶向下学 React 源码,并成为SegmentFault优秀讲师
  • 成为Anu.jsReactContributor,是从业以来技术水平提升最快的一年
  • 有了主业之外的副业,虽然才刚起步,但也能覆盖我在北京的衣食住行了

以上这些都是在8小时之外的业余时间完成的,以下是我的心路历程。

疫情期间在家办公

疫情期间在家办公

探索知识边界

首先来聊聊核心的思路:

探索知识边界

前端作为一个技术工种,存在知识边界,边界可以分为:

  • 横向上的广度边界
  • 纵向上的深度边界

横向上,有些工种天然与前端接近,比如产品服务端。提升自己这些相邻工种的能力可以提升自己对业务的整体把控。

纵向上,以传统HTMLJSCSS为代表的前端领域可以看作一个大圆,在圆周上,还有很多其他领域的圆与这个大圆相交,这些小圆就是前端知识深度上的边界

有些小圆与前端大圆相交范围比较多,比如:

  • 前端工程化,日常工作都会接触
  • 框架开发,日常工作都会使用前端框架

还有些小圆涉及到其他领域知识比较多,与前端相交的少,比如:

  • 数据可视化
  • 跨端开发

但是人的精力都是有限的,横向、纵向,该往哪里努力?

前端人的努力方向

从职业发展来看,前端有2个方向:

  • 技术经理
  • 前端架构师

其中技术经理要求技术管理能力,前端架构师要求更高的工程化能力。同时这两者都需要产品服务端能力。

所以横向上,前端人应该更多发展相邻工种的能力。像算法运维这些不与前端相邻的工种,付出了同样的努力,收益并不大。

纵向上,建议根据个人喜好,选择一个知识边界作为自己突破的方向。做一个三角形前端

比如:你很看好数据可视化,为此付出大量努力,配合上横向方向的努力,你更容易成为可视化领域的产品负责人。但是未来更不容易切换赛道。

同理:一个做了几年富文本编辑器的前端可以成为该领域的大拿,但是他积累的领域知识在其他业务上用处就没那么大了。

所以,我建议发展更贴近日常开发的领域知识,即前端工程化框架开发

考虑到日常使用React技术栈,未来大概率会长时间用他,我决定将React框架开发作为我努力的方向。

死磕React

坦白讲:这一年,最少有5次我想放弃这个努力方向。

React源码中那么多方法,除了React核心团队成员,谁能真正理解这些方法的作用?这可是全世界最厉害的一批前端维护了7年的代码库啊。

有些同学和我抱怨,看了2天React源码看不懂,为啥我对源码里每个方法的调用流程这么熟悉?

我业余时间看了半年啊!

到了React这个级别的源码,已经不是看代码就能明白意思的了,得先明白设计理念。

于是,在把往年所有React Conf演讲内容、React核心团队成员在gayhubtwitter油管的分享看完后,终于产出了一本“先讲理念,再讲运行流程,再讲局部源码”的电子书 —— React技术揭秘

我的收获

在这本书的写作过程中,逐渐有朋友加我微信和我讨论React,慢慢竟然形成了2000人的社群。群里有很多知名库的作者、参与者、技术大拿、知识领域优秀UP主、公众号主。

再后来,由于这本电子书,SegmentFault的商务找到我,合作出品了自顶向下学 React 源码视频课程,课程口碑不错,让我成为了SegmentFault优秀讲师。

React在我面前再没有秘密后,日常业务方面可以说通关了。

比较有意思的是,我们有些业务用的是一款类React框架 —— Anu.js

去年遇到框架bug后还一脸懵逼,今年已经开始维护这款框架并将React中的一些试验特性搬移过来,比如时间切片

8月初开始做公众号,我的文章特点是:专注React技术栈,对于React问题,从源码层面给出答案。

收入方面,也有了睡后收入 —— 每个月会有广告、课程收入,6000 - 1w之间。

2021,我要做大佬

今年的经历验证了我的观点 —— 只要方向对了,努力就有意义。

2021,也要努力在成为大佬的路上飞奔。

本文参与了 SegmentFault 思否征文「2020 总结」,欢迎正在阅读的你也加入。

查看原文

赞 7 收藏 0 评论 1

Shirley 赞了文章 · 1月21日

万万没想到,良许也开挂了

本来年终总结要在元旦前写的,但最近这段时间一直在看房,买房,办手续,前两天才终于全部弄完了,终于有时间来写总结啦~

大家好,我是良许。

2020 年很魔幻,各种幺蛾子事件不断出现,大家过的都很不容易。

我们被迫见证了许多生离死别,一起经历了长时间不能出门的日日夜夜。

有人失业,有人痛哭,有人失去自由,也有人经历人生高光时刻,好在我们都走过来了。

对于我个人而言,我的 2020 年也是非常充实与神奇。在这一年里,我玩直播,拍视频,健身,搞网站,见大佬,赚钱、买房理财陪伴家人,工作虽辛苦,但成果满满,下面向大家简单的汇报下。

公众号

今年花了很多心血在公众号经营上,写原创、做运营,希望能给大家带去更加的价值。5月份,公众号读者数终于突破 10W ,进入了十万粉俱乐部,成为 Linux 领域名副其实的 Top3 !

图片

买房

2020 年的最后一天最后一个小时,给我家的宝贝签了套学区房,作为她的生日礼物。

说起买房,过程还是很激动,31日谈价到半夜,在 2020 年最后几分钟达成协议,签订合同,算是给我家宝宝的一份独特的生日礼物(宝宝元旦生日)。

毕业 6 年,宝宝 2 岁,终于有了人生第一套房子,有了自己的一个小窝。这套房子是学区房,大几百万,首付一百五十多万,没有靠任何人,全凭我们俩的努力攒下的,还是很感慨。感谢我老婆陪我白手起家,mua~~~

毕业后一直租房,记得最开始租的是厦门城中村,一个月 400 元,房间小的只容得下一张床,看着陪我一起吃苦的老婆,心里默默的发誓,以后一定给她一个家。

这些年,我们两个也算是励志,一点点的拼事业,互相鼓励,互相扶持。我从机械转行至IT,连续半年每天陪我加班到 12 点,陪我度过了转行的最艰难时期。她从银行转岗至家庭风险规划师,我做她坚强的后盾。算是互相支持与鼓励吧,未来请继续多多关照。

2020年赚了多少钱?

很多读者私信我一年赚多少钱,一直没正面回答过。2020 年,我的收入实现了几倍增长。现在的收入,月薪和第一份工作年薪相当。据我了解,我现在收入超过了我前经理,甚至总监收入。

那么我的收入主要来自哪些呢?主要来自以下几块:

  1. 公众号广告
  2. 流量主
  3. 赞赏
  4. 朋友圈广告
  5. 理财收益

对于广告我这边要特意说明一下。有些朋友可能对广告比较反感,实际上,一个好的生态,商业变现是必不可少的。既要让马跑,又要让马不吃草,这是非常不现实的一件事。如果不让自媒体人商业变现,这些人就没活路,就不会持续给大家输出优质干货。

反过来,让这些自媒体人适当恰饭,他们就会更有动力去生产更多优质内容,读者能获得更多干货,这样才是一个良性的循环。

言归正传。除了以上这些收入之后,我还有很大一部分收入来自理财。在过去的一年里,我们家庭通过理财实现了 35% 左右的收益率。

股票收益:

图片

基金收益:

图片

别误会,我并不懂理财,也没啥时间理财,哈哈~家里财政大权是我老婆——良许嫂,所以理财这部分主要由她负责。我们的分工还比较明确,男主外,女主内。赚钱主要由我来赚,理财就交给她来打理。

好在良许嫂在银行工作多年,对理财这块还比较懂,并且有途径知道一些小道消息,而且对经济形势把握比较准确,所以在她的打理下我们通过理财也实现了不错的收益。

如果大家对理财有兴趣的,可以加她微信进行交流。她还有个理财交流群,纯交流无广告,也有一些理财大佬在分享他们的经验。

图片

搭建网站

在我看来,作为一名合格的互联网人,个人网站是一个必备之物。所以,在经过一番学习之后,我用 Wordpress 搭建了一个个人网站。

在我的网站里我将继续给大家分享 Linux 方面的技术干货。公众号虽好,但局限性太大,一天只能发一次,限制太多。而在个人网站,一天想发多少发多少,发完还可以任意修改。只要不违法,你可以任意运营你的网站。

所以,我打算在网站上分享一些系列教程,给大家提供更多干货,也方便大家的阅读。网址如下:

www.lxlinux.net

图片

玩直播

这两年直播行业非常火热,我也趁着这个浪潮玩了仅有的一次直播。年初与合作很久的机械工业出版社邀请我做一场关于Linux领域学习的直播,帮他们带货。

但因为没有直播经验,也没有带货经验,我一开始还有点犹豫。后面想着反正疫情期间隔离在家也没事做,而且我也对直播行业充满好奇,何不来试试尝个鲜,顺便提高一下自己的表达能力?

于是我欣然接下了这个活。

果不其然,没有任何直播经验的我一路磕磕碰碰,结结巴巴,全程充满了尴点……

但是,直播的效果却出奇的好,我推荐了 8 本书(好像),居然有 3 本被我当场卖到断货!!得知这个结果我简直是惊呆了……甚至我还一度幻想我又离李佳琦又进了一步……

这个成绩,当然不是我的直播水平有多强,而是我众多的读者朋友对我的支持与信任。在此,我再次向我的读者朋友们鞠躬致谢!

图片

图片

拍视频

2020 年,各大平台都不约而同地非常重视视频内容,我相信这肯定又是一个不错的方向,于是我开始全力进军短视频,进入 B 站当 UP 主。

刚进场,我的运气就不错,几乎所有的视频都得到了推荐,都是上万以上的播放量。每天早上最开心的一件事,就是奔向电脑,看我的视频播放量涨了多少,粉丝又涨了多少。

但是,做视频是一件非常费时费力的工作,不仅要选题、写稿、拍摄、剪辑,等等工作。这些工作,每个环节都需要花费很多时间,相对纯文本输出不知道要难多少。

但好在我的视频得到了不少的肯定,视频下方很多人留言说得到了很大的帮助,解答了很多疑惑。看到这些留言,我真心觉得我做的这些事情都是值得的!

图片

健身

作为一个资深的宅男,我的身材一天比一天臃肿,体重有压爆体重秤的趋势。于是我决定去健身。

我是一个非常自律又坚毅的人,开始健身后,我几乎每天都会往健身房跑,大有把健身房练跨的趋势。

健身的成效比较明显,3 个月减掉 22 斤,从 77 公斤减到了 66 公斤,达到了我理想的身高体重比了。

为此,我还特地写了篇文章,分享我的健身减肥经验。

瘦了14斤!

减肥成功之后,我的身体发生了很大的改变。脸形变小了,脸色红润了,之前穿不下野夫也轻松穿上了。一出门,认识我的朋友们都说,良许你瘦了好多!

其实我不算健身爱好者,但为了保持身体健康,我还会继续坚持健身。毕竟,身体是革命的本钱。

图片

见大佬

因为疫情的原因,前半年大家基本都窝在家,所以能够出门见大佬都是在后半年。

在这半年里,我见到了很多大佬。8 月底的时候,我去苏州参加了一场牛逼的大佬聚会。在这个聚会里,来了有二三十个大佬,这些大佬,粉丝数加起来应该覆盖了程序员的半壁江山。

良许被百万大V安排得服服帖帖,还跟美女小姐姐合影了……

图片

国庆期间,我去了厦门,再次见到了老戴和田总。老戴是技术自媒体很资深的一位前辈,也是我很尊敬的一位大佬,给了我很多很实用的建议。

低调的田总大家可能不认识,但他的网站程序员几乎都知道——菜鸟教程。他的流量大到可怕,但他非常注重用户体验,非常注重内容,因此他的网站一直发展不错,口碑非常好。

图片

11月底,我参加了生财有术广州线下见面会。这次见面会,云集了 450 多各行各业的大佬,并且很多大佬都做了非常精彩的分享。不得不说,生财有术是个卧虎藏龙的地方,各种各样花式赚钱方法真的让人应接不暇。这是我加入的最有质量的一个社群,没有之一!

图片

12 月的时候,受到 36Kr 创始人刘总的委托,我帮他组建了一个资深 Linux 程序员大佬聚会。同时也很荣幸受到他的邀请,我从广州飞到了北京,见到了刘总本人。刘总很谦虚、平易近人,资产过亿,富有传奇经历,却对我一点架子都没有,真是大佬风范!

图片

当然,我还见到了其他的一些大佬,限于篇幅就不一一介绍,请大佬们不要见怪!

写在最后

2020 年实在太魔幻了,但我们无法改变历史的行程,只能学会适应,毕竟这个世界唯一不变的就是变。

在过去的一年里,我也是在不停地尝试,不停地试错,不停适应这个变幻莫测的世界。在这一年里,我有成功的喜悦,有失败的泪水,也迷茫过,失望过,挣扎过,无助过……

但是,我从来没有放弃过!我,良许,一直在路上!

你好,2021,相信这一年会更美好!

本文参与了 SegmentFault 思否征文「2020 总结」,欢迎正在阅读的你也加入。

查看原文

赞 4 收藏 2 评论 3

Shirley 收藏了文章 · 1月14日

前端大数据可视化从入门到实战

作者:小天

大家好,我是小天,从事于一家金融类公司,负责前端架构与大数据可视化相关工作。本篇文章与大家简单聊一下前端与数据可视化。

相信从事前端开发人员还是对于html,css,javascript,Browser等等有一定认识了解的。但是了解的程度如何呢? 知道含义?简单/熟练使用?深入研究?

请大家试着回答我下面几个问题:

  1. 页面编写是否更多还停留在 div 套 div ?样式编写更多还是宽,高,定位?
  2. JavaScript 是否深入了解过? javascript 为什么是单线程呢?(设计初衷?受限原因?)
  3. JavaScript 在 Browser (浏览器)中如何运行的? 如何编译的?( 预编译?即时编译? )
  4. 在前端领域内自己是否有专注的一个方向?或者说是找工作的杀手锏?
试着解答过后或许结果并不是那么理想,结果如何没有太大关系,个人认为有问题不可怕,及时发现问题就是好的结果。对于每个人来说都不是万能的,是需要时刻学习,时刻进步的。

首先这边 1,2,3 点本篇不展开讲解,网上资料很多可以自行解决有相关具体疑惑地方的话可以留言, (主要前面都是铺垫- -,),咱们直接进入今天的重点,前端领域大家是否有选择一个方向进行深入研究(或者说是找工作的杀手锏)?

这道问题的答案个人觉得深度比广度更容易体现价值。如果因为某些意外大家还没有确定选择方向(那是最好的,哈哈我的机会来了)那么可以认真往下看,说不准本门课程会激发了你的斗志,继而选择了之后深耕的领域,成为领域专家,成为找工作的一个杀手锏。

什么是数据可视化

数据可视化是将数据转化成为交互的图形或图像等,以视觉感受的方式表达,增强人的认知能力,达到发现、解释、分析、探索、决策和学习。

数据可视化主要旨在借助于图形化⼿段,清晰有效地传达与沟通信息。

前端中数据可视化

首先日常开发中越来越多的可视化需求,例如静态类图表如:柱状图,折线图;交互式图表如:网络分析图,智慧社区等等。很多大厂进行了岗位划分,可视化工程师逐渐分离出来(越来越多的重视,导致很多公司投入专门团队研发可视化方向。。。所以前景是一片希望,光明。) 但是从实际出发更多的人研发是通过现成的可视化库去实现自己的需求,这边举几个例子:

  1. D3.js
  2. echarts.js
  3. three.js
  4. Chart.js
  5. cytoscape.js
  6. sigma.js
  7. AntV(G2 G6等)
  8. Go.js
  9. …其他

首先说明本人这边所举框架都是各有优势,例举无排名先后哈,有幸这些技术本人或多或少都有相关技术调研及使用。还是要从业务需求业务场景来考虑到底使用哪一种可视化库。比如D3.js有丰富的动画,交互式图表(事件),图算法;echarts.js 丰富的图表类型,绚丽的特效,支持多渲染引擎等等。

最后说一下本人的一点看法,市面上的可视化库架构设计出发角度更多是抽象化的功能,满足大众化的需求。个人认为好的可视化一定要有”灵魂”,它应该通过可视化完备交互,探索式分析的方式以及背后强大的算力能帮助用户更快更准提取有效价值;如何更好体现业务价值,从交互 算法底层是需要深入研究,自研往往是必经之路。(P:自研此处指并非完全从零实现一个可视化库,可以在现有库基础进行拓展加入业务定制化,比如业务型算法)

如何深入可视化

先来了解一下可视化基础技术架构,基础包含需要:
  1. 渲染层负责可视化图形图像生成相关 API 研发,比如:绘制圆,三角形等
  2. 算法层负责可视化图形图像生成相关算法,比如:布局算法 绘制元素坐标计算如何分布等
  3. 数据层负责数据相关操作,比如:数据增删改查以及数据与视图进行一致性保证等
  4. 其他层例如通信层 工具层等
其次大家都知道很多框架渲染引擎内部是canvas / svg / webgl 实现的,内部到底如何实现? 那么接下来对于渲染层拿canvas举例进行探讨:

图图1.png

比方说实现上方这个可视化图表效果,从canvas绘制层来说,需要提供俩个绘制 API :

  1. 绘制圆形元素
  2. 绘制连线元素
在开始绘制之前

图图2.png

绘制圆形

图图3.png

绘制曲线

图图4.png

以上就是所需要提供的绘制层 API ,后续需要结合算法层比如通过 layout (布局算法)计算节点分布坐标计算、通过节点出入度和业务规则计算节点大小等进行绘制渲染,就可以实现上面美观的可视化。

最后

是不是很有意思呢?
如果想了解学习更多可以看我最新录制的课程

课程链接:https://ke.sifou.com/course/1...

image

课程大纲介绍:

为什么要学这门课?
  • 前端新机遇:大数据可视化
  • 前端开发中的图形学
基础篇:像素级操作大师 Canvas
  • 重新认识Canvas
  • Canvas的优势及特性详解
  • Canvas形状绘制:文本&样式&图片
  • Canvas动效设计与实现
  • Canvas用户交互设计与实现
进阶篇:从零研发关系可视化组件
  • 可视化组件架构设计
  • 编写关系类绘制组件
  • 编写关系类算法(FR)
实战篇:热门可视化库实战
  • d3 入门
  • d3 实战:tree 层级图
  • d3 实战:bar 图表
  • echarts 入门
  • echarts 实战:sankey 图
实战篇:研发关系可视化分析平台
  • 架构设计说明
  • 数据采集清洗
  • 消息机制学习
  • 事件交互学习
  • 项目代码实现
查看原文

Shirley 关注了用户 · 1月14日

思否编程 @sfbc

思否编程是由中国新一代开发者社区 SegmentFault 思否孵化的在线编程培训平台,通过提升开发者 IT 职业技能,帮助开发者获得成功

思否编程网址:https://ke.sifou.com/
申请成为讲师:https://jinshuju.net/f/HK5r9K

添加编程小姐姐微信:bobonadia

关注 8465

Shirley 赞了文章 · 1月14日

前端大数据可视化从入门到实战

作者:小天

大家好,我是小天,从事于一家金融类公司,负责前端架构与大数据可视化相关工作。本篇文章与大家简单聊一下前端与数据可视化。

相信从事前端开发人员还是对于html,css,javascript,Browser等等有一定认识了解的。但是了解的程度如何呢? 知道含义?简单/熟练使用?深入研究?

请大家试着回答我下面几个问题:

  1. 页面编写是否更多还停留在 div 套 div ?样式编写更多还是宽,高,定位?
  2. JavaScript 是否深入了解过? javascript 为什么是单线程呢?(设计初衷?受限原因?)
  3. JavaScript 在 Browser (浏览器)中如何运行的? 如何编译的?( 预编译?即时编译? )
  4. 在前端领域内自己是否有专注的一个方向?或者说是找工作的杀手锏?
试着解答过后或许结果并不是那么理想,结果如何没有太大关系,个人认为有问题不可怕,及时发现问题就是好的结果。对于每个人来说都不是万能的,是需要时刻学习,时刻进步的。

首先这边 1,2,3 点本篇不展开讲解,网上资料很多可以自行解决有相关具体疑惑地方的话可以留言, (主要前面都是铺垫- -,),咱们直接进入今天的重点,前端领域大家是否有选择一个方向进行深入研究(或者说是找工作的杀手锏)?

这道问题的答案个人觉得深度比广度更容易体现价值。如果因为某些意外大家还没有确定选择方向(那是最好的,哈哈我的机会来了)那么可以认真往下看,说不准本门课程会激发了你的斗志,继而选择了之后深耕的领域,成为领域专家,成为找工作的一个杀手锏。

什么是数据可视化

数据可视化是将数据转化成为交互的图形或图像等,以视觉感受的方式表达,增强人的认知能力,达到发现、解释、分析、探索、决策和学习。

数据可视化主要旨在借助于图形化⼿段,清晰有效地传达与沟通信息。

前端中数据可视化

首先日常开发中越来越多的可视化需求,例如静态类图表如:柱状图,折线图;交互式图表如:网络分析图,智慧社区等等。很多大厂进行了岗位划分,可视化工程师逐渐分离出来(越来越多的重视,导致很多公司投入专门团队研发可视化方向。。。所以前景是一片希望,光明。) 但是从实际出发更多的人研发是通过现成的可视化库去实现自己的需求,这边举几个例子:

  1. D3.js
  2. echarts.js
  3. three.js
  4. Chart.js
  5. cytoscape.js
  6. sigma.js
  7. AntV(G2 G6等)
  8. Go.js
  9. …其他

首先说明本人这边所举框架都是各有优势,例举无排名先后哈,有幸这些技术本人或多或少都有相关技术调研及使用。还是要从业务需求业务场景来考虑到底使用哪一种可视化库。比如D3.js有丰富的动画,交互式图表(事件),图算法;echarts.js 丰富的图表类型,绚丽的特效,支持多渲染引擎等等。

最后说一下本人的一点看法,市面上的可视化库架构设计出发角度更多是抽象化的功能,满足大众化的需求。个人认为好的可视化一定要有”灵魂”,它应该通过可视化完备交互,探索式分析的方式以及背后强大的算力能帮助用户更快更准提取有效价值;如何更好体现业务价值,从交互 算法底层是需要深入研究,自研往往是必经之路。(P:自研此处指并非完全从零实现一个可视化库,可以在现有库基础进行拓展加入业务定制化,比如业务型算法)

如何深入可视化

先来了解一下可视化基础技术架构,基础包含需要:
  1. 渲染层负责可视化图形图像生成相关 API 研发,比如:绘制圆,三角形等
  2. 算法层负责可视化图形图像生成相关算法,比如:布局算法 绘制元素坐标计算如何分布等
  3. 数据层负责数据相关操作,比如:数据增删改查以及数据与视图进行一致性保证等
  4. 其他层例如通信层 工具层等
其次大家都知道很多框架渲染引擎内部是canvas / svg / webgl 实现的,内部到底如何实现? 那么接下来对于渲染层拿canvas举例进行探讨:

图图1.png

比方说实现上方这个可视化图表效果,从canvas绘制层来说,需要提供俩个绘制 API :

  1. 绘制圆形元素
  2. 绘制连线元素
在开始绘制之前

图图2.png

绘制圆形

图图3.png

绘制曲线

图图4.png

以上就是所需要提供的绘制层 API ,后续需要结合算法层比如通过 layout (布局算法)计算节点分布坐标计算、通过节点出入度和业务规则计算节点大小等进行绘制渲染,就可以实现上面美观的可视化。

最后

是不是很有意思呢?
如果想了解学习更多可以看我最新录制的课程

课程链接:https://ke.sifou.com/course/1...

image

课程大纲介绍:

为什么要学这门课?
  • 前端新机遇:大数据可视化
  • 前端开发中的图形学
基础篇:像素级操作大师 Canvas
  • 重新认识Canvas
  • Canvas的优势及特性详解
  • Canvas形状绘制:文本&样式&图片
  • Canvas动效设计与实现
  • Canvas用户交互设计与实现
进阶篇:从零研发关系可视化组件
  • 可视化组件架构设计
  • 编写关系类绘制组件
  • 编写关系类算法(FR)
实战篇:热门可视化库实战
  • d3 入门
  • d3 实战:tree 层级图
  • d3 实战:bar 图表
  • echarts 入门
  • echarts 实战:sankey 图
实战篇:研发关系可视化分析平台
  • 架构设计说明
  • 数据采集清洗
  • 消息机制学习
  • 事件交互学习
  • 项目代码实现
查看原文

赞 12 收藏 8 评论 1

认证与成就

  • 获得 2 次点赞
  • 获得 0 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 0 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2020-02-26
个人主页被 318 人浏览