We learn from history that we do not learn from history.

We learn from history that we do not learn from history.

黑格尔

Defining arrow functions at a wrong place caused *this* object becoming undefined.

Today I was caught by a bug. I got an error message like "Uncaught (in promise) TypeError: Cannot set property 'users' of undefined" in the following code:

    import axios from 'axios';
    export default {
      name: "Users",
      data() {
          return {
            users: null
          };
      },
      created: () =>  {
        axios
          .get('https://jsonplaceholder.typicode.com/users')
          .then(res => {
            this.users = res.data;
          })
      }
    }

Finally, I figured it out by changing the created method definition from an arrow function to a normal function, the following is the correct code:

    import axios from 'axios';
    export default {
      name: "Users",
      data() {
          return {
            users: null
          };
      },
      created() {
        axios
          .get('https://jsonplaceholder.typicode.com/users')
          .then(res => {
            this.users = res.data;
          })
      }
    }

Do you see the difference?

Programming Tips on 01-04-2020

  1. safely convert Unix TimeStamp to string : 
DateTimeOffset.UtcNow.ToUnixTimeSeconds().ToString(CultureInfo.InvariantCulture.NumberFormat)

source

  1. DI with parameters in constructor 
services.AddScoped<SmsSentLogRepo>(s => new SmsSentLogRepo(Configuration.GetConnectionString("sms")));
  1. You should use ConfigureAwait(false) in your library code. source

观影老电影《牧马人》

今晚一家人一起看了个老电影。那个年代的电影，意识形态的东西自然是少不了的。不过我的看点在那些东西之外。如果我是剧中的主角许灵均，我会随亿万富翁的父亲远走高飞吗？不好说。

电影除了讲故事，也无意间充当了那个年代风俗人情的不精确的记录员。精确的记录不好看，不精确不是bug，是feature，哈哈。这也是我喜欢看老电影的原因之一。

要说剧中哪个人物我最喜欢，当然是这个影片中的女主角啦，漂亮又大方，勤劳能干，还学习上进，完美的不像真的。

与Eric一起看电影

客户端 POST 错误，服务端应该回 200 还是 400？

刚好今天和一个同事在这个问题上意见不一。

于是翻到了知乎上的这个问题，遗憾的是下面的答案都很水，没有一个深得我心。这很有可能证明我的看法是片面的，管它呢。但它激起了我的表达欲望，我于是键盘侠了下面这一篇。刚好傻子知乎嫌弃我没有认证国内手机号，不让我发表。那我就给自己的 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也只会降低用户的体验而不是改善用户的体验。因为最终用户大部分时候都只能知道错了，但不知道错在哪里。

当然是很个人的看法，欢迎任意批判。