ARTS 第一周打卡笔记

[codetalks-new]

Algorithm

参加了 weekly contest 110. 完成了 重新排列日志文件4 第二题一开始理解错了，做成了示路径和，后面才意识到做错了，用了非递归的层次遍历来做，OK，不过有超时，然后加了两个判断减少循环次数，最终AC。 二叉搜索树的范围和

Review

因为我最近是看 《流畅的Python》一书，这本书真是不错。里面引用的资料有介绍到这该篇文章。 How you implemented your Python decorator is wrong 所以跟着过来学习了一下。本文其实是一个系列的相关文章的开头。总结如下： 本文主要介绍通常的大部分的 decorator 的实现方式容易有如下4种问题。

1. 原函数的 __name__ 和 __doc__ 保留问题（可以通过 functools.wraps 缓解）
   2. 使用 inspect 模块对函数进行 inspect 时会导致的问题。
   3. inspect 时获取函数源代码的问题
   4. 当将 decorator 应用到其他作为 descriptor 来实现的 decorator时的问题。

心得：

1. 通常当我们说一个谎话后，我们不得不编出更多的谎话来圆原来的谎话。在 Python 的 decorator 也是如此，当我们对一个函数应用一个 decorator 之后，相当于是狸猫换太子，其实已经发生了翻天覆地的变化了，只不过。最简单的情况下我们觉得工作得良好，其实是比较脆弱的。所以我们不得不做更多的事情使它看起来不那么脆弱。
2. 话说回来，虽然流行的实现 decorator 的方式比较脆弱，但是绝大部分时候都是正常工作的。在工程项目和理论完美方面，很多时候我们选择让工程项目简单直接。

Tip

ps + lsof 帮我找出 redis 的快照文件。 有一台服务器中运行着一个 redis 服务。我想找到其快照文件。 dump.rdb 来研究一下。 但是我并不知道其目录，搜索了对应操作系统的常规目录中并没有。因为发现 redis 是原来的系统管理员自己编译安装的。如果我尝试自己找到它。 1）查看 redis.conf 中 dump.rdb 的目录并没有特别配置，也就是在应用运行的当前目录。所以可以先找出对应进程的当前目录，然后查找 。 2）lsof 可以列出对应进程所打开的所有文件。所以有可能有 dump.rdb

1. ps -A |grep redis 得到如下输出.

   45000 ? 10-09:36:27 redis-server 其实其进程 ID 是 45000, 进程名是 redis-server

2. lsof -p 45000 > rf.log 打开文件并没有找到 dump.rdb 的影子，不过有进程的当前目录的信息。

COMMAND     PID USER   FD      TYPE     DEVICE  SIZE/OFF    NODE NAME
redis-ser 45000 root  cwd       DIR      202,2      4096 1058338 /root/path/redis-3.0.4

然后果然在 /root/path/redis-3.0.4 下找到了对应的 dump.rdb 文件。

Share

本周先分享一下我写的篇讲 Vim 的文章 Vim 精粹：文本对象： 从 1 到 N

[wsdjeg]

顺藤摸瓜，从 v2ex 到这里，写的不错。