目测引战帖

@whyou126 嗯，但看起来半路丢件的可能性挺大

@dhairoot 这个不好说呢，分布式解压也得看你有多少资源可以被用起来，是有闲置的资源吗，还是解压速度已经够好了只是达不到心理预期？

挺好的，我刚卖了几本书给多抓鱼，他们可以提现，有的时候就是想卖钱，他们也鼓励用余额支付，能再打折。

如果你只是想解压这些 zip 文件的话，多开几个进程或者线程，和 CPU 个数差不多，一个个解压就挺快吧？当然如果有很多资源可用，确实可以搞分布式解压，就行 mapreduce 一样？

在家 fix bug

我司手写复杂 SQL，但也不至于连 insert into 也是手写，对数据库操作有简单封装，主要是对结果进行封装：获取一行、获取一列、获取某行的某列、执行任意 SQL，如果有特别需要 insert into 也是手写，不使用 ORM，这样很直观，心里有底吧。

对结果简单封装后用起来和 ORM 差不多，比如获取一个订单：

```python
purchase = db().get('SELECT * FROM purchase WHERE id=%(purchase_id)s', purchase_id=123)
print(purchase.shopper_id)
print(purchase.sales_channel_id)
```
等等读取操作和用 object 的感觉一样，但如果要更新 purchase 则需要写 SQL：
```
db().execute('UPDATE purchase SET processed_at=CURRENT_TIMESTAMP WHERE id=%(purchase_id)s', purchase_id=123)
```

获取一些订单：
purchases = db().list('SELECT * FROM purchase WHERE created_at>=CURRENT_DATE')
for purchase in purchases:
print(purchase.id)

获取订单某个字段：
shopper_id = db().get_scalar('SELECT shopper_id FROM purchase WHERE id=%(purchase_id)s', purchase_id=123)

获取订单 ids：
purchase_ids = db().list_scalar('SELECT id FROM purchase WHERE created_at>=CURRENT_DATE')


对数据库的变动写 migration 脚本，按顺序部署时应用到数据库中。

开发环境中模块对表的读写有管理，不是某个模块想写哪就写哪，想读谁就读谁，但这个在生产环境不检查。

觉得俄罗斯线路挺好，香港有时不稳定

这个没有谁对谁错，就是不一样的生活习惯，要么你妥协，要么你让对方按照你的习惯来，这个事还和其他事情不一样，没有明显的对错，你觉得这样挤牙膏好看，她可能不在在乎，就随便挤一下。

我曾经很不喜欢吃面条，但我老婆很喜欢吃，我想早晨吃面包，但我老婆从小很少吃面包所以也习惯不了，我花钱大手大脚，我老婆总是很节约……这些都没什么对错。

我现在每天早晨给她下面条吃，然后我可能前一天买上面包吃，我相信你总会有一天突然发现，自己已经变得不在乎牙膏是怎么挤的了。