分类 软件开发 下的文章

学习使用 R 的 twitteR 和 leaflet 包, 你就可以把任何话题的推文定位画在地图上。

 title=

当我开始学习 R ,我也需要学习如何出于研究的目的地收集推特数据并对其进行映射。尽管网上关于这个话题的信息很多,但我发觉难以理解什么与收集并映射推特数据相关。我不仅是个 R 新手,而且对各种教程中技术名词不熟悉。但尽管困难重重,我成功了!在这个教程里,我将以一种新手程序员都能看懂的方式来攻略如何收集推特数据并将至展现在地图中。

创建应用程序

如果你没有推特帐号,首先你需要 注册一个。然后,到 apps.twitter.com 创建一个允许你收集推特数据的应用程序。别担心,创建应用程序极其简单。你创建的应用程序会与推特应用程序接口(API)相连。 想象 API 是一个多功能电子个人助手。你可以使用 API 让其它程序帮你做事。这样一来,你可以接入推特 API 令其收集数据。只需确保不要请求太多,因为推特数据请求次数是有限制 的。

收集推文有两个可用的 API 。你若想做一次性的推文收集,那么使用 REST API. 若是想在特定时间内持续收集,可以用 streaming API。教程中我主要使用 REST API。

创建应用程序之后,前往 Keys and Access Tokens 标签。你需要 Consumer Key (API key)、 Consumer Secret (API secret)、 Access Token 和 Access Token Secret 才能在 R 中访问你的应用程序。

收集推特数据

下一步是打开 R 准备写代码。对于初学者,我推荐使用 RStudio,这是 R 的集成开发环境 (IDE) 。我发现 RStudio 在解决问题和测试代码时很实用。 R 有访问该 REST API 的包叫 twitteR

打开 RStudio 并新建 RScript。做好这些之后,你需要安装和加载 twitteR 包:

install.packages("twitteR") 
#安装 TwitteR
library (twitteR) 
#载入 TwitteR

安装并载入 twitteR 包之后,你得输入上文提及的应用程序的 API 信息:

api_key <- "" 
 #在引号内放入你的 API key 
api_secret <- "" 
 #在引号内放入你的 API secret token 
token <- "" 
 #在引号内放入你的 token
token_secret <- "" 
 #在引号内放入你的 token secret

接下来,连接推特访问 API:

setup_twitter_oauth(api_key, api_secret, token, token_secret)

我们来试试让推特搜索有关社区花园和农夫市场:

tweets <- searchTwitter("community garden OR #communitygarden OR farmers market OR #farmersmarket", n = 200, lang = "en")

这个代码意思是搜索前 200 篇 (n = 200) 英文 (lang = "en") 的推文, 包括关键词 community gardenfarmers market 或任何提及这些关键词的话题标签。

推特搜索完成之后,在数据框中保存你的结果:

tweets.df <-twListToDF(tweets)

为了用推文创建地图,你需要收集的导出为 .csv 文件:

write.csv(tweets.df, "C:\Users\YourName\Documents\ApptoMap\tweets.csv") 
 #an example of a file extension of the folder in which you want to save the .csv file.

运行前确保 R 代码已保存然后继续进行下一步。.

生成地图

现在你有了可以展示在地图上的数据。在此教程中,我们将用一个 R 包 Leaflet 做一个基本的应用程序,这是一个生成交互式地图的热门 JavaScript 库。 Leaflet 使用 magrittr 管道运算符 (%>%), 因为其语法自然,易于写代码。刚接触可能有点奇怪,但它确实降低了写代码的工作量。

为了清晰起见,在 RStudio 打开一个新的 R 脚本安装这些包:

install.packages("leaflet")
install.packages("maps") 
library(leaflet)
library(maps)

现在需要一个路径让 Leaflet 访问你的数据:

read.csv("C:\Users\YourName\Documents\ApptoMap\tweets.csv", stringsAsFactors = FALSE)

stringAsFactors = FALSE 意思是保留信息,不将它转化成 factors。 (想了解 factors,读这篇文章"stringsAsFactors: An unauthorized biography", 作者 Roger Peng)

是时候制作你的 Leaflet 地图了。我们将使用 OpenStreetMap基本地图来做你的地图:

m <- leaflet(mymap) %>% addTiles()

我们在基本地图上加个圈。对于 lnglat,输入包含推文的经纬度的列名,并在前面加个~~longitude~latitude 指向你的 .csv 文件中与列名:

m %>% addCircles(lng = ~longitude, lat = ~latitude, popup = mymap$type, weight = 8, radius = 40, color = "#fb3004", stroke = TRUE, fillOpacity = 0.8)

运行你的代码。会弹出网页浏览器并展示你的地图。这是我前面收集的推文的地图:

 title=

带定位的推文地图,使用了 Leaflet 和 OpenStreetMap CC-BY-SA

虽然你可能会对地图上的图文数量如此之小感到惊奇,通常只有 1% 的推文记录了地理编码。我收集了总数为 366 的推文,但只有 10(大概总推文的 3%)是记录了地理编码的。如果你为得到记录了地理编码的推文而困扰,改变搜索关键词看看能不能得到更好的结果。

总结

对于初学者,把以上所有碎片结合起来,从推特数据生成一个 Leaflet 地图可能很艰难。 这个教程基于我完成这个任务的经验,我希望它能让你的学习过程变得更轻松。

(题图:琼斯·贝克. CC BY-SA 4.0. 来源: Cloud, Globe. Both CC0.)


作者简介:

Dorris Scott - Dorris Scott 是佐治亚大学的地理学博士生。她的研究重心是地理信息系统(GIS)、 地理数据科学、可视化和公共卫生。她的论文是在一个 GIS 系统接口将退伍军人福利医院的传统和非传统数据结合起来,帮助病人为他们的健康状况作出更为明朗的决定。


via: https://opensource.com/article/17/6/collecting-and-mapping-twitter-data-using-r

作者:Dorris Scott 译者:XYenChi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

这些错误会造成很麻烦的问题,需要数小时才能解决。

当你做错事时,承认错误并不是一件容易的事,但是犯错是任何学习过程中的一部分,无论是学习走路,还是学习一种新的编程语言都是这样,比如学习 Python。

为了让初学 Python 的程序员避免犯同样的错误,以下列出了我学习 Python 时犯的三种错误。这些错误要么是我长期以来经常犯的,要么是造成了需要几个小时解决的麻烦。

年轻的程序员们可要注意了,这些错误是会浪费一下午的!

1、 可变数据类型作为函数定义中的默认参数

这似乎是对的?你写了一个小函数,比如,搜索当前页面上的链接,并可选将其附加到另一个提供的列表中。

def search_for_links(page, add_to=[]):
    new_links = page.search_for_links()
    add_to.extend(new_links)
    return add_to

从表面看,这像是十分正常的 Python 代码,事实上它也是,而且是可以运行的。但是,这里有个问题。如果我们给 add_to 参数提供了一个列表,它将按照我们预期的那样工作。但是,如果我们让它使用默认值,就会出现一些神奇的事情。

试试下面的代码:

def fn(var1, var2=[]):
    var2.append(var1)
    print var2

fn(3)
fn(4)
fn(5)

可能你认为我们将看到:

[3]
[4]
[5]

但实际上,我们看到的却是:

[3]
[3, 4]
[3, 4, 5]

为什么呢?如你所见,每次都使用的是同一个列表,输出为什么会是这样?在 Python 中,当我们编写这样的函数时,这个列表被实例化为函数定义的一部分。当函数运行时,它并不是每次都被实例化。这意味着,这个函数会一直使用完全一样的列表对象,除非我们提供一个新的对象:

fn(3, [4])
[4, 3]

答案正如我们所想的那样。要想得到这种结果,正确的方法是:

def fn(var1, var2=None):
    if not var2:
        var2 = []
    var2.append(var1)

或是在第一个例子中:

def search_for_links(page, add_to=None):
    if not add_to:
        add_to = []
    new_links = page.search_for_links()
    add_to.extend(new_links)
    return add_to

这将在模块加载的时候移走实例化的内容,以便每次运行函数时都会发生列表实例化。请注意,对于不可变数据类型,比如元组字符串整型,是不需要考虑这种情况的。这意味着,像下面这样的代码是非常可行的:

def func(message="my message"):
    print message

2、 可变数据类型作为类变量

这和上面提到的最后一个错误很相像。思考以下代码:

class URLCatcher(object):
    urls = []

    def add_url(self, url):
        self.urls.append(url)

这段代码看起来非常正常。我们有一个储存 URL 的对象。当我们调用 add\_url 方法时,它会添加一个给定的 URL 到存储中。看起来非常正确吧?让我们看看实际是怎样的:

