需要给每个user添加一个leader, 于是在user表里添加leader, 而leader也是一个user, 于是构成了自引用。

1
2
3
4
5
6
7
8
9
10
11

class User(db.Model):
    __tablename__ = 'users'
    id = db.Column(Integer, primary_key=True)
    name = db.Column(String(10))
    addresses = relationship("Address", back_populates="user")
    leader_id = db.Column(Integer, ForeignKey('users.id'))
    users = relationship("User", back_populates="leader")
    leader = relationship("User", back_populates="users", remote_side=[id])

    def __repr__(self):
        return u'<user id={0}, name={1}>'.format(self.id, self.name).encode('utf-8')

提示如下错误，

ArgumentError: User.users and back-reference User.leader are both of the same direction symbol(‘MANYTOONE’). Did you mean to set remote_side on the many-to-one side ?

最后参考StackOverFlow上One to one self relationship in SQLAlchemy和SQLAlchemy One-to-Many relationship on single table inheritance - declarative
添加remote_side解决问题.

backref和back_populates在表示两个表之间的关系时，很有用。

查看backref的文档，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class User(db.Model):
    __tablename__ = 'users'
    id = db.Column(Integer, primary_key=True)
    name = db.Column(String(10))
    addresses = relationship("Address", backref="user")

    def __repr__(self):
        return u'<user id={0}, name={1}>'.format(self.id, self.name).encode('utf-8')


class Address(db.Model):
    __tablename__ = 'addresses'
    id = db.Column(Integer, primary_key=True)
    email = db.Column(String(64))
    user_id = db.Column(Integer, ForeignKey('users.id'))

    def __repr__(self):
        return '<address id={0}, email={1} user_id={2}>'.format(self.id, self.email, self.user_id)

之后在命令行中，可以得到如下结果

1
2
3
4
5
6
7
8
9
10
11
12

>>> u = User(name='Bob')
>>> db.session.add(u)
>>> db.session.commit()
>>> u.addresses
[]
>>> a = Address(email='bob@163.com', user_id=u.id)
>>> db.session.add(a)
>>> db.session.commit()
>>> u.addresses
[<address id=2, email=bob@163.com user_id=2>]
>>> a.user
<user id=2, name=Bob>

即通过u.addresses可以访问到用户的addresses, 而a.user可以访问到用户。注意到u.addresses返回的是列表，而a.user返回的是单个元素，即User与Address是一对多的关系。

也可以使用back_populates实现相同的功能，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class User(db.Model):
    __tablename__ = 'users'
    id = db.Column(Integer, primary_key=True)
    name = db.Column(String(10))
    addresses = relationship("Address", back_populates = "user")

    def __repr__(self):
        return u'<user id={0}, name={1}>'.format(self.id, self.name).encode('utf-8')


class Address(db.Model):
    __tablename__ = 'addresses'
    id = db.Column(Integer, primary_key=True)
    email = db.Column(String(64))
    user_id = db.Column(Integer, ForeignKey('users.id'))
    user = relationship("User", back_populates="addresses")

    def __repr__(self):
        return '<address id={0}, email={1} user_id={2}>'.format(self.id, self.email, self.user_id)

在交互环境中，得到如下结果

1
2
3
4
5
6
7
8
9
10
11
12
13

>>> u = User(name='Clack')
>>> db.session.add(u)
>>> db.session.commit()
>>> u.addresses
[]
>>> a = Address(emial='Clack@163.com', user_id=u.id)
>>> a = Address(email='Clack@163.com', user_id=u.id)
>>> db.session.add(a)
>>> db.session.commit()
>>> u.addresses
[<address id=3, email=Clack@163.com user_id=3>]
>>> a.user
<user id=3, name=Clack>

从文档中得知，back_populates是用来取代backref的，虽然backref也是一直支持使用。倾向于使用back_populates, 因为它比backref更直接明了。

最近做前端开发，发现Chrome开发者工具真是前端开发的一大利器。这里做个简单记录。

Chrome在Mac上, 可以使用快捷键Option + Command + I打开开发者工具。查看源码是Option + Command + U。

Network标签下，有一个XHR请求，XHR代表XMLHttpRequest，所以简单来说，就是AJAX请求。

Chrome的一大功能是可以修改Javascript文件中的代码，保存后就可以生效。这是一个非常有用的功能，在表单提交时，如果Javascript出错，一般来说是去修改源文件，然后重新加载，然后填入表单字段，重新提交。这种方式，需要反复填入表单，如果表单字段很多，则非常麻烦。有了Chrome这个功能后，直接修改source标签下的Javascript文件，保存后即可生效，然后就可以提交，这样非常方便。

需要注意的是，修改source下的js文件，并不会修改源代码，调试完成后，还需要将修改同步到源文件中。

参考资料

