PlayStation 4 Pro

最近买了个美版 PS4 pro 。其实本来打算是买回给老家的一台新买的 4K + HDR 电视机配的,要不然按照国内的内容源缺乏程度, 4K + HDR 就是个摆设而已。

当然先是寄到了自己广州这边,然而玩了几天 The Last Of Us 之后,我有点喜欢这个游戏机了(挖鼻孔)。于是这几天不跑步,不运动,晚上和周末花了一点时间把它通关了。然而看着已经买了的好多个其它正在下载的游戏,更加觉得自己可以重新开始宅了。。。

以前不太理解有些人为什么会话这么多钱买游戏玩,(PC 游戏盗版一大堆在那里呢),然而有了个游戏机后才发现,它的优点——省心(不用为系统配置操心)确实是最大的卖点。作为一个玩具,它能让人纯粹的从中找到乐趣,不用再关心其它事情,这就是最好的了。

如何正确的引导用户设置好的密码

  1. 可以强迫用户输入密码的长度最小为 N 位。
  2. 不要强迫用户必须输入数字、字母、特殊符号的组合。因为过于复杂的密码用户自己都记不住几个,只能重复的使用常用的几个密码组合,或者是写下来在某个地方,结果是被别人偷看、盗走。
  3. 支付密码,只用数字就可以了,不要强迫用户必须输入其它字母或者符号。用户也许不会天天都用你的 app 进行支付,同样,再说一遍,过于复杂的密码很容易忘记。因为这个密码本身已经有登陆密码的保护了,可以做的一个限制是输错 N 次之后,暂时冻结支付或者要求进入恢复支付密码的步骤。
  4. 让你的登录表单对密码管理器友好。有些登录表格会蓄意不让浏览器记住密码,然而实际上,让浏览器自动保存和填写密码是更好的办法,这样用户可以随机生成密码填进去就完事了。而当密码管理器无法记住密码的时候,用户同样也只能从自己脑海里面的常用密码选一个出来使用,最终的结果是导致用户在不同网站用了相同的密码。
  5. 如果用户选择了记住登录状态,就不要动不动隔了一两天没登陆就把用户登录状态取消了。这点在很多 app 上面非常常见,然而,在使用了随机密码的情况下,输入密码其实是个痛苦的过程。同时,这也是个高风险的过程,因为容易被偷看和监听,尤其是国内这么多网站都还没有部署 HTTPS 的情况下。

Windows 的退化

Windows 本来是优秀应用软件的集中地,尤其是以微软自己的应用程序为代表,这些软件基本很少崩溃,响应迅速,性能非常好。

然而到了 modern apps/UWP 时代之后,这一切都在退化。

已经说不清是多少次被 Windows 10 上面的 UWP 应用的闪退、崩溃给弄到吐血了(其中很多都是微软自己的应用)。并且, UWP 的问题不仅仅是闪退,它的性能也远远不如传统的 Windows 应用,比如:它的启动实在太慢。

我完全不知道 UWP 是否是个好的应用平台,不知道是否是开发者的低能导致的问题。然而这些都不重要。Windows 需要的成功,靠这么烂的软件(平台)质量是只能走向死路的。

Chrome vs. Backspace