a = URLCatcher()
a.add_url('http://www.google.com')
b = URLCatcher()
b.add_url('http://www.bbc.co.hk')

b.urls:

['http://www.google.com', 'http://www.bbc.co.uk']

a.urls:

['http://www.google.com', 'http://www.bbc.co.uk']

等等,怎么回事?!我们想的不是这样啊。我们实例化了两个单独的对象 ab。把一个 URL 给了 a,另一个给了 b。这两个对象怎么会都有这两个 URL 呢?

这和第一个错例是同样的问题。创建类定义时,URL 列表将被实例化。该类所有的实例使用相同的列表。在有些时候这种情况是有用的,但大多数时候你并不想这样做。你希望每个对象有一个单独的储存。为此,我们修改代码为:

class URLCatcher(object):
    def __init__(self):
        self.urls = []

    def add_url(self, url):
        self.urls.append(url)

现在,当创建对象时,URL 列表被实例化。当我们实例化两个单独的对象时,它们将分别使用两个单独的列表。

3、 可变的分配错误

这个问题困扰了我一段时间。让我们做出一些改变,并使用另一种可变数据类型 - 字典

a = {'1': "one", '2': 'two'}

现在,假设我们想把这个字典用在别的地方,且保持它的初始数据完整。

b = a

b['3'] = 'three'

简单吧?

现在,让我们看看原来那个我们不想改变的字典 a

{'1': "one", '2': 'two', '3': 'three'}

哇等一下,我们再看看 b

{'1': "one", '2': 'two', '3': 'three'}

等等,什么?有点乱……让我们回想一下,看看其它不可变类型在这种情况下会发生什么,例如一个元组

c = (2, 3)
d = c
d = (4, 5)

现在 c(2, 3),而 d(4, 5)

这个函数结果如我们所料。那么,在之前的例子中到底发生了什么?当使用可变类型时,其行为有点像 C 语言的一个指针。在上面的代码中,我们令 b = a,我们真正表达的意思是:b 成为 a 的一个引用。它们都指向 Python 内存中的同一个对象。听起来有些熟悉?那是因为这个问题与先前的相似。其实,这篇文章应该被称为「可变引发的麻烦」。

列表也会发生同样的事吗?是的。那么我们如何解决呢?这必须非常小心。如果我们真的需要复制一个列表进行处理,我们可以这样做:

b = a[:]

这将遍历并复制列表中的每个对象的引用,并且把它放在一个新的列表中。但是要注意:如果列表中的每个对象都是可变的,我们将再次获得它们的引用,而不是完整的副本。

假设在一张纸上列清单。在原来的例子中相当于,A 某和 B 某正在看着同一张纸。如果有个人修改了这个清单,两个人都将看到相同的变化。当我们复制引用时,每个人现在有了他们自己的清单。但是,我们假设这个清单包括寻找食物的地方。如果“冰箱”是列表中的第一个,即使它被复制,两个列表中的条目也都指向同一个冰箱。所以,如果冰箱被 A 修改,吃掉了里面的大蛋糕,B 也将看到这个蛋糕的消失。这里没有简单的方法解决它。只要你记住它,并编写代码的时候,使用不会造成这个问题的方式。

字典以相同的方式工作,并且你可以通过以下方式创建一个昂贵副本:

b = a.copy()

再次说明,这只会创建一个新的字典,指向原来存在的相同的条目。因此,如果我们有两个相同的列表,并且我们修改字典 a 的一个键指向的可变对象,那么在字典 b 中也将看到这些变化。

可变数据类型的麻烦也是它们强大的地方。以上都不是实际中的问题;它们是一些要注意防止出现的问题。在第三个项目中使用昂贵复制操作作为解决方案在 99% 的时候是没有必要的。你的程序或许应该被改改,所以在第一个例子中,这些副本甚至是不需要的。

编程快乐!在评论中可以随时提问。


作者简介:

Pete Savage - Peter 是一位充满激情的开源爱好者,在过去十年里一直在推广和使用开源产品。他从 Ubuntu 社区开始,在许多不同的领域自愿参与音频制作领域的研究工作。在职业经历方面,他起初作为公司的系统管理员,大部分时间在管理和建立数据中心,之后在 Red Hat 担任 CloudForms 产品的主要测试工程师。


via: https://opensource.com/article/17/6/3-things-i-did-wrong-learning-python

作者:Pete Savage 译者:polebug 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

下文是 James Henry(@MrJamesHenry)所提交的内容。我是 ESLint 核心团队的一员,也是 TypeScript 布道师。我正在和 Todd 在 UltimateAngular 平台上合作发布 Angular 和 TypeScript 的精品课程。

本文的主旨是为了介绍我们是如何看待 TypeScript 的以及它在加强 JavaScript 开发中所起的作用。

我们也将尽可能地给出那些类型和编译方面的那些时髦词汇的准确定义。

TypeScript 强大之处远远不止这些,本篇文章无法涵盖,想要了解更多请阅读官方文档,或者学习 UltimateAngular 上的 TypeScript 课程 ,从初学者成为一位 TypeScript 高手。

背景

TypeScript 是个出乎意料强大的工具,而且它真的很容易掌握。

然而,TypeScript 可能比 JavaScript 要更为复杂一些,因为 TypeScript 可能向我们同时引入了一系列以前没有考虑过的 JavaScript 程序相关的技术概念。

每当我们谈论到类型、编译器等这些概念的时候,你会发现很快会变的不知所云起来。

这篇文章就是一篇为了解答你需要知道的许许多多不知所云的概念,来帮助你 TypeScript 快速入门的教程,可以让你轻松自如的应对这些概念。

关键知识的掌握

在 Web 浏览器中运行我们的代码这件事或许使我们对它是如何工作的产生一些误解,“它不用经过编译,是吗?”,“我敢肯定这里面是没有类型的...”

更有意思的是,上述的说法既是正确的也是不正确的,这取决于上下文环境和我们是如何定义这些概念的。

首先,我们要作的是明确这些。

JavaScript 是解释型语言还是编译型语言?

传统意义上,程序员经常将自己的程序编译之后运行出结果就认为这种语言是编译型语言。

从初学者的角度来说,编译的过程就是将我们自己编辑好的高级语言程序转换成机器实际运行的格式。

就像 Go 语言,可以使用 go build 的命令行工具编译 .go 的文件,将其编译成代码的低级形式,它可以直接执行、运行。

# We manually compile our .go file into something we can run
# using the command line tool "go build"
go build ultimate-angular.go
# ...then we execute it!
./ultimate-angular

作为一个 JavaScript 程序员(这一刻,请先忽略我们对新一代构建工具和模块加载程序的热爱),我们在日常的 JavaScript 开发中并没有编译的这一基本步骤,

我们写一些 JavaScript 代码,把它放在浏览器的 <script> 标签中,它就能运行了(或者在服务端环境运行,比如:node.js)。

好吧,因此 JavaScript 没有进行过编译,那它一定是解释型语言了,是吗?

实际上,我们能够确定的一点是,JavaScript 不是我们自己编译的,现在让我们简单的回顾一个简单的解释型语言的例子,再来谈 JavaScript 的编译问题。

解释型计算机语言的执行的过程就像人们看书一样,从上到下、一行一行的阅读。

我们所熟知的解释型语言的典型例子是 bash 脚本。我们终端中的 bash 解释器逐行读取我们的命令并且执行它。

现在我们回到 JavaScript 是解释执行还是编译执行的讨论中,我们要将逐行读取和逐行执行程序分开理解(对“解释型”的简单理解),不要混在一起。

以此代码为例:

hello();
function hello(){
    console.log("Hello")
}

这是真正意义上 JavaScript 输出 Hello 单词的程序代码,但是,在 hello() 在我们定义它之前就已经使用了这个函数,这是简单的逐行执行办不到的,因为 hello() 在第一行没有任何意义的,直到我们在第二行声明了它。

像这样在 JavaScript 是存在的,因为我们的代码实际上在执行之前就被所谓的“JavaScript 引擎”或者是“特定的编译环境”编译过,这个编译的过程取决于具体的实现(比如,使用 V8 引擎的 node.js 和 Chome 就和使用 SpiderMonkey 的 FireFox 就有所不同)。

在这里,我们不会在进一步的讲解编译型执行和解释型执行微妙之处(这里的定义已经很好了)。

请务必记住,我们编写的 JavaScript 代码已经不是我们的用户实际执行的代码了,即使是我们简单地将其放在 HTML 中的 <script> ,也是不一样的。

运行时间 VS 编译时间

现在我们已经正确理解了编译和运行是两个不同的阶段,那“ 运行阶段 Run Time ”和“ 编译阶段 Compile Time ”理解起来也就容易多了。

