熟悉和应用 Python 的装饰器

Python 在语法上除了冒号与强制缩进外其实也没有太多令人眼前一亮的东西,倒是它的装饰器(Decorator) 值得玩味。初读 《THE Quick Python Book》一书,关于 Decorator(装饰器) 这一节匆匆而过,只是觉得它像 Java 注解一样的东西,没太细究。后来慢慢看到还是不少地方在用装饰器,如 Python 的属性 @property, @name_attr.setter, 还有 Flask 中用于定义路由的 @app.route('/') 等。

因此还是有必要花些功夫去更深入的了解 Python 的装饰器,从目前对装饰器的理解,它兼具 Java 的注解与代理的功能,而且比 Java 中自定义注解的处理与动态代理的实现要简单的多,甚至不需要特别牵涉到到面向方面的编程这么一个专门的概念。Python 的装饰器并非指的设计模式中的装饰器模式,Python 的装饰器主要还是关于代理,或叫方法拦截,切面的。

装饰器简单说来就是一个高阶函数,即一个函数作为另一个函数的参数,比如说函数 A 作为函数 B 的参数,然后函数 B 的实现有能力决定实际调用 A 的前后作点手脚,甚至压根不调用 A。由此,装饰器完全可以实现面向方面的 @Before, @After, @Around, @AfterReturning, @AfterThrowing 所有语义。

Python 中的函数像 JavaScript 的一样是头等对象(first-class objects),所以函数本身可以作为参数任意传递,一个函数也可以返回另一个函数。Python 的函数中还允许用相同的 def func():... 语法定义内部函数。 阅读全文 >>

Python 包管理及虚拟环境的应用(三: pipenv)

前两篇分别学习了 Python 如何进行依赖的管理,以及结合虚拟环境来使用 pip 进行依赖管理。而有人觉得把 virtualenv 与 pip 分开来操作太麻烦了,而且 requirements.txt 描述依赖的方式十分笨拙,所以在前两者之上创建了 pipenv, 也谈不上重新发明了轮子吧。

3. Pipenv: 新一代依赖管理与虚拟环境

倘若不是经由 virtualenv, venv 而来到 pipenv,没有对比也就无法体会到 pipenv 的妙处的。pipenv 在总结了 virtualenv/venv 的缺点之后由 Kenneth Reitz 于 2017 年 1 月发布的新型 Python 依赖管理器。

  1. 它不再需要单独用 virtualenv 和 pip,只要一条命令 pipenv 完成所有的事
  2. 不用手动管理 requirements.txt 文件,而是由  pipenv 自动维护 Pipfile 和 Pipfile.lock 文件
  3. 自动创建虚拟环境,并且虚拟环境与项目文件分离
  4. 更详尽的依赖图(例如 pipenv graph),像 mvn dependency:tree 那样显示依赖树
  5. 控制台下输出颜色更丰富

阅读全文 >>

Python 包管理及虚拟环境的应用(二: virtualenv)

原本想在一篇之内覆盖到 Python 的包管理以及各类虚拟环境的应用,没想根本就是一发不可收拾,恐怕两篇都完不了,所以也要进行重构。这里只涉及到 Python 的虚拟环境 venv 和 virtualenv,至于标题的话,也不想再改了,只作一,二,三编号,必要时仍能连缀成长篇。最后一篇将单独学习 pipenv 的应用。

以下序号也是承接上一篇 Python 包管理及虚拟环境的应用(一)

2. Python 虚拟环境

关于创建 Python 项目的虚拟环境,有三个工具可用, venv, virtualenv, 以及后面单独要学到的 pipenv

  1. venv , 即 python3 -m venv 命令,Python 3.3 及新版本自带了,为 Python 3.4 及以后的版本创建的虚拟环境会有 pip 和 setuptools 命令
  2. virtualenv 需要单独安装,但是它支持 Python 2.7 和  Python 3.3+, 创建的虚拟环境中带有 pip, setuptools 和 wheel 命令
  3. 另外,pyvenv 脚本也可用来创建 Python 虚拟环境,不过它自 Python 3.6 不推荐使用,建议用 python3 -m venv 命令

阅读全文 >>

使用 PostgreSQL 的 uuid 字段类型

上一篇 使用 SQL Server 的 uniqueidentifier 字段类型 了解了 SQL Server 中如何使用 uniqueidentifier 字段类型后,现在来看下 PostgreSQL 中如何使用 uuid 字段类型。在 PostgreSQL 的字段类型是 uuid 了,所以创建一个带有 uuid 字段的表是

