电影《疾速追杀》

上周看了《疾速追杀》和《疾速特攻》,后者是前者的第二部。

情节比较老套:一个因爱退隐的职业杀手,在妻子病逝、黑道欺凌下,不得以奋起反击、与整个杀手行业为敌,最后善恶有报、空余萧索。

知道这部戏是因为和《极寒之城》是同一个导演,卖点都是暴力美学,风格不同。《极寒之城》用不加特效的长镜头表现格斗的残酷,画风冷峻。《疾速》系列更像《杀死比尔》,场面华丽,十步杀一人、千里不留行。

关于暴力美学,维基百科是这么解释的:

主要在官感上,使暴力以美学的方式呈现,诗意的画面,甚至幻想中的镜头来表现人性暴力面和暴力行为。观赏者本身往往惊叹于艺术化的表现形式,无法对内容产生具体的不舒适感。支持人士往往称「暴力程度与票房收入成正比」,社会道德捍卫者和舆论谴责人士则称其是对社会道德教化的阻碍和负面影响;恐引发心理未臻成熟的人们,间接以为暴力行为亦是一种美感的呈现。

在众多香港导演中,吴宇森是运用这种电影表现手法的代表性人物。其标志性的白鸽漫天飞舞,手持双枪的英雄人物纵横在屏幕之上,使象征和平和安详的白鸽与血腥暴力的枪弹形成了强烈的视觉反差,吸引了无数的目光。

然而我并不打算马上去看新《追捕》,炒冷饭的鲜有好戏,等等再说。

iPhone X使用感受

上手用了两天,感觉优点多于缺点,总体是进步的。

P1030587

如果没有新的工业设计,我可能会把小6继续用下去。毕竟当初就对小6的白带和粗边框很不满意,虽然8因为改回玻璃背板已经基本解决白带问题,但是前面板几乎没有变化,一个工业设计用了四代,再优秀也审美疲劳了,而且那个屏占比在现在的千元机里也是倒数了,哪怕把边框做得再窄一点,8也不至于跳水成现在这样。

P1030579

买的银色,实际观感更接近乳白色,而深空灰更接近黑色。后者配色的一体性并没有别人说的那么好,而前者配色也没有很强的割裂感。

P1030585

宽度比6稍大,长度更长,单手握持无压力,不过单手操作就别想了,即使是6,搭配指环单手操作也不方便。

P1030584

前面板在息屏状态下一体性很好。当然我不认为这是个很重要的标准,好像罗永浩说过黑色边框可以隐藏低成本的做工,白色边框想做好更难,不管真假,息屏美学就是个营销手段,有谁会盯著息屏的手机瞅?

功能方面,这次最大的卖点就是Face ID,体验真是比Touch ID好太多!尤其是我手汗多,指纹解锁失败率很高,不过这些年倒是因此养成了一天洗几十次手的习惯……

性能上,找回了6在iOS8时的流畅度。如果没有意外,6在iOS11下就现在这德性了,追求流畅度的在10.3.3止步吧。

拍照方面,「世界第二」的摄像头效果搭配人像模式效果比6好很多。

至于续航,虽然免不了一天一充,起码比6在iOS11下强多了,毕竟多了一千毫安。

此外,作为古老的小6的用户,3D Touch、抬手亮屏、随时喊Siri也有更好的体验。

屏幕方面,全面屏+OLED效果拔群。看久了X的屏幕,再看6的会觉得模糊很多。另外,True Tone比起Night Shift也更智能了。

异形屏不是苹果的首创,全面屏也不是小米的首创,而它们连同三星S8已然成了全面屏的三个流派。我个人更倾向于异形屏,虽然iPhone X的屏占比实际上并不是非常高,不过观感上更彻底。S8用曲面屏把左右边框做到视觉上宽度接近零,不过三星的供货问题是这个流派最大的障碍。至于小米MIX,完全就是在低成本、供应链和软件生态话语权弱、硬件技术落后等因素作用下、利用普通LCD面板追全面屏热度的怪胎。MIX1就是个半成品,到了MIX2才算基本可用。所以小米不是第一个做全面屏的,但是是第一个不要脸的,还是老罗实在,「全面屏」后面还加个「almost」。

