Homebrew介绍和使用

一、Homebrew是什么?


Homebrew也称brew,macOS下基于命令行的最强大软件包管理工具,使用Ruby语言开发。类似于CentOS的yum或者Ubuntu的apt-get,brew能方便的管理软件的安装、更新、卸载,省去了手动编译或拖动安装的不便,更使得软件的管理更加集中化,解决了依赖包管理的烦恼。

官网地址https://brew.sh

二、安装


Homebrew 依赖于Xcode Command Line Tools,所以需先执行:

在终端中执行:

检查是否已安装成功:

三、基本用法


基于brew安装的所有软件及其依赖均会安装到目录/usr/local/Cellar

Brew 帮助信息

子命令帮助信息 brew help [COMMAND]或brew [COMMAND] -h 用于查看具体某个子命令的帮助信息。

例如,查看install命令的帮助详情:

搜索软件 brew search [TEXT|/REGEX/] 用于搜索软件,支持使用正则表达式进行复杂的搜索。

例如,查询静态博客生成工具hugo:

查看软件信息 brew info [FORMULA…] 用于查询软件的详细信息。

例如,查看软件hugo的详细信息:

以上查询所得信息,包含了软件的最新可用版本,本机是否已安装,本机已安装的版本,安装的路径、大小、时间、Tap 源,所依赖的包,以及安装的可选项等详细信息。而这些信息可以帮助我们很方便快捷的了解如何对该软件进行相应的操作。

安装软件包 brew install FORMULA… 用于安装一个或多个软件。

例如,安装软件hugo:

安装软件命令执行之前,brew 一般会先检查更新 Homebrew 自身及 Tap 源。

更新软件包

用于更新一个或多个软件,不指定软件名则更新所有软件。

卸载软件包

用于卸载指定的一个或多个软件

彻底卸载指定软件,包括旧版本

已安装的软件列表

用于查询本机已安装的软件列表

服务管理

用于方便的管理 brew 安装的软件软件,类似于 Linux 下的 service 命令。

查看brew services帮助信息:

查询服务列表:

检查可更新的软件列表 brew outdated 可查询有更新版本的软件

清理软件

列出需要清理的内容

清理所有的过时软件

清理指定软件的过时包

查看配置信息 brew config 用于查看 brew 所在环境及相关的配置情况

诊断问题 brew doctor 诊断当前 brew 存在哪些问题,并给出解决方案
仓库管理 brew tap 已安装的仓库列表

添加仓库

移除仓库

四、常用命令有哪些?


安装软件,如:brew install oclint
卸载软件,如:brew uninstall oclint
搜索软件,如:brew search oclint
更新软件,如:brew upgrade oclint
查看安装列表, 如:brew list
更新Homebrew,如:brew update

《跨界:开启互联网与传统行业融合新趋势》随笔

本书开篇的几个定律解释:

摩尔定律:

摩尔定律是由英特尔(Intel)创始人之一戈登·摩尔(Gordon Moore)提出来的。其内容为:当价格不变时,集成电路上可容纳的元器件的数目,约每隔18-24个月便会增加一倍,性能也将提升一倍。换言之,每一美元所能买到的电脑性能,将每隔18-24个月翻一倍以上。这一定律揭示了信息技术进步的速度。
尽管这种趋势已经持续了超过半个世纪,摩尔定律仍应该被认为是观测或推测,而不是一个物理或自然法。预计定律将持续到至少2015年或2020年。然而,2010年国际半导体技术发展路线图的更新增长已经放缓在2013年年底,之后的时间里晶体管数量密度预计只会每三年翻一番。

吉尔德定律:

与摩尔定律相联系的另一个网络定律是吉尔德定律(Gilder\’s Law),即主干网带宽的增长速度至少是运算性能增长速度的三倍。因为运算性能增长速度主要是由摩尔定律决定的,所以根据每两年运算性能提高一倍计算,主干网的网络带宽的增长速度大概是每八个月增长一倍。而主干网的网络带宽的不断增长意味着各种新的网络应用方式的出现和网络用户的使用费用的不断降低。
吉尔德定律和摩尔定律之所以联系在一起,是因为带宽的增长不仅仅受路由传输介质影响,更主要的是受路由等传输设备的运算速度的提高,和作为节点的计算机的运算速度的加快的影响,而后者是由摩尔定律决定的。

梅特卡夫原则(迈特卡夫定律):