• AJAX - 向服务器发送请求
• 使用 Chrome 开发者工具进行 JavaScript 问题定位与调试
• 前端开发神一样的工具chrome调试技巧

日志是程序员的生命线，在Python中使用logging来记录日志。之前写过Django配置logging, 这次在Flask里配置日志。查看Flask日志配置文档, 最后在一个日志等级上遇到问题。

给创建app时，添加日志配置

1
2
3
4
5
6
7

file_handler = RotatingFileHandler("lovehate.log")
file_handler.setLevel(logging.WARNING)
file_handler.setFormatter(Formatter(
    '%(asctime)s %(levelname)s: %(message)s '
        '[in %(pathname)s:%(lineno)d]'
    ))
app.logger.addHandler(file_handler)

之后使用app.logger.info输出日志，日志只在终端中显示，没有写到文件中。百思不得其解，叫同事过来看看，才发现是日志等级的原因。

以前一直认为INFO的等级比WARNING更高，所以一直认为上面的配置，应该会输出日志。后来看了文档才知道日志等级从高到低是DEBUG, INFO, WARNING, ERROR, CRITICAL。或许这还是不合理的，WARNING应该比INFO低才对啊。

Zabbix作为一款老牌监控，在服务器规模还不是很大时很有用。

安装Zabbix有很多种方式，这里使用rpm方式安装。因为服务器是CentOS 32位的，所以选择下面的rpm包，相应的包可以在阿里云上找到。rpm -ivh http://mirrors.aliyun.com/zabbix/zabbix/3.0/rhel/6/i386/zabbix-release-3.0-1.el6.noarch.rpm, 具体安装见参考资料。

参考资料

• Zabbix官方文档
• 自动化监控Zabbix安装部署之Server端部署
• 自动化监控Zabbix安装部署之agent端部署
• Zabbix使用实践

可迭代的和迭代器是两个经常容易混淆的概念，这里说说这两个概念

iterable可迭代的">iterable可迭代的

任何调用iter函数可以获得一个迭代器的都是可迭代的。实现__iter__方法，返回一个迭代器的对象是可迭代的；序列是可迭代的，因为它们实现了__getitem__方法。

iter函数执行时会做如下操作

1. 检查一个对象是否实现了__iter__, 从其中获得一个迭代器
2. 如果没有实现__iter__方法，查看是否实现__getitem__方法，从中创建一个迭代器，从0开始获取每一个元素。正是因为这一点，序列是可迭代的
3. 如果都失败，抛出异常，对象是不可迭代的。

当需要自己实现的迭代对象时，需要实现__iter__方法，因为从__getitem__中创建迭代器是为了向后兼容，未来也许会被废弃。

iterator迭代器">iterator迭代器

任何实现无参next方法，每次返回一个元素，当没有更多元素时，返回StopIteration异常的对象，都是迭代器。迭代器也实现了iter方法，所以也是可迭代的。也就是迭代器提供了访问可迭代对象的接口，用户不需要知道其内部实现。

把可迭代对象变成一个迭代器是一个坏主意

迭代器模式的用途主要是

1. 访问一个聚合对象的内容而无需暴露它的内部表示；
2. 支持多次遍历聚合对象
3. 为遍历不同的聚合结构提供一个统一的接口，即支持多态迭代。

为了支持多次遍历，调用iter函数时，需要返回一个全新的迭代器。如果可迭代器对象变成一个迭代器，那么它将返回原先的迭代器，它将只支持一次遍历。

在《Fluent Python》里看到Why len is not method，有些困惑，于是开始找答案。

在Python词汇表里，对函数和方法有如下说明
function: A series of statements which returns some value to a caller. It can also be passed zero or more arguments which may be used in the execution of the body.

method: A function which is defined inside a class body. If called as an attribute of an instance of that class, the method will get the instance object as its first argument (which is usually called self).

简单来说，就是函数在类里定义就叫方法。所以这里len是一个函数，而不是方法。那么问题是，为什么不把len做成方法，像list.len() str.len()这样呢？

在What makes Python so AWESOME里《Fluent Python》的作者Luciano Ramalho向Raymond Hettinger提了这个问题，Raymond Hettinger说是因为”practicality beats purity”, 因为把len做成一个函数更加直观和符合直觉。

实际实现时，len函数对于内置类型，会去C底层实现的结构体里取一个字段值，这个字段值记录了长度。而对于用户自定义类型，用户实现len方法的话，len函数会去调用len方法。

因为新公司要使用Flask开发，于是需要熟悉它。找到《Flask Web Developmen》这本书，于是开始学习使用Flask编写Web站点。