未来一两年,从千元机到高端机会全面普及全面屏。中低端机型主流应该会选择坚果Pro2的风格,用普通面板,然后尽量把边框做窄。高端机型在异型屏和曲面屏之间会有一场好戏。

取消Home键换来的新的交互方式,整体上是进步了。回到主界面和切换任务这两个常用操作改用触摸手势,取消了到实体键的依赖,也提高了效率。侧边键得到了更充分的利用,呼出Siri和Apple Pay从Home键挪了过来。如果同时按侧边键+音量减能自定义或者实现像坚果Pro2闪念胶囊按键那样的功能会更好。

缺点主要是边框和厚度,原本我对小6的厚度是很满意的,只是希望把边框做窄点。现在不但祖传的粗边还在,还越做越厚是什么毛病?!

电影《极寒之城》

这是最近看的电影里让我印象最深的一部。

故事背景是1989年柏林墙倒塌前发生在德国的一场谍战。剧情组织得很一般,冷战和谍战这两个卖点做得都不成功,虽然塞隆和波多拉两位女神的床戏挽救了一切,但是女同的卖点只是一道开胃菜,最精彩的部分是中后段的一场动作戏,塞隆单挑一群克格勃,同时还要保护一个东德叛谍,长达数分钟的一个长镜头,场面极为真实,一改一般好莱坞动作片里打不死的风格。

读完《谈美》

fullsizeoutput_301

这本书讲的是「什么是美」。读完后对美有了一些基本的概念,才知道我的审美水平还停留在「以快感为美」的阶段。

朱自清的序里的一些话说得很好:「新文化是「外国的影响」,自然不错;但说一般青年不留余地地鄙弃旧的文学艺术,却非真理。」、「许多青年腻味了,索性一切不管,只抱著一条道理,「有文艺的嗜好就可以谈文艺」。这是「以不了了之」,究竟「谈」不出什么来。」

用Tiny Tiny RSS搭建私人阅读器的步骤

优势

  1. 自定义过滤器
  2. 全功能,无限制
  3. 利用已有VPS,无需额外费用

安装

安装并启动docker

1
2
3
4
curl https://get.docker.com/ | sh

// centos7
systemctl start docker

安装postgre

1
docker run -d --name ttrssdb nornagon/postgres

安装tiny tiny rss

1
docker run -d --link ttrssdb:db -p 80:80 -e SELF_URL_PATH=http://example.org/ttrss fischerman/docker-ttrss

example.org替换成VPS的IP或者对应的域名。

配置

配置主程序

访问http://example.org/ttrss,用户名admin,密码password

伪装成fever

如果RSS阅读器不支持ttrss,但支持fever,例如reeder,可以通过安装插件伪装成fever:

1
2
3
git clone https://github.com/rannen/tinytinyrss-fever-plugin.git

docker cp fever [[CONTAINER ID]]:/var/www/plugins

然后去设置见面启用fever插件,并在fever插件的配置栏设置单独的密码,该栏目中会显示在RSS阅读器中使用的接口地址,用户名就是admin

备份

每天凌晨3点备份数据库到dropbox。

下载dropbox上传脚本

在VPS的/root下执行:

1
wget https://raw.github.com/andreafabrizi/Dropbox-Uploader/master/dropbox_uploader.sh

执行命令并按提示操作:

1
./dropbox_uploader.sh info

创建备份脚本

创建/root/backup.sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#!/bin/bash

