就说你真实的想法啊，如果和 HR 想的不一致，所谓道不同不相为谋，正好走人避免日后麻烦

列一个单子至少把银行名字列出来，这样家人好拿着公证书去银行要钱

dawn of the dead, 虽然有点老，但看了不少次还是很好看
world war z
28 days later
28 weeks later, 这个是上面的续集

这种小众需求为什么要实现？有 app 就可以了

据说是搭载 7.1 的系统，基本也就是 7.0 的 bug 修复版

你能看到明文不代表是明文保存的好吗？

这么重要敏感的软件，不管是不是国产，你们都需要有理有据说服用户你们的软件可信。就算一个国外大厂的软件，本身质量不行，也会被人喷死的

猫 5,6 天绝对没问题，狗肯定就不行了。反正猫喜欢独来独往，到处溜达，粮食准备充足，猫砂多弄点就行

放屁有什么好评价的，谁不会放屁？

产品开发 =/= 敲代码

@ZGLHHH 不是，官方文档写的很清楚

app/Exceptions/Handler.php

https://laravel.com/docs/5.2/errors#the-exception-handler

@ZGLHHH QueryException 是通用 exception, 应该放到全局的 exception handler 里面。不然你每执行一次 query 都要 catch 然后 handle 一遍不是要累死。。。

你这最常见的应该是 ModelNotFoundException

https://laracasts.com/discuss/channels/tips/a-list-of-most-common-laravel-errors-exceptions

User::where('verify', 1)->count();

更优雅的是用 scope, 在 User model 里面加下面 method

public function scopeVerified($query)
{
return $query->where('verify', 1);
}

然后 User::verified()->count();

咋远程唤醒的，唤醒的时候念咒语了么？

"WRITE locks normally have higher priority than READ locks to ensure that updates are processed as soon as possible. This means that if one session obtains a READ lock and then another session requests a WRITE lock, subsequent READ lock requests wait until the session that requested the WRITE lock has obtained the lock and released it.

LOCK TABLES acquires locks as follows:

1.Sort all tables to be locked in an internally defined order. From the user standpoint, this order is undefined.

2.If a table is to be locked with a read and a write lock, put the write lock request before the read lock request.

3.Lock one table at a time until the session gets all locks."

既然开源了，还是 MIT 协议，别人拿去盈利了你不是应该感到高兴么？你的代码给了别人饭碗，做出了实际的贡献，这点度量都没有，开源的目的又是什么？