CREATE TABLE customers (
    id uuid PRIMARY KEY,
    name VARCHAR(36)
);

我们这里设置 id 字段类型为 uuid, 并且它是一个主键。也可以应用函数指定它的默认值,下面将会讲述到。

然后用 SQL 语句来向该表插入记录 阅读全文 >>

用 PreparedStatement 向 SqlServer 中一次性插入多条记录

标准 SQL 都提供了下面这种方式一条 INSERT INTO 语句插入多条记录

INSERT INTO Customers(Id, Name, Age) VALUES (1, 'Name1', 21.5), (2, 'Name2', 32.3)

VALUES 之后用括号列出每一条记录。但是在 Java 中想把上面的语句转换成 PreparedStatement  来插入多条记录时就有些问题。要么写成

INSERT INTO Customers(Id, Name, Age) VALUES(?, ?, ?), (?, ?, ?), (?, ?, ?) ....

我们不知道 VALUES 后应该列多少个问号,而且  JDBC 对参数的个数是有限制的,最多 2000 个参数。如果根据字段个数来算一次添加多少条记录,那么这条 SQL 语句也是动态的,不能很好的作为 PreparedStatement 进行预编译。以一个表三个字段为例,2000 个参数下一次性最多能插入记录数 666 条,也可能由于输入是 666 条记录的任意数量,所以生成的语句非静态的。

这种方式与每次手动拼凑一个完全静态的 INSERT INTO 语句应该不会有太多的差别。

如果只是写成 

INSERT INTO Customers(Id, Name, Age) VALUES(?, ?, ?)

然后试图进行下面的操作 阅读全文 >>

Spring 项目中把属性或 SQL 语句写在 .xml 文件中

Spring 项目中把大量的 SQL 分散在 Java 代码中,无 Here Doc 的情况下用加号来连接写着实在是不爽,于是之前思考这个 Spring 项目中把 SQL 语句写在 .sql 文件中 --  把它们写在 *.sql 文件中,但是这个 *.sql 需要特定的格式来标识属性 Key

--!select.user
select id, firstname, lastname, address
--!update.user
update ........

而且还需要一个额外的类 SqlPropertySourceFactory 来解析上面的 *.sql 文件, 识别出 select.user 是 Key, 紧接着后面的块是相应的属性值,用注解引用它时还有点额外的 factory 属性来配置,如

@PropertySource(value = "classpath:sql/queries.sql", factory = SqlPropertySourceFactory.class)

所以一直在思考是否能够再简单些,是否能用一个自定义的注解,如

@SqlPropertySource("classpath:sql/queries.sql")

捉摸了很久,似乎有点难度,不过再不断发掘的过程中找到了这个类 org.springframework.core.io.support.PropertiesLoaderUtils, 有下面的代码片断 阅读全文 >>

使用 Awaitility 测试异步代码

对于同步方法的测试很简单,调用完后可立马检查执行状态; 而异步方法,由于我们无法确切的知道何时结束,因此以往的办法是用 Thread.sleep(500) 来预估一个执行时间。然后通常我们估计的要长于实际的时间,这就很浪费,况且偶然的超过预估的等待时间也并不意味着代码有问题。还有 sleep 方法还抛出一个检测异常 InterruptedException, 一般会要对 Thread.sleep(500) 作下简单包装。

于是今天要介绍的 Awaitility 就应运而生了,专门针对异步方法的测试。它的官方文档在 https://github.com/awaitility/awaitility/wiki/Usage。本文主要关注在 Java 8 环境下用 Lambda 的代码书写方式。Awaitlity 实际运行是以某种轮询的方式来检查是否达到某个运行状态,可设定最多,最少等待时间,或永久等待,或自定义轮询策略,之后就开始进行需要的断言,所以它可以尽可能的节省测试异步方法所需的时长。而不像 Thread.sleep(500) 一路等到黑,并且没有回头路。

通常我会在项目中给 JUnit 配上三个最佳伴侣,它们是(按 mvn dependency:tree 中的显示方式):

  1. org.awaitility:awaitility:2.0.0:test
  2. org.assertj:assertj-core: version: 3.8.0:test
  3. org.mockito:mockito-core:2.7.22:test

当然如果项目中没有异步调用自然是不需要 Awaitility, 在我的项目中是基本不可能的。以上三种都追求 DSL,以流畅的方式进行愉快的测试。

现在来尝试下 Awaitility 的几种基本的用法,先假定有下面的代码 UserService 阅读全文 >>