因为 StackOverflow 的审核大量依赖用户，而相比搜索答案，答题占的比例很少，然后相比答题，审核的比例更少（首先，审核需要积分够到门槛，而够到门槛的人，也不一定会花很多时间审核——其中一部分人比较忙，另外一般来说，答题要比审核有意思）。这就导致 StackOverflow 经常会让高积分用户去审核他不熟悉的内容——这就可能带来问题。

新用户在 StackOverflow 上看到一个简单问题，可能会随手回答，因为觉得问题太简单，可能就回答一两句话。然后，审核答案的人，如果不熟悉这方面的内容很大可能是看不懂这样的简短回答的，再一看回答的人又是一个分数低的新用户，可能就会把这个”劣质“回答干掉。碰到这样的情况，这些新用户当然会觉得不友好了。

@wangxiaoaer 但是换 vue 也有成本的呀。而且换了后又碰到类似问题怎么办？再换别的？

@raysonx 但是有的人并不知道 app 取自 application 的前三个，所以不能拆开读，读成 A-P-P 也不影响沟通。其实还是因为生活中这个词用的少，很多人没听过。像 iPhone 这样的词，即使不会英语的人也会念成“爱疯”或者“苹果”，我从没听人念成 I-P-H-O-N-E。

穷得女装都买不起，哪有钱买西装啊？

规范写成文档，工作任务用 ticket 写清楚。

@snoopy1024 v 站本来就有设计、设计师、字体排印节点啊。

> 早 9 晚 6
> 20:00 以前能完成的工作尽量在正常工作时间内完成，加班到 20:00 以后开始计算加班

那不是说，其实你早 11 晚 8 也不会让公司多出钱？早 11 应该爬得起吧。

@agdhole 这就是三元啊，只不过和大多数语言的三元的顺序不大一样而已。

@liyoubin37 直觉上，has_data 的值应该是 True 和 False，而不是 0 或 1，这种写法是利用了 Python 的布尔值和整数值之间的隐式转换，我不喜欢。而且习惯上，has_data，正常的思路，是先写有数据的情况，再写没数据的情况，而这种写法还要颠倒一下，看起来很别扭。

这种写法更适合条件本来就是整数的情况（因为 python 里没有 switch ... case 语句）。

像 @monkeylyf 指出的，第二种写法不能让人一眼看出来，这两个变量的取值都取决于`has_data`，所以第二种写法不好，第一种好。

如果偏爱第二种的风格，那得这样写：

calculate_func, task_id = ("rollback", sql_data.get("task_id", "")) if has_data else ("calculate", sin_id)

其实我个人是喜欢第二种风格的，并不像 @xpresslink 说的“本质上是一样的”，第二种写法，可以确保你不会无意中遗漏 else 的情况——像 Haskell 和 OCaml 等一堆函数语言里，if then else 都是第二种写法。

但是 python 这个东西就和 lambda 一样，都是设计来让你写很短的东西的。设想一下，以后可能需求变动，不止一个条件判断，不止赋值两个变量，第一种写法可以很方便地加 elif，可以很方便地多加几行赋值语句。而第二种写法呢？当然，可以啦，条件判断嵌套，元组可以加元素，但是这么搞，可读性会很差。

所以鉴于 python 的设计限制，虽然我喜欢第二种写法，但我还是会用第一种写法。

@mrzx 有段时间 ofo 小程序充值金额只能选几个固定值，最低的是 100

@Fezl 摩拜也可以卸载，用微信小程序。以前摩拜 app 有手动输入车号的功能，小程序没有，可以应对部分二维码损毁的车。现在摩拜小程序支持蓝牙开锁了，app 没什么用了。

除了促进配件卖钱外我也想不到了——只不过不知道这算不算意义

除了比 MBP 轻二两外毫无优势。

担心下一波 MBP 升级会提价，强行给新 air 加上价格优势……

simplenote

这改个 master/slave 不痛不痒的。git 本身是侮辱人的话（饭桶、无用之人），应该换用 hg ;-)