想到把之前用Django开发的站点，爱与生的苦恼还不够完善，于是决定用Flask重写。之所以叫爱与生的苦恼，是因为之前看过叔本华写的《爱与生的苦恼》。想想每个人很多时候都是在爱与恨中度过，就像我喜欢跑步，囚徒健身，现代牧业，旭辉控股，莱尔斯丹等等，讨厌工商银行，赌博，垄断，Windows命令行等等。于是我想把它记下来，也可以看看自己喜欢与讨厌的变化。或许随着时间的推移，自己会变得更加宽容，更加开放。也许那个时候，不在讨厌工商银行，Windows命令行也是有可能的。记微信朋友圈显得有些杂乱，于是干脆记在自己写的网站里。

《Flask Web Development》的作者Miguel Grinberg显然具有多年开发经验，将Web开发需要注意的地方，通过一个完整的博客应用娓娓道来，令人倾佩。许多代码稍作更改，就可以用在自己的站点中，大呼过瘾。如果要学习Flask开发，极力推荐看看这本书。

相比于Django, Flask显得更加轻量。没有了Django的admin，但好在应用比较简单，写个简单的后台没有什么问题。基本上Django里有的功能，Flask都能找到合适替代品。整个开发过程还是很顺畅的，唯一不好的一点是Flask的migrate功能有问题，当使用SQLite做数据库时，自动生成的SQL语句会出问题，主要是SQLite不支持Alter字段。

刚开始时，访问速度很慢，因为显示的都是原始图片，动不动就是10M，用户体验不是很好。曾考虑过使用七牛图床，只是这样增加了开发成本，而且需要把照片寄存在第三方应用中，好处是图片清晰。考虑之后，还是决定使用Pillow模块进行图片裁剪，目前来看，效果还不错。

之后添加了粉丝，评论功能这些社交元素。除了界面显示效果略差，整体效果还算满意。

站点地址可移步爱与生的苦恼, 欢迎在此记录爱与生的苦恼。

这是一道关于元组+=赋值的谜题, 据说，能答对这道题的都是Python老司机。 请在不执行下面的代码的情况下，回答这个问题

1
2
3
4
5
6
7

>>> t = (1,2,[30,40])
>>> t[2] += [50, 60]
会发生什么, 选择最佳答案:
a) t变成(1, 2, [30, 40, 50, 60])
b 抛出TypeError, 'tuple' object does not support item assignment异常，即元祖对象不支持赋值
c) 上面两种情况都没有发生.
d) a 和 b都发生

看到这题时，第一反应是b。之后使用dis模块查看执行语句, 得到

1
2
3
4
5
6
7
8
9
10
11
12
13

>>> dis.dis("t[2] += [50, 60]")
  1           0 LOAD_NAME                0 (t)
              3 LOAD_CONST               0 (2)
              6 DUP_TOP_TWO
              7 BINARY_SUBSCR
              8 LOAD_CONST               1 (50)
             11 LOAD_CONST               2 (60)
             14 BUILD_LIST               2
             17 INPLACE_ADD
             18 ROT_THREE
             19 STORE_SUBSCR
             20 LOAD_CONST               3 (None)
             23 RETURN_VALUE

可以看到第17条的INPLACE_ADD操作，因为列表是可变对象，所以这条会执行成功。之后第19条进行保存，而元祖是不可变对象，所以第19条会报错。

所以答案是d, 即a和b都发生了。

在Python词汇表里对，可哈希的有这样一段说明:

An object is hashable if it has a hash value which never changes during its lifetime (it needs a hash() method), and can be compared to other objects (it needs an eq() method). Hashable objects which compare equal must have the same hash value.

也就是说，一个对象的哈希值(实现hash方法)在对象的生命周期里永远不变的，这个对象可以与其它对象进行比较(实现eq方法), 相等的对象哈希值一定相等，那么这个对象就是可哈希的。

也就是说，可哈希对象必须满足下面三个条件

1. 支持hash函数，也就是实现hash方法。这个方法的返回值在对象的生命周期里永远不变
2. 支持相等判断，也就是实现eq方法
3. 如果a == b, 那么hash(a)一定等于hash(b)，也就是相等的对象，哈希值一定相等。

这里不明白的是第三点，也就是为什么两个对象相等，哈希值一定要相等，不相等难道不行吗？

下面编写的一个测试类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

class UnHashable(object):
    """
    >>> a = UnHashable(3)
    >>> b = UnHashable(3)
    >>> a == b
    True
    """
    def __init__(self, x):
        self.x = x

    def __eq__(self, other):
        return self.x == other.x

    def __hash__(self):
        import random
        return hash("{} {}".format(self.x, random.random()))

如果我们执行

1
2
3
4

d = dict()
a = UnHashable(3)
b = UnHashable(3)
d[a] = 4

之后我们会希望d[b]返回4，但是并不会如此，因为hash[a]并不一定等于hash[b]. 这就是为什么要求可哈希对象一定要a == b时，hash(a) == hash(b)

在Python中，对于内置不可变对象，都是可哈希的，而字典和列表等可变对象不是可哈希的。