编译阶段,就是我们在我们的编辑器或者 IDE 当中的代码转换成其它格式的代码的阶段。

运行阶段,就是我们程序实际执行的阶段,例如:上面的 hello() 函数就执行在“运行阶段”。

TypeScript 编译器

现在我们了解了程序的生命周期中的关键阶段,接下来我们可以介绍 TypeScript 编译器了。

TypeScript 编译器是帮助我们编写代码的关键。比如,我们不需将 JavaScript 代码包含到 <script> 标签当中,只需要通过 TypeScript 编译器传递它,就可以在运行程序之前得到改进程序的建议。

我们可以将这个新的步骤作为我们自己的个人“编译阶段”,这将在我们的程序抵达 JavaScript 主引擎之前,确保我们的程序是以我们预期的方式编写的。

它与上面 Go 语言的实例类似,但是 TypeScript 编译器只是基于我们编写程序的方式提供提示信息,并不会将其转换成低级的可执行文件,它只会生成纯 JavaScript 代码。

# One option for passing our source .ts file through the TypeScript
# compiler is to use the command line tool "tsc"
tsc ultimate-angular.ts

# ...this will produce a .js file of the same name
# i.e. ultimate-angular.js

官方文档中,有许多关于将 TypeScript 编译器以各种方式融入到你的现有工作流程中的文章。这些已经超出本文范围。

动态类型与静态类型

就像对比编译程序与解释程序一样,动态类型与静态类型的对比在现有的资料中也是极其模棱两可的。

让我们先回顾一下我们在 JavaScript 中对于类型的理解。

我们的代码如下:

var name = 'James';
var sum = 1 + 2;

我们如何给别人描述这段代码?

“我们声明了一个变量 name,它被分配了一个 “James” 的字符串,然后我们又申请了一个变量 sum,它被分配了一个数字 1 和数字 2 的求和的数值结果。”

即使在这样一个简单的程序中,我们也使用了两个 JavaScript 的基本类型:StringNumber

就像上面我们讲编译一样,我们不会陷入编程语言类型的学术细节当中,关键是要理解在 JavaScript 中类型表示的是什么,并扩展到 TypeScript 的类型的理解上。

从每夜拜读的最新 ECMAScript 规范中我们可以学到(LOL, JK - “wat’s an ECMA?”),它大量引用了 JavaScript 的类型及其用法。

直接引自官方规范:

ECMAScript 语言的类型取决于使用 ECMAScript 语言的 ECMAScript 程序员所直接操作的值。

ECMAScript 语言的类型有 Undefined、Null、Boolean、String、Symbol、Number 和 Object。

我们可以看到,JavaScript 语言有 7 种正式类型,其中我们在我们现在程序中使用了 6 种(Symbol 首次在 ES2015 中引入,也就是 ES6)。

现在我们来深入一点看上面的 JavaScript 代码中的 “name 和 sum”。

我们可以把我们当前被分配了字符串“James”的变量 name 重新赋值为我们的第二个变量 sum 的当前值,目前是数字 3。

var name = 'James';
var sum = 1 + 2;

name = sum;

name 变量开始“存有”一个字符串,但现在它“存有”一个数字。这凸显了 JavaScript 中变量和类型的基本特性:

“James” 值一直是字符串类型,而 name 变量可以分配任何类型的值。和 sum 赋值的情况相同,1 是一个数字类型,sum 变量可以分配任何可能的值。

在 JavaScript 中,值是具有类型的,而变量是可以随时保存任何类型的值。

这也恰好是一个“动态类型语言”的定义。

相比之下,我们可以将“静态类型语言”视为我们可以(也必须)将类型信息与特定变量相关联的语言:

var name: string = ‘James’;

在这段代码中,我们能够更好地显式声明我们对变量 name 的意图,我们希望它总是用作一个字符串。

你猜怎么着?我们刚刚看到我们的第一个 TypeScript 程序。

当我们 反思reflect我们自己的代码(非编程方面的双关语“反射”)时,我们可以得出的结论,即使我们使用动态语言(如 JavaScript),在几乎所有的情况下,当我们初次定义变量和函数参数时,我们应该有非常明确的使用意图。如果这些变量和参数被重新赋值为与我们原先赋值不同类型的值,那么有可能某些东西并不是我们预期的那样工作的。

作为 JavaScript 开发者,TypeScript 的静态类型注释给我们的一个巨大的帮助,它能够清楚地表达我们对变量的意图。

这种改进不仅有益于 TypeScript 编译器,还可以让我们的同事和将来的自己明白我们的代码。代码是用来读的。

TypeScript 在我们的 JavaScript 工作流程中的作用

我们已经开始看到“为什么经常说 TypeScript 只是 JavaScript + 静态类型”的说法了。: string 对于我们的 name 变量就是我们所谓的“类型注释”,在编译时被使用(换句话说,当我们让代码通过 TypeScript 编译器时),以确保其余的代码符合我们原来的意图。

我们再来看看我们的程序,并添加显式注释,这次是我们的 sum 变量:

var name: string = 'James';
var sum: number = 1 + 2;

name = sum;

如果我们使用 TypeScript 编译器编译这个代码,我们现在就会收到一个在 name = sum 这行的错误: Type 'number' is not assignable to type 'string',我们的这种“偷渡”被警告,我们执行的代码可能有问题。

重要的是,如果我们想要继续执行,我们可以选择忽略 TypeScript 编译器的错误,因为它只是在将 JavaScript 代码发送给我们的用户之前给我们反馈的工具。

TypeScript 编译器为我们输出的最终 JavaScript 代码将与上述原始源代码完全相同:

var name = 'James';
var sum = 1 + 2;

name = sum;

类型注释全部为我们自动删除了,现在我们可以运行我们的代码了。

注意:在此示例中,即使我们没有提供显式类型注释的 : string: number ,TypeScript 编译器也可以为我们提供完全相同的错误 。

TypeScript 通常能够从我们使用它的方式推断变量的类型!

我们的源文件是我们的文档,TypeScript 是我们的拼写检查

对于 TypeScript 与我们的源代码的关系来说,一个很好的类比,就是拼写检查与我们在 Microsoft Word 中写的文档的关系。

这两个例子有三个关键的共同点:

  1. 它能告诉我们写的东西的客观的、直接的错误:

    • 拼写检查:“我们已经写了字典中不存在的字”
    • TypeScript:“我们引用了一个符号(例如一个变量),它没有在我们的程序中声明”
  2. 它可以提醒我们写的可能是错误的:

    • 拼写检查:“该工具无法完全推断特定语句的含义,并建议重写”
    • TypeScript:“该工具不能完全推断特定变量的类型,并警告不要这样使用它”
  3. 我们的来源可以用于其原始目的,无论工具是否存在错误:

    • 拼写检查:“即使您的文档有很多拼写错误,您仍然可以打印出来,并把它当成文档使用”
    • TypeScript:“即使您的源代码具有 TypeScript 错误,它仍然会生成您可以执行的 JavaScript 代码”

TypeScript 是一种可以启用其它工具的工具

TypeScript 编译器由几个不同的部分或阶段组成。我们将通过查看这些部分之一 The Parser(语法分析程序)来结束这篇文章,除了 TypeScript 已经为我们做的以外,它为我们提供了在其上构建其它开发工具的机会。

编译过程的“解析器步骤”的结果是所谓的抽象语法树,简称为 AST。

什么是抽象语法树(AST)?

我们以普通文本形式编写我们的程序,因为这是我们人类与计算机交互的最好方式,让它们能够做我们想要的东西。我们并不是很擅长于手工编写复杂的数据结构!

然而,不管在哪种情况下,普通文本在编译器里面实际上是一个非常棘手的事情。它可能包含程序运作不必要的东西,例如空格,或者可能存在有歧义的部分。

因此,我们希望将我们的程序转换成数据结构,将数据结构全部映射为我们所使用的所谓“标记”,并将其插入到我们的程序中。

这个数据结构正是 AST!

AST 可以通过多种不同的方式表示,我使用 JSON 来看一看。

我们从这个极其简单的基本源代码来看:

var a = 1;

TypeScript 编译器的 Parser(语法分析程序)阶段的(简化后的)输出将是以下 AST:

{
  "pos": 0,
  "end": 10,
  "kind": 256,
  "text": "var a = 1;",
  "statements": [
    {
      "pos": 0,
      "end": 10,
      "kind": 200,
      "declarationList": {
        "pos": 0,
        "end": 9,
        "kind": 219,
        "declarations": [
          {
            "pos": 3,
            "end": 9,
            "kind": 218,
            "name": {
              "pos": 3,
              "end": 5,
              "text": "a"
            },
            "initializer": {
              "pos": 7,
              "end": 9,
              "kind": 8,
              "text": "1"
            }
          }
        ]
      }
    }
  ]
}