迈特卡夫定律与摩尔定律也是联系在一起的。前面提到,在某种意义上讲,摩尔定律从微观角度解释了产品的性能提高而成本降低的现象;迈特卡夫定律则从宏观角度解释了产生这种现象的社会渊源——这就是随着一个技术的使用者的不断增多,每一个使用者从使用中获得的价值不断增加,但使用费用却不断下降的现象是市场决定的。互联网使用者的不断增加,互联网应用技术的日新月异和新技术公司的不断崛起为这三定律的准确性提供了最好的诠释。
前面提到的两个定律都和硬件有关系,而作为三大定律之一的迈特卡夫定律(Metcalfe\’s Law)则为互联网的社会和经济价值提供了一个估算的模式。迈特卡夫定律是由以太网的发明人罗伯特·迈特卡夫(Robert Metcalfe)提出并以他的名字命名的。其简单描述是:网络的价值与网络使用者数量的平方成正比。这个貌似简单的陈述,却为包括互联网在内的,许多重大发明存在并被用的实际价值,提供了一个简洁的数学结论。比如,电话的发明就是遵循迈特卡夫定律的——如果全世界只有一个电话的使用者,那么电话这项发明的价值为零,可是大家都在使用电话,那么,这项技术就能够为像美国电报电话公司(AT&T)这样的巨型企业的存在提供足够的经济基础。同样的道理,互联网上众多应运而生的网络公司,如电子海湾和亚马逊的飞速发展也是因为其网络用户的不断加入而发展壮大。

六度分隔理论:

六度分隔(Six Degrees of Separation)理论。1967年,哈佛大学的心理学教授Stanley Milgram(1933-1984)想要描绘一个连结人与社区的人际连系网。做过一次连锁信实验,结果发现了“六度分隔”现象。简单地说:“你和任何一个陌生人之间所间隔的人不会超过六个,也就是说,最多通过六个人你就能够认识任何一个陌生人。”
“六度分隔”说明了社会中普遍存在的“弱纽带”,但是却发挥着非常强大的作用。有很多人在找工作时会体会到这种弱纽带的效果。 通过弱纽带人与人之间的距离变得非常“相近”。

马太效应:

马太效应(Matthew Effect),指强者愈强、弱者愈弱的现象,广泛应用于社会心理学、教育、金融以及科学领域。马太效应,是社会学家和经济学家们常用的术语,反映的社会现象是两极分化,富的更富,穷的更穷 。
马太效应,名字来自圣经《新约·马太福音》一则寓言: “凡有的,还要加倍给他叫他多余;没有的,连他所有的也要夺过来”。表面看起来“马太效应”与“平衡之道”相悖,与“二八定则”类似,但是实则它只不过是“平衡之道”的一极。
陆陆续续读完这本书,本书第一版是2015年5月,当时O2O正火,共享单车正拿着大笔融资圈地。滴滴快滴正大力补贴在争夺用户。作者对于共享单车、在线教育、旅游产业都做了分析,传统企业面对互联网冲击时候的恐惧和反应。此刻共享单车、滴滴快滴尘埃落定,以现在的认知在看此书还是有很大的启发。特别是后记:勿忘初心,初心不是what,是why。细想起来确实是很独到而且合理的理解。

轻松掌握阿里Blink SQL关键技术及实现原理

内容来源:2018 年 6 月 15 日,阿里巴巴高级技术专家孙金城(金竹)在“阿里云流计算杭州峰会”进行《Blink SQL关键技术及实现原理》演讲分享。IT 大咖说(微信id:itdakashuo)作为独家视频合作方,经主办方和讲者审阅授权发布。

获取嘉宾演讲视频及PPT:suo.im/4ZZ9PO

摘要

本次演讲主要介绍Blink SQL的几个关键技术,以及实现原理,并通过两个实例来阐述具体的功能效果。

六个特点和背景介绍

(Blink架构)

Blink作为一个纯流式的计算平台,具备秒级甚至毫秒级的延时,能够快速容错,比如在某个计算节点挂掉的时候可以快速恢复。它还支持动态扩容,针对流计算场景做了大量优化,具备高吞吐和高资源利用率的极致性能,同时解决了非常明显的数据乱序的问题,并且支持大数据量的流计算请求。

什么是BlinkSQL

BlinkSQL是在FlinkSQL基础上新增了大量的丰富功能和性能优化。SQL作为声明式的可优化的语言具备很大的优势,Blink的SQL查询优化器会对用户SQL进行优化,制定最优的执行计划以获取高性能。同时SQL易于理解,用它编写的业务逻辑清晰明了。