SCRIPT_DIR="/root"
NOW=$(date +"%Y%m%d")
TMP_PATH='/tmp'
DOCKER_ID_TTRSS='39cec6a7xcb7'
TTRSS_DB="$TMP_PATH/ttrss.sql"
BAK_FILE_NAME="vps-$NOW.tar.gz"
BAK_FILE="$TMP_PATH/$BAK_FILE_NAME"
DROPBOX_DIR=""

docker exec "$DOCKER_ID_TTRSS" /usr/bin/pg_dump ttrss > "$TTRSS_DB"
echo "数据库备份完成,打包网站数据中..."
tar cfzP "$BAK_FILE" "$TTRSS_DB"
echo "所有数据打包完成,准备上传..."
# 用脚本上传到dropbox
"$SCRIPT_DIR"/dropbox_uploader.sh upload "$BAK_FILE" "$DROPBOX_DIR/$BAK_FILE_NAME"
if [ $? -eq 0 ];then
echo "上传完成"
else
echo "上传失败,重新尝试"
fi

# 删除本地的临时文件
rm -f "$TTRSS_DB" "$BAK_FILE"

39cec6a7xcb7替换成实际的postgresql容器的ID。

创建定时任务

crontab -e里添加:

1
0 3 * * * /bin/bash /root/backup.sh > /dev/null
过度优化和过度设计

我见过两种程序员,一种是想做事的,一种是混饭吃的。

第一种人最容易犯两个错误,一是过度优化,二是过度设计。两种错误共同的原因是经验不足,不同的地方是过度优化往往出于知其然不知其所以然,而过度设计一般是想得太远从而脱离实际。

比如我见过的一个人,凡是联表的语句,都要拆开来写,完全不考虑这些联表语句实际会不会发生性能问题。这就是过度优化,只记住一些成例和范式,不从实际出发,胶柱鼓瑟,刻舟求剑。联表当然会造成数据量以笛卡尔积的形式增长,但如果所联表的数据量并不大,或者通过限制条件过滤后的数据量不大,并不会出现性能问题,而拆开SQL语句会导致代码量增大、可读性下降,是得不偿失的。

至于过度设计,我自己就是个很好的反面教材。刚工作的时候,我在写程序之前和过程中会不断地冒出新的想法,设想到很多种可能,为了照顾到这些可能性,我会不断地重构程序,导致出活很慢。多数人并不会认真了解别人,只是从结果上武断地下结论。所以关于我写程序太慢的说法就悄悄流传开,而那些程序写得很烂、混饭吃但出活很快的人反而获利颇丰。最可笑的是过了很长时间后回顾曾经设想到的可能性,几乎全部没有发生。为一些将来可能发生而实际没有发生的可能性,在一开始就花费更多的成本,这就是过度设计。

不过经验作为知识存量,是不值钱的,假以时间,有一定认知水平、不甘于庸俗的人总可以积累得到。所以相对于第二种人,我宁愿和第一种共事。

用gv.vim查看git提交历史

gv.vim是fugitive的插件,用于查看git提交历史,特点是速度快、好用。我现在用它做code review。

1
2
3
4
nnoremap <leader>gll :GV --no-merges<CR>
nnoremap <leader>glc :GV!<CR>
nnoremap <leader>gla :GV --no-merges --author<space>
nnoremap <leader>glg :GV --no-merges --grep<space>
解决phpqa和fugitive不兼容的问题

:Gstatus中查看diff时,报错:

Error detected while processing function Phpqa#PhpLint:
line 8:
E684: list index out of range: 0
E116: Invalid arguments for function match(l:php_list[0],”No syntax errors”) == -1
E15: Invalid expression: 0 != v:shell_error && match(l:php_list[0],”No syntax errors”) == -1

这是phpqa的bug,有人创建了PR,但作者没有合并,需要手工合并:

1
curl -L https://github.com/joonty/vim-phpqa/pull/43.patch | git am
读完《美的历程》

这是我读过的第一本美学书。梳理了中国文艺和审美发展的历史脉络,浅显易懂。

多读点美学还是很有必要的,能减少点俗气,那就最好了。