我们的 AST 中的对象称为节点。

示例:在 VS Code 中重命名符号

在内部,TypeScript 编译器将使用 Parser 生成的 AST 来提供一些非常重要的事情,例如,发生在编译程序时的类型检查。

但它不止于此!

我们可以使用 AST 在 TypeScript 之上开发自己的工具,如代码美化工具、代码格式化工具和分析工具。

建立在这个 AST 代码之上的工具的一个很好的例子是: 语言服务器 Language Server

深入了解语言服务器的工作原理超出了本文的范围,但是当我们编写程序时,它能为我们提供一个绝对重量级别功能,就是“重命名符号”。

假设我们有以下源代码:

// The name of the author is James
var first_name = 'James';
console.log(first_name);

经过代码审查和对完美的适当追求,我们决定应该改换我们的变量命名惯例;使用驼峰式命名方式,而不是我们当前正在使用这种蛇式命名。

在我们的代码编辑器中,我们一直以来可以选择多个相同的文本,并使用多个光标来一次更改它们。

Manually select matches

当我们把程序也视作文本这样继续操作时,我们已经陷入了一个典型的陷阱中。

那个注释中我们不想修改的“name”单词,在我们的手动匹配中却被误选中了。我们可以看到在现实世界的应用程序中这样更改代码是有多危险。

正如我们在上面学到的那样,像 TypeScript 这样的东西在幕后生成一个 AST 的时候,与我们的程序不再像普通文本那样可以交互,每个标记在 AST 中都有自己的位置,而且它有很清晰的映射关系。

当我们右键单击我们的 first_name 变量时,我们可以在 VS Code 中直接“重命名符号”(TypeScript 语言服务器插件也可用于其他编辑器)。

Rename Symbol Example

非常好!现在我们的 first_name 变量是唯一需要改变的东西,如果需要的话,这个改变甚至会发生在我们项目中的多个文件中(与导出和导入的值一样)!

总结

哦,我们在这篇文章中已经讲了很多的内容。

我们把有关学术方面的规避开,围绕编译器和类型还有很多专业术语给出了通俗的定义。

我们对比了编译语言与解释语言、运行阶段与编译阶段、动态类型与静态类型,以及抽象语法树(AST)如何为我们的程序构建工具提供了更为优化的方法。

重要的是,我们提供了 TypeScript 作为我们 JavaScript 开发工具的一种思路,以及如何在其上构建更棒的工具,比如说作为重构代码的一种方式的重命名符号。

快来 UltimateAngular 平台上学习从初学者到 TypeScript 高手的课程吧,开启你的学习之旅!


via: https://toddmotto.com/typescript-the-missing-introduction

作者:James Henry 译者:MonkeyDEcho 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

在恒久的迷惑与过多期待的海洋中,登上一组简单响应式设计原则的小岛。

下载 Konrad Malawski 的免费电子书《为什么选择响应式?企业应用中的基本原则》,深入了解更多响应式技术的知识与好处。

自从 2013 年一起合作写了《响应式宣言》之后,我们看着响应式从一种几乎无人知晓的软件构建技术——当时只有少数几个公司的边缘项目使用了这一技术——最后成为 中间件领域 middleware field 大佬们全平台战略中的一部分。本文旨在定义和澄清响应式各个方面的概念,方法是比较在响应式编程风格下和把响应式系统视作一个紧密整体的设计方法下编写代码的不同之处。

响应式是一组设计原则

响应式技术目前成功的标志之一是“ 响应式 reactive ”成为了一个热词,并且跟一些不同的事物与人联系在了一起——常常伴随着像“ streaming ”、“ 轻量级 lightweight ”和“ 实时 real-time ”这样的词。

举个例子:当我们看到一支运动队时(像棒球队或者篮球队),我们一般会把他们看成一个个单独个体的组合,但是当他们之间碰撞不出火花,无法像一个团队一样高效地协作时,他们就会输给一个“更差劲”的队伍。从这篇文章的角度来看,响应式是一组设计原则,一种关于系统架构与设计的思考方式,一种关于在一个分布式环境下,当 实现技术 implementation techniques 、工具和设计模式都只是一个更大系统的一部分时如何设计的思考方式。

这个例子展示了不经考虑地将一堆软件拼揍在一起——尽管单独来看,这些软件都很优秀——和响应式系统之间的不同。在一个响应式系统中,正是不同 组件 parts 间的相互作用让响应式系统如此不同,它使得不同组件能够独立地运作,同时又一致协作从而达到最终想要的结果。

一个响应式系统 是一种 架构风格 architectural style ,它允许许多独立的应用结合在一起成为一个单元,共同响应它们所处的环境,同时保留着对单元内其它应用的“感知”——这能够表现为它能够做到 放大/缩小规模 scale up/down ,负载平衡,甚至能够主动地执行这些步骤。

以响应式的风格(或者说,通过响应式编程)写一个软件是可能的;然而,那也不过是拼图中的一块罢了。虽然在上面的提到的各个方面似乎都足以称其为“响应式的”,但仅就其它们自身而言,还不足以让一个系统成为响应式的。

当人们在软件开发与设计的语境下谈论“响应式”时,他们的意思通常是以下三者之一:

  • 响应式系统(架构与设计)
  • 响应式编程(基于声明的事件的)
  • 函数响应式编程(FRP)

我们将调查这些做法与技术的意思,特别是前两个。更明确地说,我们会在使用它们的时候讨论它们,例如它们是怎么联系在一起的,从它们身上又能到什么样的好处——特别是在为多核、云或移动架构搭建系统的情境下。

让我们先来说一说函数响应式编程吧,以及我们在本文后面不再讨论它的原因。

函数响应式编程(FRP)

函数响应式编程 Functional reactive programming ,通常被称作 FRP,是最常被误解的。FRP 在二十年前就被 Conal Elliott 精确地定义过了了。但是最近这个术语却被错误地 脚注1 用来描述一些像 Elm、Bacon.js 的技术以及其它技术中的响应式插件(RxJava、Rx.NET、 RxJS)。许多的 libraries 声称他们支持 FRP,事实上他们说的并非响应式编程,因此我们不会再进一步讨论它们。

响应式编程

响应式编程 Reactive programming ,不要把它跟函数响应式编程混淆了,它是异步编程下的一个子集,也是一种范式,在这种范式下,由新信息的 有效性 availability 推动逻辑的前进,而不是让 一条执行线程 a thread-of-execution 去推动 控制流 control flow

它能够把问题分解为多个独立的步骤,这些独立的步骤可以以异步且 非阻塞 non-blocking 的方式被执行,最后再组合在一起产生一条 工作流 workflow ——它的输入和输出可能是 非绑定的 unbounded

“异步地” Asynchronous 被牛津词典定义为“不在同一时刻存在或发生”,在我们的语境下,它意味着一条消息或者一个事件可发生在任何时刻,也有可能是在未来。这在响应式编程中是非常重要的一项技术,因为响应式编程允许[ 非阻塞式 non-blocking ]的执行方式——执行线程在竞争一块共享资源时不会因为 阻塞 blocking 而陷入等待(为了防止执行线程在当前的工作完成之前执行任何其它操作),而是在共享资源被占用的期间转而去做其它工作。 阿姆达尔定律 Amdahl's Law 脚注2 告诉我们,竞争是 可伸缩性 scalability 最大的敌人,所以一个响应式系统应当在极少数的情况下才不得不做阻塞工作。

响应式编程一般是 事件驱动 event-driven ,相比之下,响应式系统则是 消息驱动 message-driven 的——事件驱动与消息驱动之间的差别会在文章后面阐明。

响应式编程库的应用程序接口(API)一般是以下二者之一:

  • 基于回调的 Callback-based —匿名的 间接作用 side-effecting 回调函数被绑定在 事件源 event sources 上,当事件被放入 数据流 dataflow chain 中时,回调函数被调用。
  • 声明式的 Declarative ——通过函数的组合,通常是使用一些固定的函数,像 mapfilterfold 等等。

大部分的库会混合这两种风格,一般还带有 基于流 stream-based 操作符 operators ,像 windowing、 counts、 triggers。

说响应式编程跟 数据流编程 dataflow programming 有关是很合理的,因为它强调的是数据流而不是控制流