虽然SQL被更多的用于批处理,但是在流计算场景下同样也适用。从处理的数据集合来看,流处理的数据是无穷的,而批处理面对的是有限集合。从内部处理逻辑来看,批处理是单次作业,流处理的运作持续不断,并且会对历史数据进行修正。

上图展示的是一个携带时间戳和用户名的点击事件流,我们先对这些事件流进行流式统计,同时在最后的流事件上触发批计算。流计算中每接收一个数据都会触发一个结果,可以看到最后的事件无论是在流还是批上计算结果都是6。这说明只要SQL语句和数据源相同,流和批的计算结果就不会存在差异。相同的SQL在流和批这两种模式下,语义相同,最终结果就会一致。

五个概念和一个实现

流表对偶性

流表对偶性是指流表转换信息无损,具有对偶性。

传统数据库表有两个最明显的特征schema和data,流同样也有schema和data,另外还有一个重要属性time,随着时间的推移数据会不断涌入流中。

上图中在对一个用户名关系表进行DML操作,每insert一条语句后会触发一个统计查询,按user维度分组做count统计。图中插入第一条数据后,输入的是(mary , 1),接着再插入数据就会输出(Bob , 2)、(mary , 1),在进行操作的时候虽然没有显示的涉及到时间,但是其实都隐含了一个操作时间,从本质上讲,传统数据库表中也有time属性。

这样的话单就属性来看数据库表和流式就是一样的,我们可以把一个具体的表可以看做是流上某一时间切片的数据。

动态表

随着时间变化不断变化的表可以称之为动态表,这个概念不适用于传统数据库表。因为传统数据库有着事务控制,在执行查询的那一刻表的内容不会有变化,所以是静态表。而流上的数据即使在查询的时候也还是在变化,数据进行回放的时候,可以Replay成一张动态表,而动态表的changelog又形成了流。

持续查询 & 增量计算

持续查询是流计算特有的,不断更新结果,执行运行的查询。它是保证低延迟和数据更新的基础。

增量计算是一种可以提高流计算性能的计算实现,流上的每一条数据都会利用上一条计算结果进行聚合和统计计算。

Early Emit & Retraction

Early Emit是为了保证流计算的低延时需求,将计算结果尽早的流到下游。由于流计算的结果会随着时间改变,因此即使上游的计算结果在发出的那一刻是正确的,但是随后又会产生新的结果,这样下游当初接收的数据就是陈旧的。Retraction解决的就是这一问题,为了保障流计算语义正确性,将Early Emit的计算结果撤回并发出正确的计算结果。

双流JOIN实现

对于双流join,由于流上的流速不一定相同,有可能会出现查询的时候数据不存在,后续才出现数据的情况。上图是Blink的join方案,将左边的数据存储在一个state中,并且对右边的state做join查询。同理右边的数据处理也是一样,先存储在一个state中,然后join查询另一个state。

这样的流程存在一个问题,即在join另一边的state时可能没有数据,传统数据库的做法是将它留空,而流上的数据会实时变化,此刻没有join数据不代表下一刻还没有。这就需要利用Retraction机制,在正确数据到来的时候撤回之前的空数据并重新填入新数据,如上图所示。

总结

这里我们对这5个概念做下总结。首先有了流表对偶性,流表转换才有理论支撑,流表才能互转;有了动态表的概念,SQL才能作用于流上,才能进行持续查询;有了持续查询的概念,才能真正解释流式SQL计算永不结束,结果永远在更新;增量计算配合查询和引擎优化,才有了Blink的高性能;Early Emit和Retraction,一个使用Blink有了无限逼近秒级毫秒级的低延时,一个保证了流式语义的正确性。

两个案例和总结

案例1 – 无key热点

对于有多区块的数据源,每个区块都会由对应的节点来处理。理想情况下每个节点的处理量相同,负载是均衡的,但是实际场景下可能会出现不均衡处理的情况,比如某个节点无法处理所负载的量,对此我们要将该节点无法处理的部分分配给其他节点。

Blink为此提供了Dynamic Rebalance,它会感知下游节点的压力情况,进而将繁忙的节点处理不过来的数据分发给空闲节点。需要注意的是目前的这种情况是无key节点,这意味着数据在哪个节点处理都可以。

案例2 – keyed热点

Keyed就是对数据按key分组,相同的key必须到同一个节点上。这时候虽然框架也能感知到反压,但是不可以使用反压机制再分配节点上的数据。

这时候要用到Local-Global Aggregation,数据热点优化的另一个方案,也是由系统内部的查询优化器来完成,让用户无感知。它会先将每个节点的数据在本地进行Local Agg聚合,图中不同的颜色表示不同的key,他们在本地会做局部的聚合,这样原先上游的4条记录就变成的1条,很大程度上减轻了下游节点的压力。

