一种语言要使用到外部库(模块) 时必然会涉及到从哪里以及按何顺序加载依赖，就像 LD_LIBRARY_PATH, CLASSPATH 那样，Python 也有其默认的模块搜索顺序, 依序找到想要的模块即停止。Python 中 sys.path 返回的列表包含了模块搜索的顺序，我们可以程序中修改该列表，或用 PYTHONPATH 环境变量前插路径，甚至是用  .pth 文件来附加路径。

简单的，可以执行命令 python3 -c "import sys; print(str(sys.path).replace(',', '\n'))" 来查看 python3 交互 shell 下的模块搜索路径，类似结果如下：

[''
'/usr/lib/python36.zip'
'/usr/lib/python3.6'
'/usr/lib/python3.6/lib-dynload'
'/home/yanbin/.local/lib/python3.6/site-packages'
'/usr/local/lib/python3.6/dist-packages'
'/usr/lib/python3/dist-packages'
'/usr/lib/python3.6/dist-packages']

注意，第一个元素是个空字符串，代表进入 python3 shell 时的当前目录。

如果在通过一个 py 脚本文件来打印 sys.path 的话显示稍微有所差异。比如在目录 /home/yanbin/Developers/ 下创建 test.py 文件，内容为 Read More

阅读到 Strings 中关于转换对象为字符串的内容，介绍了 repr 函数，趁着还没有真正了解 Python 面向对象的生疏与热度，感性上理解一下 repr 与 str 这两个函数的区别。

Python 的全局方法 repr 和 str 会映射到对象的 __repr__ 和 __str__ 的方法调用，还有 str(obj) 时会调用哪个方法，以及 print(obj) 和调试 Python 代码时的对象显示会调用哪个方法呢？这就是本文想要印证的内容。

恰如 Java 的 System.out.println(obj) 或 "hello" + obj 都会调用 Java 对象的 toString() 方法，那么 Python 中是怎么一回事呢？

来自某本 Python 入门书的解释 repr 和 str:

1. repr: formal string representation of a Python object
2. str: informal string representation of a Python object，或者说 printable string representation

首先 repr 是 representation 的意思，一个是正式，另一个是非正式，看起来 repr 比 str 显得重要些。 Read More

两年前想摸摸 Python 的门道，简要记录了一篇 我的 Python 快速入门，当时只觉得那是一种与 C/Java 异样风格的编程语言，没领会到特别之处。如今对 Python 的感受就不一般了，因为是云服务，机器学习，人工知道大行其道的年代，所以更为急迫的想把它好好弄明白。

Python 3 说是设计的比  Python 2 要合理的多，所以没有保持向后兼容，现在初学 Python 对于选择哪个版本的 Python 时没有任何犹豫了，当然拣最新的 Python 3 学了。因此各种命令行工具都得用有 3 标记的，如  python3, pip3, pydoc3。

编程语言特别是脚本语言，简单验证或入门最需要一个 REPL 工具，这里不论大型项目时最好选择全功能型的 IDE，像 PyCharm 这样的重型武器。在安装 Python 3 后，它自带了两个，分别是 python3 和 idle3(据说是 Integrated DeveLopment Environment 的缩写词, 可没见这么简陋的 IDE)

Python

命令 python3 进到控制台的 Python 交互界面，Python 标准的 >>> 提示符。没有语法高亮，没有自动缩进，唯一高级点的功能就是 tab 能对变量可以方法，属性的自动完成。 Read More

docker run <image-name> <command> arg1 arg2
docker run <image-name> arg1 arg2

1. 如果没有定义 ENTRYPOINT， CMD 将作为它的 ENTRYPOINT
2. 定义了 ENTRYPOINT 的话，CMD 只为 ENTRYPOINT 提供参数
3. CMD 可由 docker run <image> 后的命令覆盖，同时覆盖参数

初识 Mockito 这个测试框架后，我们要使用 Mock 的属性创建一个被测试类实例时，大概会下面这么纯手工来打造。

假定类 UserService 有一个属性 UserDao userDao, 需要构造 UserService 实例时 Mock 内部状态

UserDao userDao = Mockito.mock(UserDao.class);
UserService testMe = new UserService(userDao);

如此，userDao 的行为就可以自由模拟了，这种纯手工方式都不需要给测试类添加

@RunWith(MockitoJunitRuner.class)
//或
MockitoAnnotations.initMocks(this);

因为上面两句是给 Mockito 的注解使用的。

如果所有的 Mock 对象全部通过手工来创建，那就不容易体现出 Mockito 的优越性出来。因此对于被测试对象的创建，Mock 属性的注入应该让 @Mock 和 @InjectMocks 这两个注解大显身手了。

标注在实例变量上的 @Mock 相当于是 Mockito.mock(Class) 创建了一个 Mock 对象，而 @InjectMock 标的实例会寻找到相应 Mock 属性想法构造出被测试类的实例。看下面的例子： Read More

docker login [OPTIONS] [SERVER]

aws-docker
  ├── Dockerfile
  └── java-webapp-0.0.1-SNAPSHOT.jar

在 Java 测试中使用 Mockito 有段时日了，以前只是想当然的认为 Mock 的对象属性值和方法返回值都是依据同样的规则。基本类型是 0, 0.0, 或 false, 对象类型都是 null, Mock 对象的默认返回值也应该是一样的。直到最近有一天，有一个返回 Optional<String> 类型的方法，由于忘记对该方法打桩，意外的发现它返回的不是 null, 而 Optional.empty(), 因此才意识到此处定有蹊跷。着实有必要用代码验证一下 Mockito 是怎么决定属性及方法的各种返回类型的默认值的。

此次测试所用的 Mockito 版本是 mockito-core-2.12.0.

于是创建了下面一个类 MyClass 用于生成 Mock 对象，选取了一些典型的数据类型, 包括 int, Double, String, long[], Optional<String>, Collection<String>, Map<String, String>, 同时测试 Mock 对象默认的属性值与方法默认返回值。 Read More