举几个为这种编程技术提供支持的的编程抽象概念:

  • Futures/Promises——一个值的容器,具有 读共享/写独占 many-read/single-write 的语义,即使变量尚不可用也能够添加异步的值转换操作。
  • streams - 响应式流——无限制的数据处理流,支持异步,非阻塞式,支持多个源与目的的 反压转换管道 back-pressured transformation pipelines
  • 数据流变量#Dataflow_variables_and_declarative_concurrency)——依赖于输入、 过程 procedures 或者其它单元的 单赋值变量 single assignment variables (存储单元),它能够自动更新值的改变。其中一个应用例子是表格软件——一个单元的值的改变会像涟漪一样荡开,影响到所有依赖于它的函数,顺流而下地使它们产生新的值。

在 JVM 中,支持响应式编程的流行库有 Akka Streams、Ratpack、Reactor、RxJava 和 Vert.x 等等。这些库实现了响应式编程的规范,成为 JVM 上响应式编程库之间的 互通标准 standard for interoperability ,并且根据它自身的叙述是“……一个为如何处理非阻塞式反压异步流提供标准的倡议”。

响应式编程的基本好处是:提高多核和多 CPU 硬件的计算资源利用率;根据阿姆达尔定律以及引申的 Günther 的通用可伸缩性定律 Günther’s Universal Scalability Law 脚注3 ,通过减少 序列化点 serialization points 来提高性能。

另一个好处是开发者生产效率,传统的编程范式都尽力想提供一个简单直接的可持续的方法来处理异步非阻塞式计算和 I/O。在响应式编程中,因活动(active)组件之间通常不需要明确的协作,从而也就解决了其中大部分的挑战。

响应式编程真正的发光点在于组件的创建跟工作流的组合。为了在异步执行上取得最大的优势,把 反压 back-pressure 加进来是很重要,这样能避免过度使用,或者确切地说,避免无限度的消耗资源。

尽管如此,响应式编程在搭建现代软件上仍然非常有用,为了在更高层次上 理解 reason about 一个系统,那么必须要使用到另一个工具: 响应式架构 reactive architecture ——设计响应式系统的方法。此外,要记住编程范式有很多,而响应式编程仅仅只是其中一个,所以如同其它工具一样,响应式编程并不是万金油,它不意图适用于任何情况。

事件驱动 vs. 消息驱动

如上面提到的,响应式编程——专注于短时间的数据流链条上的计算——因此倾向于事件驱动,而响应式系统——关注于通过分布式系统的通信和协作所得到的弹性和韧性——则是消息驱动的 脚注4(或者称之为 消息式 messaging 的)。

一个拥有 长期存活的可寻址 long-lived addressable 组件的消息驱动系统跟一个事件驱动的数据流驱动模型的不同在于,消息具有固定的导向,而事件则没有。消息会有明确的(一个)去向,而事件则只是一段等着被 观察 observe 的信息。另外, 消息式 messaging 更适用于异步,因为消息的发送与接收和发送者和接收者是分离的。

响应式宣言中的术语表定义了两者之间概念上的不同

一条消息就是一则被送往一个明确目的地的数据。一个事件则是达到某个给定状态的组件发出的一个信号。在一个消息驱动系统中,可寻址到的接收者等待消息的到来然后响应它,否则保持休眠状态。在一个事件驱动系统中,通知的监听者被绑定到消息源上,这样当消息被发出时它就会被调用。这意味着一个事件驱动系统专注于可寻址的事件源而消息驱动系统专注于可寻址的接收者。

分布式系统需要通过消息在网络上传输进行交流,以实现其沟通基础,与之相反,事件的发出则是本地的。在底层通过发送包裹着事件的消息来搭建跨网络的事件驱动系统的做法很常见。这样能够维持在分布式环境下事件驱动编程模型的相对简易性,并且在某些特殊的和合理的范围内的使用案例上工作得很好。

然而,这是有利有弊的:在编程模型的抽象性和简易性上得一分,在控制上就减一分。消息强迫我们去拥抱分布式系统的真实性和一致性——像 局部错误 partial failures 错误侦测 failure detection 丢弃/复制/重排序 dropped/duplicated/reordered 消息,最后还有一致性,管理多个并发真实性等等——然后直面它们,去处理它们,而不是像过去无数次一样,藏在一个蹩脚的抽象面罩后——假装网络并不存在(例如EJB、 RPCCORBAXA)。

这些在语义学和适用性上的不同在应用设计中有着深刻的含义,包括分布式系统的 复杂性 complexity 中的 弹性 resilience 韧性 elasticity 移动性 mobility 位置透明性 location transparency 管理 management ,这些在文章后面再进行介绍。

在一个响应式系统中,特别是使用了响应式编程技术的,这样的系统中就即有事件也有消息——一个是用于沟通的强大工具(消息),而另一个则呈现现实(事件)。

响应式系统和架构

响应式系统 —— 如同在《响应式宣言》中定义的那样——是一组用于搭建现代系统——已充分准备好满足如今应用程序所面对的不断增长的需求的现代系统——的架构设计原则。

响应式系统的原则决对不是什么新东西,它可以被追溯到 70 和 80 年代 Jim Gray 和 Pat Helland 在 串级系统 Tandem System 上和 Joe aomstrong 和 Robert Virding 在 Erland 上做出的重大工作。然而,这些人在当时都超越了时代,只有到了最近 5 - 10 年,技术行业才被不得不反思当前企业系统最好的开发实践活动并且学习如何将来之不易的响应式原则应用到今天这个多核、云计算和物联网的世界中。

响应式系统的基石是 消息传递 message-passing ,消息传递为两个组件之间创建一条暂时的边界,使得它们能够在 时间 上分离——实现并发性——和 空间 space ——实现 分布式 distribution 移动性 mobility 。这种分离是两个组件完全 隔离 isolation 以及实现 弹性 resilience 韧性 elasticity 基础的必需条件。

从程序到系统

这个世界的连通性正在变得越来越高。我们不再构建 程序 ——为单个操作子来计算某些东西的端到端逻辑——而更多地在构建 系统 了。

系统从定义上来说是复杂的——每一部分都包含多个组件,每个组件的自身或其子组件也可以是一个系统——这意味着软件要正常工作已经越来越依赖于其它软件。

我们今天构建的系统会在多个计算机上操作,小型的或大型的,或少或多,相近的或远隔半个地球的。同时,由于人们的生活正变得越来越依赖于系统顺畅运行的有效性,用户的期望也变得越得越来越难以满足。

为了实现用户——和企业——能够依赖的系统,这些系统必须是 灵敏的 responsive ,这样无论是某个东西提供了一个正确的响应,还是当需要一个响应时响应无法使用,都不会有影响。为了达到这一点,我们必须保证在错误( 弹性 )和欠载( 韧性 )下,系统仍然能够保持灵敏性。为了实现这一点,我们把系统设计为 消息驱动的 ,我们称其为 响应式系统

响应式系统的弹性

弹性是与 错误下 灵敏性 responsiveness 有关的,它是系统内在的功能特性,是需要被设计的东西,而不是能够被动的加入系统中的东西。弹性是大于容错性的——弹性无关于 故障退化 graceful degradation ——虽然故障退化对于系统来说是很有用的一种特性——与弹性相关的是与从错误中完全恢复达到 自愈 的能力。这就需要组件的隔离以及组件对错误的包容,以免错误散播到其相邻组件中去——否则,通常会导致灾难性的连锁故障。

因此构建一个弹性的、 自愈 self-healing 系统的关键是允许错误被:容纳、具体化为消息,发送给其他(担当 监管者 supervisors )的组件,从而在错误组件之外修复出一个安全环境。在这,消息驱动是其促成因素:远离高度耦合的、脆弱的深层嵌套的同步调用链,大家长期要么学会忍受其煎熬或直接忽略。解决的想法是将调用链中的错误管理分离,将客户端从处理服务端错误的责任中解放出来。

响应式系统的韧性

韧性 Elasticity 是关于 欠载下的 灵敏性 responsiveness 的——意味着一个系统的吞吐量在资源增加或减少时能够自动地相应 增加或减少 scales up or down (同样能够 向内或外扩展 scales in or out )以满足不同的需求。这是利用云计算承诺的特性所必需的因素:使系统利用资源更加有效,成本效益更佳,对环境友好以及实现按次付费。

系统必须能够在不重写甚至不重新设置的情况下,适应性地——即无需介入自动伸缩——响应状态及行为,沟通负载均衡, 故障转移 failover ,以及升级。实现这些的就是 位置透明性 location transparency :使用同一个方法,同样的编程抽象,同样的语义,在所有向度中 伸缩 scaling 系统的能力——从 CPU 核心到数据中心。

如同《响应式宣言》所述:

一个极大地简化问题的关键洞见在于意识到我们都在使用分布式计算。无论我们的操作系统是运行在一个单一结点上(拥有多个独立的 CPU,并通过 QPI 链接进行交流),还是在一个 节点集群 cluster of nodes (独立的机器,通过网络进行交流)上。拥抱这个事实意味着在垂直方向上多核的伸缩与在水平方面上集群的伸缩并无概念上的差异。在空间上的解耦 [...],是通过异步消息传送以及运行时实例与其引用解耦从而实现的,这就是我们所说的位置透明性。