总结

Blink SQL拥有标准的语义,完全支持标准的ANSI SQL,同时有丰富的功能,比如UDF、JOIN、双流JOIN等。有更优的性能,在ANSI SQL的各个语法功能基础上做了大量的性能优化。提供了一站式平台,集开发、测试、部署、监控、升级于一体,让用户专注于自己的业务。

原文链接:https://juejin.im/post/5b8609a6e51d4538d12ca085

java 泛型详解

对java的泛型特性的了解仅限于表面的浅浅一层,直到在学习设计模式时发现有不了解的用法,才想起详细的记录一下。
本文参考java 泛型详解、Java中的泛型方法、 java泛型详解

1. 概述

泛型在java中有很重要的地位,在面向对象编程及各种设计模式中有非常广泛的应用。

什么是泛型?为什么要使用泛型?

泛型,即“参数化类型”。一提到参数,最熟悉的就是定义方法时有形参,然后调用此方法时传递实参。那么参数化类型怎么理解呢?顾名思义,就是将类型由原来的具体的类型参数化,类似于方法中的变量参数,此时类型也定义成参数形式(可以称之为类型形参),然后在使用/调用时传入具体的类型(类型实参)。

泛型的本质是为了参数化类型(在不创建新的类型的情况下,通过泛型指定的不同类型来控制形参具体限制的类型)。也就是说在泛型使用过程中,操作的数据类型被指定为一个参数,这种参数类型可以用在类、接口和方法中,分别被称为泛型类、泛型接口、泛型方法。

2. 一个栗子

一个被举了无数次的例子:

毫无疑问,程序的运行结果会以崩溃结束:

java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String

ArrayList可以存放任意类型,例子中添加了一个String类型,添加了一个Integer类型,再使用时都以String的方式使用,因此程序崩溃了。为了解决类似这样的问题(在编译阶段就可以解决),泛型应运而生。

我们将第一行声明初始化list的代码更改一下,编译器会在编译阶段就能够帮我们发现类似这样的问题。

3. 特性

泛型只在编译阶段有效。看下面的代码:

输出结果:D/泛型测试: 类型相同。

通过上面的例子可以证明,在编译之后程序会采取去泛型化的措施。也就是说Java中的泛型,只在编译阶段有效。在编译过程中,正确检验泛型结果后,会将泛型的相关信息擦出,并且在对象进入和离开方法的边界处添加类型检查和类型转换的方法。也就是说,泛型信息不会进入到运行时阶段。

对此总结成一句话:泛型类型在逻辑上看以看成是多个不同的类型,实际上都是相同的基本类型。

4. 泛型的使用

泛型有三种使用方式,分别为:泛型类、泛型接口、泛型方法。

4.1 泛型类
泛型类型用于类的定义中,被称为泛型类。通过泛型可以完成对一组类的操作对外开放相同的接口。最典型的就是各种容器类,如:List、Set、Map。

泛型类的最基本写法(这么看可能会有点晕,会在下面的例子中详解):

一个最普通的泛型类:

定义的泛型类,就一定要传入泛型类型实参么?并不是这样,在使用泛型的时候如果传入泛型实参,则会根据传入的泛型实参做相应的限制,此时泛型才会起到本应起到的限制作用。如果不传入泛型类型实参的话,在泛型类中使用泛型的方法或成员变量定义的类型可以为任何的类型。

看一个例子:

注意:
泛型的类型参数只能是类类型,不能是简单类型。
不能对确切的泛型类型使用instanceof操作。如下面的操作是非法的,编译时会出错。

4.2 泛型接口
泛型接口与泛型类的定义及使用基本相同。泛型接口常被用在各种类的生产器中,可以看一个例子:

当实现泛型接口的类,未传入泛型实参时:

当实现泛型接口的类,传入泛型实参时:

4.3 泛型通配符
我们知道Ingeter是Number的一个子类,同时在特性章节中我们也验证过Generic与Generic实际上是相同的一种基本类型。那么问题来了,在使用Generic作为形参的方法中,能否使用Generic的实例传入呢?在逻辑上类似于Generic和Generic是否可以看成具有父子关系的泛型类型呢?

为了弄清楚这个问题,我们使用Generic这个泛型类继续看下面的例子:

