分类 技术 下的文章

为初学者介绍尖括号。

Bash 内置了很多诸如 lscdmv 这样的重要的命令,也有很多诸如 grepawksed 这些有用的工具。但除此之外,其实 Bash 中还有很多可以起到胶水作用的标点符号,例如点号(.)、逗号(,)、括号(<>)、引号(")之类。下面我们就来看一下可以用来进行数据转换和转移的尖括号(<>)。

转移数据

如果你对其它编程语言有所了解,你会知道尖括号 <> 一般是作为逻辑运算符,用来比较两个值之间的大小关系。如果你还编写 HTML,尖括号作为各种标签的一部分,就更不会让你感到陌生了。

在 shell 脚本语言中,尖括号可以将数据从一个地方转移到另一个地方。例如可以这样把数据存放到一个文件当中:

ls > dir_content.txt

在上面的例子中,> 符号让 shell 将 ls 命令的输出结果写入到 dir_content.txt 里,而不是直接显示在命令行中。需要注意的是,如果 dir_content.txt 这个文件不存在,Bash 会为你创建;但是如果 dir_content.txt 是一个已有的非空文件,它的内容就会被覆盖掉。所以执行类似的操作之前务必谨慎。

你也可以不使用 > 而使用 >>,这样就可以把新的数据追加到文件的末端而不会覆盖掉文件中已有的数据了。例如:

ls $HOME > dir_content.txt; wc -l dir_content.txt >> dir_content.txt

在这串命令里,首先将家目录的内容写入到 dir_content.txt 文件中,然后使用 wc -l 计算出 dir_content.txt 文件的行数(也就是家目录中的文件数)并追加到 dir_content.txt 的末尾。

在我的机器上执行上述命令之后,dir_content.txt 的内容会是以下这样:

Applications
bin
cloud
Desktop
Documents
Downloads
Games
ISOs
lib
logs
Music
OpenSCAD
Pictures
Public
Templates
test_dir
Videos
17 dir_content.txt

你可以将 >>> 作为箭头来理解。当然,这个箭头的指向也可以反过来。例如,Coen brothers (LCTT 译注:科恩兄弟,一个美国电影导演组合)的一些演员以及他们出演电影的次数保存在 CBActors 文件中,就像这样:

John Goodman 5
John Turturro 3
George Clooney 2
Frances McDormand 6
Steve Buscemi 5
Jon Polito 4
Tony Shalhoub 3
James Gandolfini 1

你可以执行这样的命令:

sort < CBActors
Frances McDormand 6 # 你会得到这样的输出
George Clooney 2
James Gandolfini 1
John Goodman 5
John Turturro 3
Jon Polito 4
Steve Buscemi 5
Tony Shalhoub 3

就可以使用 sort 命令将这个列表按照字母顺序输出。但是,sort 命令本来就可以接受传入一个文件,因此在这里使用 < 会略显多余,直接执行 sort CBActors 就可以得到期望的结果。

如果你想知道 Coens 最喜欢的演员是谁,你可以这样操作。首先:

while read name surname films; do echo $films $name $surname > filmsfirst.txt; done < CBActors

上面这串命令写在多行中可能会比较易读:

while read name surname films;\
 do
 echo $films $name $surname >> filmsfirst;\
 done < CBActors

下面来分析一下这些命令做了什么:

  • while …; do … done 是一个循环结构。当 while 后面的条件成立时,dodone 之间的部分会一直重复执行;
  • read 语句会按行读入内容。read 会从标准输入中持续读入,直到没有内容可读入;
  • CBActors 文件的内容会通过 < 从标准输入中读入,因此 while 循环会将 CBActors 文件逐行完整读入;
  • read 命令可以按照空格将每一行内容划分为三个字段,然后分别将这三个字段赋值给 namesurnamefilms 三个变量,这样就可以很方便地通过 echo $films $name $surname >> filmsfirst;\ 来重新排列几个字段的放置顺序并存放到 filmfirst 文件里面了。

执行完以后,查看 filmsfirst 文件,内容会是这样的:

5 John Goodman
3 John Turturro
2 George Clooney
6 Frances McDormand
5 Steve Buscemi
4 Jon Polito
3 Tony Shalhoub
1 James Gandolfini

这时候再使用 sort 命令:

sort -r filmsfirst

就可以看到 Coens 最喜欢的演员是 Frances McDormand 了。(-r 参数表示降序排列,因此 McDormand 会排在最前面)


via: https://www.linux.com/blog/learn/2019/1/understanding-angle-brackets-bash

作者:Paul Brown 选题:lujun9972 译者:HankChow 校对:wxy

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

watchtopac 命令为我们监视 Linux 服务器上的活动提供了一些十分高效的途径。

为了在获取系统活动时更加轻松,Linux 系统提供了一系列相关的命令。在这篇文章中,我们就一起来看看这些对我们很有帮助的命令吧。

watch 命令

watch 是一个用来轻松地重复检测 Linux 系统中一系列数据命令,例如用户活动、正在运行进程、登录、内存使用等。这个命令实际上是重复地运行一个特定的命令,每次都会重写之前显示的输出,它提供了一个比较方便的方式用以监测在你的系统中发生的活动。

首先以一个基础且不是特别有用的命令开始,你可以运行 watch -n 5 date,然后你可以看到在终端中显示了当前的日期和时间,这些数据会每五秒更新一次。你可能已经猜到了,-n 5 选项指定了运行接下来一次命令需要等待的秒数。默认是 2 秒。这个命令将会一直运行并按照指定的时间更新显示,直到你使用 ^C 停下它。

Every 5.0s: date                             butterfly: Wed Jan 23 15:59:14 2019

Wed Jan 23 15:59:14 EST 2019

下面是一个更有趣的命令实例,你可以监控一个在服务器中登录用户的列表,该列表会按照指定的时间定时更新。就像下面写到的,这个命令会每 10 秒更新一次这个列表。登出的用户将会从当前显示的列表中消失,那些新登录的将会被添加到这个表格当中。如果没有用户再登录或者登出,这个表格跟之前显示的将不会有任何不同。

$ watch -n 10 who

Every 10.0s: who                             butterfly: Tue Jan 23 16:02:03 2019

shs      :0           2019-01-23 09:45 (:0)
dory     pts/0        2019-01-23 15:50 (192.168.0.5)
nemo     pts/1        2019-01-23 16:01 (192.168.0.15)
shark    pts/3        2019-01-23 11:11 (192.168.0.27)

如果你只是想看有多少用户登录进来,可以通过 watch 调用 uptime 命令获取用户数和负载的平均水平,以及系统的工作状况。

$ watch uptime

Every 2.0s: uptime                           butterfly: Tue Jan 23 16:25:48 2019

 16:25:48 up 22 days,  4:38,  3 users,  load average: 1.15, 0.89, 1.02

如果你想使用 watch 重复一个包含了管道的命令,就需要将该命令用引号括起来,就比如下面这个每五秒显示一次有多少进程正在运行的命令。

$ watch -n 5 'ps -ef | wc -l'

Every 5.0s: ps -ef | wc -l butterfly: Tue Jan 23 16:11:54 2019

245

要查看内存使用,你也许会想要试一下下面的这个命令组合:

$ watch -n 5 free -m

Every 5.0s: free -m butterfly: Tue Jan 23 16:34:09 2019

Every 5.0s: free -m                          butterfly: Tue Jan 23 16:34:09 2019

              total        used        free      shared  buff/cache   available
Mem:           5959         776        3276          12        1906        4878
Swap:          2047           0        2047

你可以在 watch 后添加一些选项查看某个特定用户下运行的进程,不过 top 为此提供了更好的选择。

top 命令

如果你想查看某个特定用户下的进程,top 命令的 -u 选项可以很轻松地帮你达到这个目的。

$ top -u nemo
top - 16:14:33 up 2 days,  4:27,  3 users,  load average: 0.00, 0.01, 0.02
Tasks: 199 total,   1 running, 198 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.2 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   5959.4 total,   3277.3 free,    776.4 used,   1905.8 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   4878.4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
23026 nemo      20   0   46340   7820   6504 S   0.0   0.1   0:00.05 systemd
23033 nemo      20   0  149660   3140     72 S   0.0   0.1   0:00.00 (sd-pam)
23125 nemo      20   0   63396   5100   4092 S   0.0   0.1   0:00.00 sshd
23128 nemo      20   0   16836   5636   4284 S   0.0   0.1   0:00.03 zsh

你可能不仅可以看到某个用户下的进程,还可以查看每个进程所占用的资源,以及系统总的工作状况。

ac 命令

如果你想查看系统中每个用户登录的时长,可以使用 ac 命令。运行该命令之前首先需要安装 acct(Debian 等)或者 psacct(RHEL、Centos 等)包。

ac 命令有一系列的选项,该命令从 wtmp 文件中拉取数据。这个例子展示的是最近用户登录的总小时数。

$ ac
        total     1261.72

这个命令显示了用户登录的总的小时数:

$ ac -p
        shark                                5.24
        nemo                                 5.52
        shs                               1251.00
        total     1261.76

这个命令显示了每天登录的用户小时数:

$ ac -d | tail -10

Jan 11  total        0.05
Jan 12  total        1.36
Jan 13  total       16.39
Jan 15  total       55.33
Jan 16  total       38.02
Jan 17  total       28.51
Jan 19  total       48.66
Jan 20  total        1.37
Jan 22  total       23.48
Today   total        9.83

总结

Linux 系统上有很多命令可以用于检查系统活动。watch 命令允许你以重复的方式运行任何命令,并观察输出有何变化。top 命令是一个专注于用户进程的最佳选项,以及允许你以动态方式查看进程的变化,还可以使用 ac 命令检查用户连接到系统的时间。


via: https://www.networkworld.com/article/3335200/linux/how-to-monitor-activity-on-your-linux-server.html

作者:Sandra Henry-Stocker 选题:lujun9972 译者:dianbanjiu 校对:wxy

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

了解一下配置管理工具,以找出哪个最适合你的 DevOps 组织。

DevOps 正因为有提高产品质量、缩短产品开发时间等优势,目前备受业界关注,同时也在长足发展当中。

DevOps 的核心价值观 团队文化 Culture 自动化 Automation 评估 Measurement 分享 Sharing (CAMS),同时,团队对 DevOps 的执行力也是 DevOps 能否成功的重要因素。

  • 团队文化让大家团结一致;
  • 自动化是 DevOps 的基础;
  • 评估保证了及时的改进;
  • 分享让 CAMS 成为一个完整的循环过程。

DevOps 的另一个思想是任何东西,包括服务器、数据库、网络、日志文件、应用配置、文档、自动化测试、部署流程等,都可以通过代码来管理。

在本文中,我主要介绍配置管理的自动化。配置管理工具作为 基础架构即代码 Infrastructure as Code (IaC)的一部分,支持使用经过测试和验证的软件开发实践,通过明文定义文件管理和配置数据中心。

DevOps 团队只需要通过操作简单的配置文件,就可以实现应用开发中包括版本控制、测试、小型部署、设计模式在内的这些最佳实践。总而言之,配置管理工具实现了通过编写代码来使基础架构的配置和管理变得自动化。

为什么要使用配置管理工具?

配置管理工具可以提高应用部署和变更的效率,还可以让这些流程变得可重用、可扩展、可预测,甚至让它们维持在期望的状态,从而让资产的可控性提高。

使用配置管理工具的优势还包括:

  • 让代码遵守编码规范,提高代码可读性;
  • 具有 幂等性 Idempotency ,也就是说,无论执行多少次重复的配置管理操作,得到的结果都是一致的;
  • 分布式的设计可以方便地管理大量的远程服务器。

配置管理工具主要分为 拉取 pull 模式和 推送 push 模式。拉取模式是指安装在各台服务器上的 代理 agent 定期从 中央存储库 central repository 拉取最新的配置并应用到对应的服务器上;而推送模式则由 中央服务器 central server 的中央服务器会触发其它受管服务器的更新。

五大最流行的配置管理工具

目前配置管理工具有很多,不同的配置管理工具都有自己最适合的使用场景。而对于下面五个我按照字母顺序列出的配置管理工具,都对 DevOps 有明显的帮助:全都具有开源许可证、使用外部配置文件、支持无人值守运行、可以通过脚本自定义运行。下面对它们的介绍都来源于它们的软件库和官网内容。

Ansible

“Ansible 是一个极其简洁的 IT 自动化平台,可以让你的应用和系统以更简单的方式部署。不需要安装任何代理,只需要使用 SSH 的方式和简单的语言,就可以免去脚本或代码部署应用的过程。”——GitHub Ansible 代码库

Ansible 是我最喜欢的工具之一,我在几年前就开始使用了。你可以使用 Ansible 在命令行中让多个服务器执行同一个命令,也可以使用 YAML 格式的 剧本 playbook 来让它自动执行特定的操作,这促进了技术团队和非技术团队之间的沟通。简洁、无代理、配置文件对非技术人员友好是它的几个主要优点。

由于 Ansible 不需要代理,因此对服务器的资源消耗会很少。Ansible 默认使用的推送模式需要借助 SSH 连接,但 Ansible 也支持拉取模式。剧本 可以使用最少的命令集编写,当然也可以扩展为更加精细的自动化任务,包括引入角色、变量和其它人写的模块。

你可以将 Ansible 和其它工具(包括 Ansible Works、Jenkins、RunDeck、ARA 等)结合起来使用,因为这些工具 提供了运行剧本时的可追溯性,这样就可以创建控制流程的中央控制台。

CFEngine

“CFEngine 3 是一个流行的开源配置管理系统,它主要用于为大规模的系统提供自动化配置和维护。”——GitHub CFEngine 代码库

CFEngine 最早在 1993 年由 Mark Burgess 作为自动配置管理的科学方法提出,目的是降低计算机系统配置中的熵,最终收敛到期望的配置状态,同时还阐述了幂等性是让系统达到期望状态的能力。Burgess 在 2004 年又提出了 承诺理论 Promise Theory ,这个理论描述了代理之间自发合作的模型。

CFEngine 的最新版本已经用到了承诺理论,在各个服务器上的代理程序会从中央存储库拉取配置。CFEngine 的配置对专业技能要求较高,因此它比较适合技术团队使用。

Chef

“为整个基础架构在配置管理上带来便利的一个系统集成框架。”——GitHub Chef 代码库

Chef 通过由 Ruby 编写的“ 菜谱 recipe ”来让你的基础架构保持在最新、最兼容的状态,这些“菜谱”描述了一系列应处于某种状态的资源。Chef 既可以通过客户端-服务端的模式运行,也可以在 chef-solo 这种独立配置的模式下运行。大部分云提供商都很好地集成了 Chef,因此可以使用它为新机器做自动配置。

Chef 有广泛的用户基础,同时也提供了完备的工具包,让不同技术背景的团队可以通过“菜谱”进行沟通。尽管如此,它仍然算是一个技术导向的工具。

Puppet

“Puppet 是一个可以在 Linux、Unix 和 Windows 系统上运行的自动化管理引擎,它可以根据集中的规范来执行诸如添加用户、安装软件包、更新服务器配置等等管理任务。”——GitHub Puppet 代码库

Puppet 作为一款面向运维工程师和系统管理员的工具,在更多情况下是作为配置管理工具来使用。它通过客户端-服务端的模式工作,使用代理从主服务器获取配置指令。

Puppet 使用 声明式语言 declarative language 或 Ruby 来描述系统配置。它包含了不同的模块,并使用 清单文件 manifest files 记录期望达到的目标状态。Puppet 默认使用推送模式,但也支持拉取模式。

Salt

“为大规模基础结构或应用程序实现自动化管理的软件。”——GitHub Salt 代码库

Salt 的专长就是快速收集数据,即使是上万台服务器也能够轻松完成任务。它使用 Python 模块来管理配置信息和执行特定的操作,这些模块可以让 Salt 实现所有远程操作和状态管理。但配置 Salt 模块对技术水平有一定的要求。

Salt 使用客户端-服务端的结构(Salt minions 是客户端,而 Salt master 是服务端),并以 Salt 状态文件记录需要达到的目标状态。

总结

DevOps 工具领域一直在发展,因此必须时刻关注其中的最新动态。希望这篇文章能够鼓励读者进一步探索相关的概念和工具。为此, 云原生计算基金会 Cloud Native Computing Foundation (CNCF)在 Cloud Native Landscape Project 中也提供了很好的参考案例。


via: https://opensource.com/article/18/12/configuration-management-tools

作者:Marco Bravo 选题:lujun9972 译者:HankChow 校对:wxy

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

十月初,由 Opensource.com 赞助的首届 Open Jam 吸引了来自世界各地的团队的 45 个参赛项目。这些队伍只用了三天时间就用开源软件制作出一个游戏来参与角逐,有三支队伍取得了胜利

我们在我们的大学为每一位愿意参与的人举办了我们自己的 Open Jam 活动。我们预留了周末的计算机实验室,并教大家使用开源软件来创建游戏和游戏素材:游戏引擎:Godot、音乐:LMMS、2D 素材:GIMP、3D 素材:Blender。我们的活动产出了三个游戏:LoathsomeLost ArtistPaint Rider(我做的)。

根据我在游戏开发和游戏开发方面的经验,这里有 10 条关于游戏引擎、编码和快速游戏开发的经验教训。

1、限定规模

很容易想要去做一个规模宏大的冒险游戏或者可以比拟你最喜欢的游戏的东西。如果你有一些经验,追求超乎游戏 Jam 活动的东西可能很酷,但不要高估自己拥有的时间。我欣赏游戏 Jam 活动的一点是它强制你快速将一个游戏从概念阶段变成最终产品,因为你的时间非常有限。这也就是限定规模如此重要的原因。

这个 Open Jam 的主题是“留下痕迹”,题目一出来,我和朋友就开始讨论什么样的游戏适合该主题。一个想法就是做玩家能在敌人身上留下伤痕的 3D 拳击游戏。我几乎没有做 3D 游戏的经验,我想做好的话,在我甚至还没发掘出可玩性之前,就得花太多时间在学习如何让痕迹合理和打击有效。

2、尽早可玩

这是我对游戏 Jam 活动最中肯的建议。试着做出核心机制,快速写出代码,这样你就可以测试并决定它是否值得做成一个完整的游戏。不应该只剩几个小时截止了,你的游戏才可玩。像 Open Jam 这样的三天的活动,不应该花费几个小时以上来做一个可以运行的演示。

3、保持简单

你想加入的每个特性都会延长整个开发时间。因为你不能迅速使之运行,所以无从得知提交一个新特性是否会消耗大量时间。街机风格的高分作品往往会在游戏 Jam 活动中表现良好,它们天生就很简单。一旦核心部分完成,你可以开始加入特性并润色,无需担心最后游戏是否功能正常。

4、从其他游戏获取灵感

可能你想做出完全原创的作品,但有个可以基于它开发的原型极其有用。这将节省重复劳动的时间,因为你已经知道什么有趣。告诉自己实践的经验越多,越容易做出包含自己想法的大型游戏,所以你也能从再创作其他人的作品中得到很好地练习。

考虑到 Open Jam 的“留下痕迹”主题,我觉得创作一个玩的时候可以留下颜料痕迹的游戏会很有趣,这样也可以看到你留下的标记。我记得有款老式动画游戏 Line Rider 2 Beta (后来叫 Paint Rider),而且知道玩的时候按住 Control 键可以画出痕迹的彩蛋。我简化了这个概念,甚至只需要一个按键来垂直移动。(更像老式飞机游戏)。进入到 Jam 活动大概一两个小时后,我就有了基本模型,可以用一个按钮上下移动和留下小黑圈的痕迹。

5、不要忽视可得性

确保尽可能多的人能玩你的游戏。某个提交到 Open Jam 的游戏是虚拟现实游戏。尽管那很酷,但几乎没有人可以玩,因为拥有 VR 设备的人不多。所幸它的开发者并不期望取得好名次,只是想练手。但如果你想和人们分享你的游戏(或者赢得游戏 Jam 活动),注意可得性是很重要的。

Godot (和其他大多数游戏引擎)允许你在所有主流平台发布游戏。提交游戏时,特别是在 Itch.io,有个浏览器版本就可以支持大多数人玩。但尽你所能去发布在更多的平台和操作系统上。我甚至试着在移动端发布 Paint Rider,但技术有限。

6、不要做得太难

如果游戏需要花费过多精力去学或者玩,你将失去一部分玩家。要保持简单和限定规模,这在游戏计划阶段非常重要。再次重申,想出一个需要花上十天半个月开发的宏大的游戏创意很容易;难的是做出好玩、简单的游戏。

给我的妈妈介绍了 Paint Rider 之后,她很快开始玩起来,我认为不需要跟她说明更多。

7、不用太整洁

如果你习惯于花时间在设计模式上和确保代码可复用、可适应,试着放松一点。如果你花太多时间考虑设计,当你最后到了可以玩游戏的时候,你可能发现游戏不是很有趣,那时候就来不及修改了。

这过程也适用于简化更严格的游戏:快速码出验证概念性展示模型,直到找出值得做成完整游戏的,然后你可以潜心建立完美的代码来支持它。为游戏 Jame 活动创作的游戏就像是个快速开发一个可验证的模型一样。

8、但也不要太随意

另一方面, 意大利面式代码 容易失控,即使游戏开发没有大量代码。还好大多是游戏引擎都考虑到了设计模式。就拿 Godot 的信号 功能来说,节点可以发送数据信息给它们“连上了”的节点 —— 这是你的设计自动成型的观察者模式。只要你知道如何利用这种游戏引擎的特性的优势,就可以快速写代码,你的代码也不会特别难读。

9、取得反馈

向人们展示你正在做的。让他们试一试并看看他们说些啥。看看他们如何玩你的游戏,找找他们有没有发现你预料之外的事。如果游戏 Jam 活动有 Discord 频道或者类似的,把你的游戏放上去,人们会反馈给你想法。Paint Rider 的一个确定的功能是画布循环,所以你可以看到之前留下来的画。在有人问我为什么这个游戏没有之前,我甚至没有考虑那个机制。

团队协作的话,确保有可以传递周围反馈的人参与这个开发。

而且不要忘了用相同的方式帮助其他人;如果你在玩其他人游戏的时候发现了有助于你游戏的东西,这就是双赢。

10、哪里找资源

做出所有你自己的资源真的会拖你后腿。Open Jam 期间,当我忙于组装新特性和修漏洞时,我注意到 Loathsome 的开发者花了大量时间在绘制主要角色上。你可以简化游戏的艺术风格创作并且用一些视听效果尚可的东西,但这里还有其他选择。试着寻找 Creative Commons 许可的或免费音乐站点(比如 Anttis Instrumentals)的资源。或者,可行的话,组建一个有专门艺术家、作家或者音乐家的团队。

其他你可能觉得有用的软件有 Krita,这是一款适合数字绘画的开源 2D 图像生成软件,特别是如果你有一块绘图板的话;还有 sfxr,这是一款游戏音效生成软件,很多参数可以调,但正如它的开发者所说:“它的基本用法包括了按下随机按钮。”(Paint Rider 的所有音效都是用 Sfxr 做的。)你也可以试试 Calinou 的众多但有序的开源游戏开发软件列表。

你参加 Open Jam 或者其他游戏 Jam 并有别的建议吗?对我未提及的有问题吗?有的话,请在评论中分享。


via: https://opensource.com/article/17/12/10-keys-rapid-open-source-game-development

作者:Ryan Estes 译者:XYenChi 校对:wxy

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

这 12 个步骤能确保成功发布。

你写了一个 Python 库。自己觉着这太棒了!如果让人们能够轻松使用它不是很优雅么?这有一个需要考虑的清单,以及在开源 Python 库时要采取的具体步骤。

1、源码

将代码放在 GitHub 上,这里有很多开源项目,并且人们很容易提交拉取请求。

2、许可证

选择一个开源许可证。一般来说 MIT 许可证是一个挺好的宽容许可证。如果你有特定要求,Creative Common 的选择许可证可以指导你完成其它选择。最重要的是,在选择许可证时要记住三条规则:

  • 不要创建自己的许可证。
  • 不要创建自己的许可证。
  • 不要创建自己的许可证。

3、README

将一个名为 README.rst 的文件(使用 ReStructured Text 格式化)放在项目树的顶层。

GitHub 将像 Markdown 一样渲染 ReStructured Text,而 ReST 在 Python 的文档生态系统中的表现更好。

4、测试

写测试。这对你来说没有用处。但对于想要编写避免破坏相关功能的补丁的人来说,它非常有用。

测试可帮助协作者进行协作。

通常情况下,如果可以用 pytest 运行就最好了。还有其他测试工具 —— 但很少有理由去使用它们。

5、样式

使用 linter 制定样式:PyLint、Flake8 或者带上 --check 的 Black 。除非你使用 Black,否则请确保在一个文件中指定配置选项,并签入到版本控制系统中。

6、API 文档

使用 docstrings 来记录模块、函数、类和方法。

你可以使用几种样式。我更喜欢 Google 风格的 docstrings,但 ReST docstrings 也是一种选择。

Sphinx 可以同时处理 Google 风格和 ReST 的 docstrings,以将零散的文档集成为 API 文档。

7、零散文档

使用 Sphinx。(阅读我们这篇文章。)教程很有用,但同样重要的是要指明这是什么、它有什么好处、它有什么坏处、以及任何特殊的考虑因素。

8、构建

使用 tox 或 nox 自动运行测试和 linter,并构建文档。这些工具支持“依赖矩阵”。这些矩阵往往会快速增长,但你可以尝试针对合理的样本进行测试,例如 Python 版本、依赖项版本以及可能安装的可选依赖项。

9、打包

使用 setuptools 工具。写一个 setup.py 和一个 setup.cfg。如果同时支持 Python 2 和 3,请在 setup.cfg 中指定 universal 格式的 wheel。

tox 或 nox 应该做的一件事是构建 wheel 并对已安装的 wheel 进行测试。

避免使用 C 扩展。如果出于性能或绑定的原因一定需要它们,请将它们放在单独的包中。正确打包 C 扩展可以写一篇新的文章。这里有很多问题!

10、持续集成

使用公共持续工具。TravisCICircleCI 为开源项目提供免费套餐。将 GitHub 或其他仓库配置为在合并拉请求之前需要先通过检查,那么你就不必担心在代码评审中告知用户修复测试或样式。

11、版本

使用 SemVerCalVer。有许多工具可以帮助你管理版本:incrementalbumpversionsetuptools\_scm 等都是 PyPI 上的包,都可以帮助你管理版本。

12、发布

通过运行 tox 或 nox 并使用 twine 将文件上传到 PyPI 上发布。你可以通过在 DevPI 中“测试上传”。


via: https://opensource.com/article/18/12/tips-open-sourcing-python-libraries

作者:Moshe Zadka 选题:lujun9972 译者:geekpi 校对:wxy

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

使用此框架编写断言,提高开发测试的准确性。

测试金字塔的底部是单元测试。单元测试每次只测试一个代码单元,通常是一个函数或方法。

通常,设计单个单元测试是为了测试通过一个函数或特定分支的特定执行流程,这使得将失败的单元测试和导致失败的 bug 对应起来变得容易。

理想情况下,单元测试很少使用或不使用外部资源,从而隔离它们并使它们更快。

单元测试套件通过在开发过程的早期发现问题来帮助维护高质量的产品。有效的单元测试可以在代码离开开发人员机器之前捕获 bug,或者至少可以在特定分支上的持续集成环境中捕获 bug。这标志着好的和坏的单元测试之间的区别:好的测试通过尽早捕获 bug 并使测试更快来提高开发人员的生产力。坏的测试降低了开发人员的工作效率。

当测试附带的特性时,生产率通常会降低。当代码更改时测试会失败,即使它仍然是正确的。发生这种情况是因为输出的不同,但在某种程度上是因为它不是 函数契约 function’s contract 的一部分。

因此,一个好的单元测试可以帮助执行函数所提交的契约。

如果单元测试中断,那意味着该契约被违反了,应该(通过更改文档和测试)明确修改,或者(通过修复代码并保持测试不变)来修复。

虽然将测试限制为只执行公共契约是一项需要学习的复杂技能,但有一些工具可以提供帮助。

其中一个工具是 Hamcrest,这是一个用于编写断言的框架。最初是为基于 Java 的单元测试而发明的,但它现在支持多种语言,包括 Python

Hamcrest 旨在使测试断言更容易编写和更精确。

def add(a, b):
    return a + b

from hamcrest import assert_that, equal_to

def test_add():
    assert_that(add(2, 2), equal_to(4))  

这是一个用于简单函数的断言。如果我们想要断言更复杂的函数怎么办?

def test_set_removal():
    my_set = {1, 2, 3, 4}
    my_set.remove(3)
    assert_that(my_set, contains_inanyorder([1, 2, 4]))
    assert_that(my_set, is_not(has_item(3)))

注意,我们可以简单地断言其结果是任何顺序的 124,因为集合不保证顺序。

我们也可以很容易用 is_not 来否定断言。这有助于我们编写精确的断言,使我们能够把自己限制在执行函数的公共契约方面。

然而,有时候,内置的功能都不是我们真正需要的。在这些情况下,Hamcrest 允许我们编写自己的 匹配器 matchers

想象一下以下功能:

def scale_one(a, b):
    scale = random.randint(0, 5)
    pick = random.choice([a,b])
    return scale * pick

我们可以自信地断言其结果均匀地分配到至少一个输入。

匹配器继承自 hamcrest.core.base_matcher.BaseMatcher,重写两个方法:

class DivisibleBy(hamcrest.core.base_matcher.BaseMatcher):
    def __init__(self, factor):
        self.factor = factor

    def _matches(self, item):
        return (item % self.factor) == 0

    def describe_to(self, description):
        description.append_text('number divisible by')
        description.append_text(repr(self.factor))

编写高质量的 describe_to 方法很重要,因为这是测试失败时显示的消息的一部分。

def divisible_by(num):
    return DivisibleBy(num)

按照惯例,我们将匹配器包装在一个函数中。有时这给了我们进一步处理输入的机会,但在这种情况下,我们不需要进一步处理。

def test_scale():
    result = scale_one(3, 7)
    assert_that(result,
                any_of(divisible_by(3),
                divisible_by(7)))

请注意,我们将 divisible_by 匹配器与内置的 any_of 匹配器结合起来,以确保我们只测试函数提交的内容。

在编辑这篇文章时,我听到一个传言,取 “Hamcrest” 这个名字是因为它是 “matches” 字母组成的字谜。嗯…

>>> assert_that("matches", contains_inanyorder(*"hamcrest")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/moshez/src/devops-python/build/devops/lib/python3.6/site-packages/hamcrest/core/assert_that.py", line 43, in assert_that
    _assert_match(actual=arg1, matcher=arg2, reason=arg3)
  File "/home/moshez/src/devops-python/build/devops/lib/python3.6/site-packages/hamcrest/core/assert_that.py", line 57, in _assert_match
    raise AssertionError(description)
AssertionError:
Expected: a sequence over ['h', 'a', 'm', 'c', 'r', 'e', 's', 't'] in any order
      but: no item matches: 'r' in ['m', 'a', 't', 'c', 'h', 'e', 's']

经过进一步的研究,我找到了传言的来源:它是 “matchers” 字母组成的字谜。

>>> assert_that("matchers", contains_inanyorder(*"hamcrest"))
>>>

如果你还没有为你的 Python 代码编写单元测试,那么现在是开始的好时机。如果你正在为你的 Python 代码编写单元测试,那么使用 Hamcrest 将允许你使你的断言更加精确,既不会比你想要测试的多也不会少。这将在修改代码时减少误报,并减少修改工作代码的测试所花费的时间。


via: https://opensource.com/article/18/8/robust-unit-tests-hamcrest

作者:Moshe Zadka 选题:lujun9972 译者:MjSeven 校对:wxy

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