因此,不论接收者在哪里,我们都以同样的方式与它交流。唯一能够在语义上等同实现的方式是消息传送。

响应式系统的生产效率

既然大多数的系统生来即是复杂的,那么其中一个最重要的点即是保证一个系统架构在开发和维护组件时,最小程度地减低生产效率,同时将操作的 偶发复杂性 accidental complexity 降到最低。

这一点很重要,因为在一个系统的生命周期中——如果系统的设计不正确——系统的维护会变得越来越困难,理解、定位和解决问题所需要花费时间和精力会不断地上涨。

响应式系统是我们所知的最具 生产效率 的系统架构(在多核、云及移动架构的背景下):

  • 错误的隔离为组件与组件之间裹上舱壁(LCTT 译注:当船遭到损坏进水时,舱壁能够防止水从损坏的船舱流入其他船舱),防止引发连锁错误,从而限制住错误的波及范围以及严重性。
  • 监管者的层级制度提供了多个等级的防护,搭配以自我修复能力,避免了许多曾经在侦查(inverstigate)时引发的操作 代价 cost ——大量的 瞬时故障 transient failures
  • 消息传送和位置透明性允许组件被卸载下线、代替或 重新布线 rerouted 同时不影响终端用户的使用体验,并降低中断的代价、它们的相对紧迫性以及诊断和修正所需的资源。
  • 复制减少了数据丢失的风险,减轻了数据 检索 retrieval 和存储的有效性错误的影响。
  • 韧性允许在使用率波动时保存资源,允许在负载很低时,最小化操作开销,并且允许在负载增加时,最小化 运行中断 outgae 紧急投入 urgent investment 伸缩性的风险。

因此,响应式系统使 生成系统 creation systems 很好的应对错误、随时间变化的负载——同时还能保持低运营成本。

响应式编程与响应式系统的关联

响应式编程是一种管理 内部逻辑 internal logic 数据流转换 dataflow transformation 的好技术,在本地的组件中,做为一种优化代码清晰度、性能以及资源利用率的方法。响应式系统,是一组架构上的原则,旨在强调分布式信息交流并为我们提供一种处理分布式系统弹性与韧性的工具。

只使用响应式编程常遇到的一个问题,是一个事件驱动的基于回调的或声明式的程序中两个计算阶段的 高度耦合 tight coupling ,使得 弹性 难以实现,因此时它的转换链通常存活时间短,并且它的各个阶段——回调函数或 组合子 combinator ——是匿名的,也就是不可寻址的。

这意味着,它通常在内部处理成功与错误的状态而不会向外界发送相应的信号。这种寻址能力的缺失导致单个 阶段 stages 很难恢复,因为它通常并不清楚异常应该,甚至不清楚异常可以,发送到何处去。

另一个与响应式系统方法的不同之处在于单纯的响应式编程允许 时间 上的 解耦 decoupling ,但不允许 空间 上的(除非是如上面所述的,在底层通过网络传送消息来 分发 distribute 数据流)。正如叙述的,在时间上的解耦使 并发性 成为可能,但是是空间上的解耦使 分布 distribution 移动性 mobility (使得不仅仅静态拓扑可用,还包括了动态拓扑)成为可能的——而这些正是 韧性 所必需的要素。

位置透明性的缺失使得很难以韧性方式对一个基于适应性响应式编程技术的程序进行向外扩展,因为这样就需要分附加工具,例如 消息总线 message bus 数据网格 data grid 或者在顶层的 定制网络协议 bespoke network protocol 。而这点正是响应式系统的消息驱动编程的闪光的地方,因为它是一个包含了其编程模型和所有伸缩向度语义的交流抽象概念,因此降低了复杂性与认知超载。

对于基于回调的编程,常会被提及的一个问题是写这样的程序或许相对来说会比较简单,但最终会引发一些真正的后果。

例如,对于基于匿名回调的系统,当你想理解它们,维护它们或最重要的是在 生产供应中断 production outages 或错误行为发生时,你想知道到底发生了什么、发生在哪以及为什么发生,但此时它们只提供极少的内部信息。

为响应式系统设计的库与平台(例如 Akka 项目和 Erlang 平台)学到了这一点,它们依赖于那些更容易理解的长期存活的可寻址组件。当错误发生时,根据导致错误的消息可以找到唯一的组件。当可寻址的概念存在组件模型的核心中时, 监控方案 monitoring solution 就有了一个 有意义 的方式来呈现它收集的数据——利用 传播 propagated 的身份标识。

一个好的编程范式的选择,一个选择实现像可寻址能力和错误管理这些东西的范式,已经被证明在生产中是无价的,因它在设计中承认了现实并非一帆风顺,接受并拥抱错误的出现 而不是毫无希望地去尝试避免错误。

总而言之,响应式编程是一个非常有用的实现技术,可以用在响应式架构当中。但是记住这只能帮助管理一部分:异步且非阻塞执行下的数据流管理——通常只在单个结点或服务中。当有多个结点时,就需要开始认真地考虑像 数据一致性 data consistency 跨结点沟通 cross-node communication 协调 coordination 版本控制 versioning 编制 orchestration 错误管理 failure management 关注与责任 concerns and responsibilities 分离等等的东西——也即是:系统架构。

因此,要最大化响应式编程的价值,就把它作为构建响应式系统的工具来使用。构建一个响应式系统需要的不仅是在一个已存在的遗留下来的 软件栈 software stack 上抽象掉特定的操作系统资源和少量的异步 API 和 断路器 circuit breakers 。此时应该拥抱你在创建一个包含多个服务的分布式系统这一事实——这意味着所有东西都要共同合作,提供一致性与灵敏的体验,而不仅仅是如预期工作,但同时还要在发生错误和不可预料的负载下正常工作。

总结

企业和中间件供应商在目睹了应用响应式所带来的企业利润增长后,同样开始拥抱响应式。在本文中,我们把响应式系统做为企业最终目标进行描述——假设了多核、云和移动架构的背景——而响应式编程则从中担任重要工具的角色。

响应式编程在内部逻辑及数据流转换的组件层次上为开发者提高了生产率——通过性能与资源的有效利用实现。而响应式系统在构建 原生云 cloud native 和其它大型分布式系统的系统层次上为架构师及 DevOps 从业者提高了生产率——通过弹性与韧性。我们建议在响应式系统设计原则中结合响应式编程技术。

脚注

  1. 参考 Conal Elliott,FRP 的发明者,见这个演示
  2. Amdahl 定律揭示了系统理论上的加速会被一系列的子部件限制,这意味着系统在新的资源加入后会出现 收益递减 diminishing returns
  3. Neil Günter 的 通用可伸缩性定律 Universal Scalability Law 是理解并发与分布式系统的竞争与协作的重要工具,它揭示了当新资源加入到系统中时,保持一致性的开销会导致不好的结果。
  4. 消息可以是同步的(要求发送者和接受者同时存在),也可以是异步的(允许他们在时间上解耦)。其语义上的区别超出本文的讨论范围。

via: https://www.oreilly.com/ideas/reactive-programming-vs-reactive-systems

作者:Jonas BonérViktor Klang 译者:XLCYun 校对:wxy

本文由 LCTT 组织编译,Linux中国 荣誉推出

在这个三篇系列文章的第一篇文章中,我们将学习 图数据库 graph database 的基础知识,它支持了这地球上最大的一些数据池。

对于海量的各种非结构化信息来说,图数据库已经成为帮助收集、管理和搜索大量数据的技术。在这三篇系列文章中,我们将使用开源图数据库软件 Neo4j 来研究图数据库。

在本文中,我将向你展示图数据库的基础知识,帮助你快速了解概念模型。在第二篇中,我将向你展示如何启动 Neo4j 数据库,并使用内置的浏览器工具填充一些数据。而且,在本系列的最后一篇文章中,我们将探讨一些在开发工作中使用的 Neo4j 编程库。

掌握图数据库的概念模型是有用的,所以我们从那里开始。图数据库中只存储两种数据: 节点 node edge

  • 节点是实体:诸如人物、发票、电影、书籍或其他具体事物。这些有些等同于关系数据库中的记录或行。
  • 边名关系:连接节点的概念、事件或事物。在关系数据库中,这些关系通常存储在具有链接字段的数据库行中。在图数据库中,它们本身就是有用的,是可以以其自己的权限搜索的对象。

节点和边都可以拥有可搜索的属性。例如,如果你的节点代表人,他们可能拥有名字、性别、出生日期、身高等属性。而边的属性可能描述了两个人之间的关系何时建立,见面的情况或关系的性质。