通过提示信息我们可以看到Generic不能被看作为`Generic的子类。由此可以看出:同一种泛型可以对应多个版本(因为参数类型是不确定的),不同版本的泛型类实例是不兼容的。

回到上面的例子,如何解决上面的问题?总不能为了定义一个新的方法来处理Generic类型的类,这显然与java中的多台理念相违背。因此我们需要一个在逻辑上可以表示同时是Generic和Generic父类的引用类型。由此类型通配符应运而生。

我们可以将上面的方法改一下:

类型通配符一般是使用?代替具体的类型实参,注意了,此处’?’是类型实参,而不是类型形参 。重要说三遍!此处’?’是类型实参,而不是类型形参 ! 此处’?’是类型实参,而不是类型形参 !再直白点的意思就是,此处的?和Number、String、Integer一样都是一种实际的类型,可以把?看成所有类型的父类。是一种真实的类型。

可以解决当具体类型不确定的时候,这个通配符就是 ?  ;当操作类型时,不需要使用类型的具体功能时,只使用Object类中的功能。那么可以用 ? 通配符来表未知类型。

4.4 泛型方法
在java中,泛型类的定义非常简单,但是泛型方法就比较复杂了。

尤其是我们见到的大多数泛型类中的成员方法也都使用了泛型,有的甚至泛型类中也包含着泛型方法,这样在初学者中非常容易将泛型方法理解错了。

泛型类,是在实例化类的时候指明泛型的具体类型;泛型方法,是在调用方法的时候指明泛型的具体类型 。

4.4.1 泛型方法的基本用法
光看上面的例子有的同学可能依然会非常迷糊,我们再通过一个例子,把我泛型方法再总结一下。

4.4.2 类中的泛型方法
当然这并不是泛型方法的全部,泛型方法可以出现杂任何地方和任何场景中使用。但是有一种情况是非常特殊的,当泛型方法出现在泛型类中时,我们再通过一个例子看一下:

4.4.3 泛型方法与可变参数
再看一个泛型方法和可变参数的例子:

4.4.4 静态方法与泛型
静态方法有一种情况需要注意一下,那就是在类中的静态方法使用泛型:静态方法无法访问类上定义的泛型;如果静态方法操作的引用数据类型不确定的时候,必须要将泛型定义在方法上。

即:如果静态方法要使用泛型的话,必须将静态方法也定义成泛型方法 。

4.4.4 泛型方法总结
泛型方法能使方法独立于类而产生变化,以下是一个基本的指导原则:

无论何时,如果你能做到,你就该尽量使用泛型方法。也就是说,如果使用泛型方法将整个类泛型化,那么就应该使用泛型方法。另外对于一个static的方法而已,无法访问泛型类型的参数。所以如果static方法要使用泛型能力,就必须使其成为泛型方法。

4.4.5 泛型上下边界
在使用泛型的时候,我们还可以为传入的泛型类型实参进行上下边界的限制,如:类型实参只准传入某种类型的父类或某种类型的子类。为泛型添加上边界,即传入的类型实参必须是指定类型的子类型

如果我们把泛型类的定义也改一下:

再来一个泛型方法的例子:

通过上面的两个例子可以看出:泛型的上下边界添加,必须与泛型的声明在一起 。

4.4.6 关于泛型数组要提一下
看到了很多文章中都会提起泛型数组,经过查看sun的说明文档,在java中是”不能创建一个确切的泛型类型的数组”的。

也就是说下面的这个例子是不可以的:

而使用通配符创建泛型数组是可以的,如下面这个例子:

这样也是可以的:

下面使用Sun的一篇文档的一个例子来说明这个问题:

这种情况下,由于JVM泛型的擦除机制,在运行时JVM是不知道泛型信息的,所以可以给oa[1]赋上一个ArrayList而不会出现异常,但是在取出数据的时候却要做一次类型转换,所以就会出现ClassCastException,如果可以进行泛型数组的声明,上面说的这种情况在编译期将不会出现任何的警告和错误,只有在运行时才会出错。

而对泛型数组的声明进行限制,对于这样的情况,可以在编译期提示代码有类型安全问题,比没有任何提示要强很多。

下面采用通配符的方式是被允许的:数组的类型不可以是类型变量,除非是采用通配符的方式,因为对于通配符的方式,最后取出数据是要做显式的类型转换的。

5. 最后

本文中的例子主要是为了阐述泛型中的一些思想而简单举出的,并不一定有着实际的可用性。另外,一提到泛型,相信大家用到最多的就是在集合中,其实,在实际的编程过程中,自己可以使用泛型去简化开发,且能很好的保证代码质量。

原文:https://blog.csdn.net/s10461/article/details/53941091