Hacker News 上面出现了一个讨论(https://news.ycombinator.com/item?id=11729287),是关于 Google Chrome 去除了将 Backspace 键作为回退到上一个页面的快捷键功能。
我很惊讶很多人在回帖里面对 Chrome 开发者的这一决定表示支持,因为:

  1. 我自己是个 backspace 键的重度用户。我尽量都是在用键盘快捷键在导航,除了 backspace,还有 Ctrl+w,f5,f6 。。。没兴趣从以前的 backspace 切换为两只手才能操作的 Ctrl+左方向键。
  2. backspace 并不是很多人说的那么小众的导航键。相反,把它作为回退上页的功能来用的例子非常多,比如在 Windows 平台,File Explorer 里面也是可以用它回退到上一页面的。
  3. Google Chrome 得了 Apple 的病。一直以来我都觉得 Chrome 其实更像是个 Apple 弄出来的浏览器,标榜着自己比用户更懂一切。而我不想被当作傻瓜。

我觉得我还是继续用 Firefox 吧

HEVC/H.265

仔细想了想,最近一年的时间里,对我的生活改善最为明显的技术是——HEVC/H.265 编码的视频。

现阶段唯一的缺陷是硬件解码的支持并不广泛,Intel 也只有从 Skylake 才开始支持 HEVC/H.265 的硬件编码、解码,不过也只是 8-bit 色深的,10-bit 的基本没有效果,仍然只能靠软解码,吃 CPU。就拿手头的 Intel NUC6I5SYH 来说,它的 CPU —— Core i5-6260U 碰到 HEVC 10-bit 的 4K 视频文件,是无法流畅播放的。(这是当然的,其实笔记本的 i7-4700HQ 都没法流畅播放的,基本没试过其它什么场景能把 CPU 负载跑到这么高的。)

不是说一定要看 10-bit 而不是 8-bit 的视频文件,只不过多数能找到的片源都是 10-bit 的了。

Fxxk HHVM

hhvm 大概是我见过的稳定性最差的开源软件之一了,也不知道这项目到底有没有QA的,反正我是碰到过很多次一更新,这破东西就挂了,起不来

nginx 直接向 logstash 发送 JSON 格式日志

通过 nginx 的 log_format 指令可以很容易直接就在 nginx 这里就生成(几乎是)JSON 格式的消息发送到 logstash

log_format  logstash '{"@timestamp":"$time_iso8601",'
                     '"@version":"1",'
                     '"host":"$server_addr",'
                     '"client":"$remote_addr",'
                     '"size":$body_bytes_sent,'
                     '"domain":"$host",'
                     '"method":"$request_method",'
                     '"url":"$uri",'
                     '"status":"$status",' # status 有可能会是以0开头,比如“009”这样的状态码,因此不能以数值形式保存,需要加括号存为字符串
                     '"referer":"$http_referer",'
                     '"user_agent":"$http_user_agent",'
                     '"real_ip":"$http_x_real_ip",'
                     '"forwarded_for":"$http_x_forwarded_for",'
                     '"responsetime":$request_time,'
                     '"upstream":"$upstream_addr",'
                     '"upstream_response_time":"$upstream_response_time",'
                     '"cache_fetch":"$srcache_fetch_status",' # 统计srcahe缓存命中率
                     '"cache_store":"$srcache_store_status"}';

但是这个还是会有问题,因为中文字符编码的原因,有时候 url 或者 referer 头里面可能会出现”\x”这样的跳脱字符,导致 JSON 解析失败,这个时候需要在 logstash 的 filter 里面再加上配置

filter {
  if [type] == "nginx-access-syslog" {
    mutate {
      gsub => [
        # replace '\x' with '\\x', or json parser will fail
        "message", "\\x", "\\\\x"
      ]
    }
  }
}

把”\x”替换为”\\x”。(这个方法不通用,只对”\x”做了处理,但一般应该也只有”\x”会出现了。。。)
然后我们可以用 kibana 画图了,以上收集的参数还算比较丰富了,可以做出很不错的 dashboard 了

Android 系统更新,愿你一直这么蠢下去

最近 Android 6.0 版本发布了,而我正好有一个Nexus 7 2013,但我却还无法更新它的系统,因为 Google 的傻逼 OTA 更新方式,服务器那头拒绝给我检测到更新。

这当然不是我第一次遇到这种情况了,以前的每次系统更新也是一样,Android 升级的主动权完全不由用户掌握。

Android 系统更新本来就是个老大难的问题,但我实在想不出 Google 的人是怎么想的,就算是官方支持的设备其实也无法及时更新到最新版本的系统。

  • 如果 Google 是想采用灰度发布,那么其实根本就不应该发布。这么做只不过是先拿一部分用户直接来当小白鼠来测试你的系统而已,所有用户的设备都该被当成重要的,你应该事先完全测试好。
  • 如果 Google 是因为服务器带宽资源不足够以立即对所有用户分发,我其实不太相信这种原因。
  • 为甚么不提供方式让用户自己使用其它方式下载安装包手动更新

以上,Apple 实在做得比 Google 好得多,新版本发布后可以立即更新,无论是 OTA 还是自己本地下载更新。