这是一个帮助你可视化的图表:

 title=

在这张图中,你知道 Jane Doe 有一个新的丈夫 John;一个女儿(来自她以前的夫妻关系)Mary Smith 和朋友 Robert 和 Rhonda Roe。Roes 有一个儿子 Ryan,他正在与 Mary Smith 约会。

看看它怎么工作?每个节点代表一个独立于其他节点的人。你需要找到关于那个人的一切都可以存储在节点的属性中。边描述了人们之间的关系,这与你在程序中需要的一样多。

关系是单向的,且不能是无向的,但这没有问题。由于数据库可以以相同的速度遍历两个方向,并且方向可以忽略,你只需要定义一次此关系。如果你的程序需要定向关系,则可以自由使用它们,但如果双向性是暗含的,则不需要。

另外需要注意的是,图数据库本质上是无 schema 的。这与关系数据库不同,关系数据库每行都有一组列表,并且添加新的字段会给开发和升级带来很多工作。

每个节点都可以拥有一个 标签 label ;对于大多数程序你需要“输入”这个标签,是对典型的关系数据库中的表名的模拟。标签可以让你区分不同的节点类型。如果你需要添加新的标签或属性,修改程序来用它就行!

使用图数据库,你可以直接开始使用新的属性和标签,节点将在创建或编辑时获取它们。不需要转换东西;只需在你的代码中使用它们即可。在这里的例子中,你可以看到,我们知道 Jane 和 Mary 最喜欢的颜色和 Mary 的出生日期,但是别人没有(这些属性)。这个系统不需要知道它;用户可以在正常使用程序的过程中访问节点时为其添加信息(属性)。

作为一名开发人员,这是一个有用的特性。你可以将新的标签或属性添加到由节点处理的表单中并开始使用它,而不必进行数据库 schema 的修改。对于没有该属性的节点,将不显示任何内容。你可以使用任何一种类型的数据库来为表单进行编码,但是你可以放下在关系型数据库中要进行的许多后端工作了。

让我们添加一些新的信息:

 title=

这是一个新的节点类型,它代表一个位置,以及一些相关关系。现在我们看到 John Doe 出生在加利福尼亚州的 Petaluma,而他的妻子 Jane 则出生在德克萨斯州的 Grand Prairie。 他们现在住在得克萨斯州的赛普拉斯,因为 Jane 在附近的休斯顿工作。Ryan Roe 缺乏城市关系对数据库来说没有什么大不了的事情,我们不知道那些信息而已。当用户输入更多数据时,数据库可以轻松获取新数据并添加新数据,并根据需要创建新的节点和关系。

了解节点和边应该足以让你开始使用图形数据库。如果你像我一样,已经在考虑如何在一个图中重组你的程序。在本系列的下一篇文章中,我将向你展示如何安装 Neo4j、插入数据,并进行一些基本的搜索。


via: https://opensource.com/article/17/7/fundamentals-graph-databases-neo4j

作者:Ruth Holloway 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

到目前为止,你已经偶尔听到了关于 dwarves、调试信息、一种无需解析就可以理解源码方式。今天我们会详细介绍源码级的调试信息,作为本指南后面部分使用它的准备。

系列文章索引

随着后面文章的发布,这些链接会逐渐生效。

  1. 准备环境
  2. 断点
  3. 寄存器和内存
  4. Elves 和 dwarves
  5. 源码和信号
  6. 源码级逐步执行
  7. 源码级断点
  8. 调用栈展开
  9. 读取变量
  10. 下一步

ELF 和 DWARF 简介

ELF 和 DWARF 可能是两个你没有听说过,但可能大部分时间都在使用的组件。ELF(Executable and Linkable Format,可执行和可链接格式)是 Linux 系统中使用最广泛的目标文件格式;它指定了一种存储二进制文件的所有不同部分的方式,例如代码、静态数据、调试信息以及字符串。它还告诉加载器如何加载二进制文件并准备执行,其中包括说明二进制文件不同部分在内存中应该放置的地点,哪些位需要根据其它组件的位置固定(重分配)以及其它。在这些博文中我不会用太多篇幅介绍 ELF,但是如果你感兴趣的话,你可以查看这个很好的信息图该标准

DWARF是通常和 ELF 一起使用的调试信息格式。它不一定要绑定到 ELF,但它们两者是一起发展的,一起工作得很好。这种格式允许编译器告诉调试器最初的源代码如何和被执行的二进制文件相关联。这些信息分散到不同的 ELF 部分,每个部分都衔接有一份它自己的信息。下面不同部分的定义,信息取自这个稍有过时但非常重要的 DWARF 调试格式简介

  • .debug_abbrev .debug_info 部分使用的缩略语
  • .debug_aranges 内存地址和编译的映射
  • .debug_frame 调用帧信息
  • .debug_info 包括 DWARF 信息条目 DWARF Information Entries (DIEs)的核心 DWARF 数据
  • .debug_line 行号程序
  • .debug_loc 位置描述
  • .debug_macinfo 宏描述
  • .debug_pubnames 全局对象和函数查找表
  • .debug_pubtypes 全局类型查找表
  • .debug_ranges DIEs 的引用地址范围
  • .debug_str .debug_info 使用的字符串列表
  • .debug_types 类型描述

我们最关心的是 .debug_line.debug_info 部分,让我们来看一个简单程序的 DWARF 信息。

int main() {
    long a = 3;
    long b = 2;
    long c = a + b;
    a = 4;
}

DWARF 行表

如果你用 -g 选项编译这个程序,然后将结果传递给 dwarfdump 执行,在行号部分你应该可以看到类似这样的东西:

.debug_line: line number info for a single cu
Source lines (from CU-DIE at .debug_info offset 0x0000000b):

            NS new statement, BB new basic block, ET end of text sequence
            PE prologue end, EB epilogue begin
            IS=val ISA number, DI=val discriminator value
<pc>        [lno,col] NS BB ET PE EB IS= DI= uri: "filepath"
0x00400670  [   1, 0] NS uri: "/home/simon/play/MiniDbg/examples/variable.cpp"
0x00400676  [   2,10] NS PE
0x0040067e  [   3,10] NS
0x00400686  [   4,14] NS
0x0040068a  [   4,16]
0x0040068e  [   4,10]
0x00400692  [   5, 7] NS
0x0040069a  [   6, 1] NS
0x0040069c  [   6, 1] NS ET

前面几行是一些如何理解 dump 的信息 - 主要的行号数据从以 0x00400670 开头的行开始。实际上这是一个代码内存地址到文件中行列号的映射。NS 表示地址标记一个新语句的开始,这通常用于设置断点或逐步执行。PE 表示函数序言(LCTT 译注:在汇编语言中,function prologue 是程序开始的几行代码,用于准备函数中用到的栈和寄存器)的结束,这对于设置函数断点非常有帮助。ET 表示转换单元的结束。信息实际上并不像这样编码;真正的编码是一种非常节省空间的排序程序,可以通过执行它来建立这些行信息。

那么,假设我们想在 variable.cpp 的第 4 行设置断点,我们该怎么做呢?我们查找和该文件对应的条目,然后查找对应的行条目,查找对应的地址,在那里设置一个断点。在我们的例子中,条目是:

0x00400686  [   4,14] NS

假设我们想在地址 0x00400686 处设置断点。如果你想尝试的话你可以在已经编写好的调试器上手动实现。

反过来也是如此。如果我们已经有了一个内存地址 - 例如说,一个程序计数器值 - 想找到它在源码中的位置,我们只需要从行表信息中查找最接近的映射地址并从中抓取行号。

DWARF 调试信息

.debug_info 部分是 DWARF 的核心。它给我们关于我们程序中存在的类型、函数、变量、希望和梦想的信息。这部分的基本单元是 DWARF 信息条目(DWARF Information Entry),我们亲切地称之为 DIEs。一个 DIE 包括能告诉你正在展现什么样的源码级实体的标签,后面跟着一系列该实体的属性。这是我上面展示的简单事例程序的 .debug_info 部分:

.debug_info

COMPILE_UNIT<header overall offset = 0x00000000>:
< 0><0x0000000b>  DW_TAG_compile_unit
                    DW_AT_producer              clang version 3.9.1 (tags/RELEASE_391/final)
                    DW_AT_language              DW_LANG_C_plus_plus
                    DW_AT_name                  /super/secret/path/MiniDbg/examples/variable.cpp
                    DW_AT_stmt_list             0x00000000
                    DW_AT_comp_dir              /super/secret/path/MiniDbg/build
                    DW_AT_low_pc                0x00400670
                    DW_AT_high_pc               0x0040069c

