DateTimeOffset.UtcNow.ToUnixTimeSeconds().ToString(CultureInfo.InvariantCulture.NumberFormat)
services.AddScoped<SmsSentLogRepo>(s => new SmsSentLogRepo(Configuration.GetConnectionString("sms")));
今晚一家人一起看了个老电影。那个年代的电影，意识形态的东西自然是少不了的。不过我的看点在那些东西之外。如果我是剧中的主角许灵均，我会随亿万富翁的父亲远走高飞吗？不好说。
电影除了讲故事，也无意间充当了那个年代风俗人情的不精确的记录员。精确的记录不好看，不精确不是bug，是feature，哈哈。这也是我喜欢看老电影的原因之一。
要说剧中哪个人物我最喜欢，当然是这个影片中的女主角啦，漂亮又大方，勤劳能干，还学习上进，完美的不像真的。
与Eric一起看电影
刚好今天和一个同事在这个问题上意见不一。
于是翻到了知乎上的这个问题，遗憾的是下面的答案都很水，没有一个深得我心。这很有可能证明我的看法是片面的，管它呢。但它激起了我的表达欲望，我于是键盘侠了下面这一篇。刚好傻子知乎嫌弃我没有认证国内手机号，不让我发表。那我就给自己的 Blog 添块砖吧。
其实这个标题蛮误导人。Post 错误....这种表述再宽泛了。因此有人支持有人反对都不奇怪。多么 Bad 的 Request 算Post错误？每个人有每个人的出发点，这太难达成一致了。
我的观点缩成一句话，只要请求使用 Api 协议（参数个数类型都）正确，我接受甚至有点喜欢响应 200 OK 再给出具体的 ErrorCode 和 ErrorMessage 这种做法。 既然请求能抵达你的 Action 处理方法，至少说明发起请求的一方是有一点点诚意的。如果你再有一点点时间，即使请求不是十全十美，给个不等于0的ErrorCode和一个合理的ErrorMessage是一种绅士的做法。
如果请求格式合法，服务器能够理解，但不能给出满意的结果，或者说 errorCode 不是0的情况，我个人的实践的是返回 200，并给出具体的错误码和错误信息。理由是这个请求不是无效的和非法的，直接扔400 是给前端增加工作量。
即使现在在的框架已经内置了 NotFound() 之类的快捷响应办法， 但只要Route正确到达了我的处理方法，而我又不想偷懒，我的观点也是应尽量给出人类能够理解的出错信息。你总不能因为商品暂时缺货就直接甩404吧！
我不赞成甚至讨厌那些把2xx - 5xx那几十个code 一个个或合理或牵强附会的对号入座，毕竟发明大部分这些Code 的时候还根本没有 Restful 概念。它们都过于宽泛了，是给喜欢偷懒和甩锅的程序员们准备的。即使你使用的前端框架能够自动帮你处理这些code，广泛而大量的使用这些code也只会降低用户的体验而不是改善用户的体验。因为最终用户大部分时候都只能知道错了，但不知道错在哪里。
当然是很个人的看法，欢迎任意批判。
I watched the English version of this famous movie this evening with Eric. It's so impressive. We should watch more good films in our remain life.
微生物的力量
它们不知世上有人，却能够深深改变人类世界。