LOCAL_SYMBOLS:
< 1><0x0000002e>    DW_TAG_subprogram
                      DW_AT_low_pc                0x00400670
                      DW_AT_high_pc               0x0040069c
                      DW_AT_frame_base            DW_OP_reg6
                      DW_AT_name                  main
                      DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                      DW_AT_decl_line             0x00000001
                      DW_AT_type                  <0x00000077>
                      DW_AT_external              yes(1)
< 2><0x0000004c>      DW_TAG_variable
                        DW_AT_location              DW_OP_fbreg -8
                        DW_AT_name                  a
                        DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                        DW_AT_decl_line             0x00000002
                        DW_AT_type                  <0x0000007e>
< 2><0x0000005a>      DW_TAG_variable
                        DW_AT_location              DW_OP_fbreg -16
                        DW_AT_name                  b
                        DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                        DW_AT_decl_line             0x00000003
                        DW_AT_type                  <0x0000007e>
< 2><0x00000068>      DW_TAG_variable
                        DW_AT_location              DW_OP_fbreg -24
                        DW_AT_name                  c
                        DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                        DW_AT_decl_line             0x00000004
                        DW_AT_type                  <0x0000007e>
< 1><0x00000077>    DW_TAG_base_type
                      DW_AT_name                  int
                      DW_AT_encoding              DW_ATE_signed
                      DW_AT_byte_size             0x00000004
< 1><0x0000007e>    DW_TAG_base_type
                      DW_AT_name                  long int
                      DW_AT_encoding              DW_ATE_signed
                      DW_AT_byte_size             0x00000008

第一个 DIE 表示一个编译单元(CU),实际上是一个包括了所有 #includes 和类似语句的源文件。下面是带含义注释的属性:

DW_AT_producer   clang version 3.9.1 (tags/RELEASE_391/final)    <-- 产生该二进制文件的编译器
DW_AT_language   DW_LANG_C_plus_plus                             <-- 原编程语言
DW_AT_name       /super/secret/path/MiniDbg/examples/variable.cpp  <-- 该 CU 表示的文件名称
DW_AT_stmt_list  0x00000000                                      <-- 跟踪该 CU 的行表偏移
DW_AT_comp_dir   /super/secret/path/MiniDbg/build                  <-- 编译目录
DW_AT_low_pc     0x00400670                                      <-- 该 CU 的代码起始
DW_AT_high_pc    0x0040069c                                      <-- 该 CU 的代码结尾

其它的 DIEs 遵循类似的模式,你也很可能推测出不同属性的含义。

现在我们可以根据新学到的 DWARF 知识尝试和解决一些实际问题。

当前我在哪个函数?

假设我们有一个程序计数器值然后想找到当前我们在哪一个函数。一个解决该问题的简单算法:

for each compile unit:
    if the pc is between DW_AT_low_pc and DW_AT_high_pc:
        for each function in the compile unit:
            if the pc is between DW_AT_low_pc and DW_AT_high_pc:
                return function information

这对于很多目的都有效,但如果有成员函数或者内联(inline),就会变得更加复杂。假如有内联,一旦我们找到其范围包括我们的程序计数器(PC)的函数,我们需要递归遍历该 DIE 的所有孩子检查有没有内联函数能更好地匹配。在我的代码中,我不会为该调试器处理内联,但如果你想要的话你可以添加该功能。

如何在一个函数上设置断点?

再次说明,这取决于你是否想要支持成员函数、命名空间以及类似的东西。对于简单的函数你只需要迭代遍历不同编译单元中的函数直到你找到一个合适的名字。如果你的编译器能够填充 .debug_pubnames 部分,你可以更高效地做到这点。

一旦找到了函数,你可以在 DW_AT_low_pc 给定的内存地址设置一个断点。不过那会在函数序言处中断,但更合适的是在用户代码处中断。由于行表信息可以指定序言的结束的内存地址,你只需要在行表中查找 DW_AT_low_pc 的值,然后一直读取直到被标记为序言结束的条目。一些编译器不会输出这些信息,因此另一种方式是在该函数第二行条目指定的地址处设置断点。

假如我们想在我们示例程序中的 main 函数设置断点。我们查找名为 main 的函数,获取到它的 DIE:

< 1><0x0000002e>    DW_TAG_subprogram
                      DW_AT_low_pc                0x00400670
                      DW_AT_high_pc               0x0040069c
                      DW_AT_frame_base            DW_OP_reg6
                      DW_AT_name                  main
                      DW_AT_decl_file             0x00000001 /super/secret/path/MiniDbg/examples/variable.cpp
                      DW_AT_decl_line             0x00000001
                      DW_AT_type                  <0x00000077>
                      DW_AT_external              yes(1)

这告诉我们函数从 0x00400670 开始。如果我们在行表中查找这个,我们可以获得条目:

0x00400670  [   1, 0] NS uri: "/super/secret/path/MiniDbg/examples/variable.cpp"

我们希望跳过序言,因此我们再读取一个条目:

0x00400676  [   2,10] NS PE

Clang 在这个条目中包括了序言结束标记,因此我们知道在这里停止,然后在地址 0x00400676 处设一个断点。

我如何读取一个变量的内容?

读取变量可能非常复杂。它们是难以捉摸的东西,可能在整个函数中移动、保存在寄存器中、被放置于内存、被优化掉、隐藏在角落里,等等。幸运的是我们的简单示例是真的很简单。如果我们想读取变量 a 的内容,我们需要看它的 DW_AT_location 属性:

DW_AT_location              DW_OP_fbreg -8

这告诉我们内容被保存在以栈帧基(base of the stack frame)偏移为 -8 的地方。为了找到栈帧基,我们查找所在函数的 DW_AT_frame_base 属性。

DW_AT_frame_base            DW_OP_reg6

System V x86\_64 ABI 我们可以知道 reg6 在 x86 中是帧指针寄存器。现在我们读取帧指针的内容,从中减去 8,就找到了我们的变量。如果我们知道它具体是什么,我们还需要看它的类型:

< 2><0x0000004c>      DW_TAG_variable
                        DW_AT_name                  a
                        DW_AT_type                  <0x0000007e>

如果我们在调试信息中查找该类型,我们得到下面的 DIE:

< 1><0x0000007e>    DW_TAG_base_type
                      DW_AT_name                  long int
                      DW_AT_encoding              DW_ATE_signed
                      DW_AT_byte_size             0x00000008

这告诉我们该类型是 8 字节(64 位)有符号整型,因此我们可以继续并把这些字节解析为 int64_t 并向用户显示。

当然,类型可能比那要复杂得多,因为它们要能够表示类似 C++ 的类型,但是这能给你它们如何工作的基本认识。

再次回到帧基(frame base),Clang 可以通过帧指针寄存器跟踪帧基。最近版本的 GCC 倾向于使用 DW_OP_call_frame_cfa,它包括解析 .eh_frame ELF 部分,那是一个我不会去写的另外一篇完全不同的文章。如果你告诉 GCC 使用 DWARF 2 而不是最近的版本,它会倾向于输出位置列表,这更便于阅读:

DW_AT_frame_base            <loclist at offset 0x00000000 with 4 entries follows>
 low-off : 0x00000000 addr  0x00400696 high-off  0x00000001 addr 0x00400697>DW_OP_breg7+8
 low-off : 0x00000001 addr  0x00400697 high-off  0x00000004 addr 0x0040069a>DW_OP_breg7+16
 low-off : 0x00000004 addr  0x0040069a high-off  0x00000031 addr 0x004006c7>DW_OP_breg6+16
 low-off : 0x00000031 addr  0x004006c7 high-off  0x00000032 addr 0x004006c8>DW_OP_breg7+8

位置列表取决于程序计数器所处的位置给出不同的位置。这个例子告诉我们如果程序计数器是在 DW_AT_low_pc 偏移量为 0x0 的位置,那么帧基就在和寄存器 7 中保存的值偏移量为 8 的位置,如果它是在 0x10x4 之间,那么帧基就在和相同位置偏移量为 16 的位置,以此类推。

休息一会

这里有很多的信息需要你的大脑消化,但好消息是在后面的几篇文章中我们会用一个库替我们完成这些艰难的工作。理解概念仍然很有帮助,尤其是当出现错误或者你想支持一些你使用的 DWARF 库所没有实现的 DWARF 概念时。

如果你想了解更多关于 DWARF 的内容,那么你可以从这里获取其标准。在写这篇博客时,刚刚发布了 DWARF 5,但更普遍支持 DWARF 4。


via: https://blog.tartanllama.xyz/c++/2017/04/05/writing-a-linux-debugger-elf-dwarf/

作者:Simon Brand 译者:ictlyh 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出