「所有的故事都必将迎来终结。」
说起来我还从来没有在博客里写过ACG相关的东西,可能除了一两篇跟舰C相关的吧。毕竟本来这个博客应该是一个技术博客的(笑)。但是前天晚上 Amazon Prime Video 上线了《EVA新剧场版:终》,我还是想写点什么。
我的记忆中我小的时候是在电视上看过EVA的,虽然我当时不知道它的译名是《天鹰战士》,也完全不记得我在哪个频道看到的,而且不知道是什么原因,刻在我记忆里的片段跟后来我仔细看了正片以后注意到的片段似乎有一点对不上。我记得特别清楚的一个是插入栓,我当时应该是把它跟EVA的外接电源插头弄混淆了,一直以为那是插头,但是我很肯定的是里面有人并且充满了液体(后来才知道是LCL),而且有一个片段是有人用手打开插入栓的舱门救人(碇司令:有人Q我?)。另一个就是初号机生吃了三号机的名场面了,这东西真的是我的童年阴影之一,给我幼小的心灵留下了深深的震撼……
后来上了大学重新看起动画,终于完整的看了一遍旧TV和旧剧场版(EOE),以及《序》《破》《Q》三部新剧场版。总结起来就是一句话:我看不懂,但我深受震撼🤣。再后来补了一些设定、看了一些解析、读了一遍漫画,终于还是多多少少理解了旧 TV + EOE 想要讲的故事。但是新剧场版当时只出到《Q》,《Q》还又一个个的都是谜语人,看了以后完全不知道剧情是什么,就想等着看终,没想到一等就是七年。
EVA 有许许多多值得说的地方,比如设定、制作、人物塑造、以及痞子的报复社会行为等等,但是新剧场版是什么地方让我百看不厌呢?我首先能想到的就是痞子对于机械结构的执着以及对机械设定的考究。《序》里面美里带着真嗣看着夕阳下第三新东京市缓缓升上地面的镜头,以及第五使徒来袭的时候城市再次进入地下,被防御武器(多炮塔神教www)所替代的镜头简直就是我中二幻想的具现,这种整齐、巨大,精巧并且复杂的机械结构真的是太令我着迷了,试问哪个男孩能抵挡住这种诱惑呢?《序》中接下来的屋岛作战也是经典中的经典,详尽的工程机械刻画、电缆铺设的细节、成排的变压器运输镜头还有工作人员一本正经的各种汇报台词真的是中二度拉满。
「中二」就是我想说的第二点了,毕竟第一次看EVA的人大概都会觉得这是个普通少年驾驶巨大机器人拯救世界的故事吧(少年啊快去创造奇迹),虽然实际上不是,既不是普通少年,驾驶的也不是机器人,更没有拯救世界(好吧《终》里还是救了的),但是不妨碍EVA从头到尾的中二气息外漏。《破》中「把绫波……还回来!」的台词要是在现实中说出来真的是尬到原地爆炸,但是配合真嗣觉醒和初号机暴走锤爆第十使徒小力就是让我热血沸腾。在《Q》中抛出的太多谜团和剧情线大改导致观众和真嗣一样云里雾里一直吃瘪,导致这种中二感几乎没有了,我想这也是为什么《Q》没有前两部「好看」的原因之一吧。真嗣真的是从头到尾都是懵逼的状态(我也是),还眼看着爱人基友被字面意义上的爆头,一直自闭到《终》里也怪不得他。
EVA的暗线和设定从来都是藏着掖着的,这也是很多考据党的精神食粮。EVA是什么?Seele的计划是什么?碇司令的计划与之有什么区别?碇司令到底有没有计划?冲击的条件是什么,怎么突然就开始冲击了?Guf 之门又是什么鬼?很多问题我到现在都还没有搞明白。剧中人物说的话可能本来就是谎话,也可能是被谎话所欺骗,所以想要知道这些基本都要靠自己的眼睛和脑子了。看完了《终》,有的疑惑我以为被解开了,可是又多了更多的疑惑,本来我还想写写的,但是想来想去这已经有点像是在做语文阅读理解了,也许痞子自己对这些问题都没有很好的答案,而且结束就是结束了,感觉再去分析什么显得有点「空気が読めない」。
谈论EVA的时候人们总是提到上世纪90年代日本的社会背景以及EVA对当时迷茫的年轻人的内心刻画,独自反抗自己所不能理解的大人、社会、世界的无力感,没有希望,想要逃避的自闭感。我不在那个环境下成长,也几乎没有过「反抗世界」这种逆反的想法,也几乎不曾迷茫过,更没有过与世界「和解」,所以当人们说《终》没有「EVA那味儿」的时候,我是不怎么有切身的体会的。《Q》整体的压抑和故意的谜团渲染让我不喜,《终》里痞子大发慈悲先是花了几十分钟来描写一个末世中的世外桃源,想要传达生命、母性、包容、顽强得活下去等等的心情几乎溢出屏幕,我不得不承认也许EOE那种充满了绝望的故事更有艺术感甚至哲学感,但我还是更喜欢温柔的故事。
在最后各个角色依次「补完」,所有人都得到了救赎和拯救,碇司令跟话唠一样喋喋不休地说他有多需要唯的时候,我有一瞬间觉得痞子是真的老了累了,他不再是那个在作品中狠狠地讥讽报复观众的痞子了,也许他选择了与他的世界「和解」,他也不用再跟《EVA》这一部作品相爱相杀了。
是时候跟所有的EVA说再见了。
《终》里我最爱的一幕
]]>本文默认读者已经有一定的公有云平台/阿里云以及Linux系统和Docker使用经验,并且已经拥有可以部署云函数的阿里云账号。本文不会详细解释阿里云的使用细节,关于如何部署/管理阿里云资源请参考阿里云文档。
注意⚠️:笔者在此只简述工作原理及搭建简易POC,不保证任何可靠性及安全性。鉴于笔者的水平有限,文中不免出现错误,请不吝指出。
使用阿里云免费额度一定要注意,由于本文所述的云函数几乎是一直运行,因此极其容易被反薅羊毛。
一般的代理工具的工作方式一般被称为“正向代理”(有别于“反向代理”),在不考虑某些特殊的隐蔽流量的需求的情况下,常用的正向代理方式有http/https/socks。使用云函数搭建http代理非常简单,基本是开箱即用,因为http代理作为一个中间人可以完全获得http请求的内容,然后根据header中host的值直接进行转发。https代理,或者是基于http的隧道,都需要代理服务器支持connect
方法,而云函数运行在一个类似API网关的反向代理后面,该API网关与云函数之间不使用标准http请求通信,也同样不转发connect
请求,因此难以实现此种代理。
由于云函数所在的网络结构,类似于一个位于防火墙或者NAT网关之后的主机:可以与外部建立TCP连接但是不能监听外部连接请求。因此在这种情况下常用的反向SSH隧道便可以派上用场。
SSH客户端和服务端提供了方便的端口转发(port forwarding)功能,利用其提供的反向隧道(reverse SSH tunnel)功能,我们可以在云函数所在的主机(下称主机A)向一台外部主机(下称主机B)发起SSH连接并使用-R
选项来把远程主机的端口转发到本地主机端口,同时在本地使用SSH启动一个socks5代理,把端口转发的本地端口设置为socks代理的监听端口,这样就实现了外部主机B <--> 外部主机B隧道监听端口 <--> 云函数主机A本地端口 <--> 云函数主机A socks 代理
的代理转发流程。
出于安全和方便起见,笔者没有直接使用VPS上运行的SSH Server,而是选择启动一个Docker容器专门用于SSH Server,基于以下两点理由:
笔者使用Docker镜像linuxserver/openssh-server
启动SSH Server
1 | sudo docker run -d \ |
linuxserver/openssh-server
镜像默认监听2222
端口,笔者选择了对外暴露10241
端口。注意选项-v $(pwd)/88-enable_tunnels:/etc/cont-init.d/88-enable_tunnels
,该init脚本是为了在openssh-server中启用隧道功能,该功能默认是禁用的。88-enable_tunnels
文件内容如下:
1 |
|
注意笔者在本文中全部使用密码验证,如上所述这主要是为了方便起见,如果需要更高安全性可以换成密钥认证。
阿里云函数支持自定义Docker Image,这给了我们极大的方便。
首先我们要基于alpine
镜像,安装必要的程序:
1 | FROM alpine:latest |
其中sshpass
是为了能够在脚本中传入SSH密码。
接下来修改镜像中的sshd_config
文件,之所以要修改是因为我们除了要在容器中连接主机B以外,还要创建一个本地的socks连接,所以主机A也要能够接受SSH连接。
1 | RUN sed -i 's/#PasswordAuthentication/PasswordAuthentication/' /etc/ssh/sshd_config |
然后我们就可以开始建立SSH连接了,在镜像中加入一个脚本start-tunnel.sh
:
1 |
|
可以看到,主机B的6666
端口被转发到了主机A的54321
端口,而主机A的54321
端口就是socks代理的监听端口。关于脚本中的ssh命令选项在此就不赘述了。不过有一点需要注意的是,使用sshpass
搭配ssh端口转发会导致ssh client开启转发后立刻退出,因此使用sh -c ... sleep .1
来避免这个问题。
把这个文件复制到镜像中:
1 | COPY start-tunnel.sh . |
接下来是最后一个问题,阿里云函数在运行Custom Container的时候,默认通过9000
端口传入参数,因为我们的镜像也必须有一个HTTP服务器监听9000
端口。好在用Go语言写起来很容易:
1 | package main |
在Dockerfile中构建server
:
1 | FROM golang:1.16-alpine AS build |
最后运行docker build
和docker push
把镜像push到阿里云的镜像仓库。
在阿里云的控制台创建一个云函数并选择使用我们push的Custom Container,选择128MB内存的弹性实例(实际上笔者实测容器只用了<10MB的内存)。在Command
中填上["sh", "start-tunnel.sh", "PASSWORD", "user@Host_A_IP", "Host_A_Port", "TIMEOUT"]
。TIMEOUT
要配合函数配置,以及之前脚本中的时间(笔者选择10min)。然后创建一个每10min运行一次的定时触发器。这样就可以让容器几乎一直运行。
完成了以上步骤,主机B已经可以使用主机A作为代理了。作为客户端,我们还要创建一个客户端主机(C)到主机B的正向隧道,以便在本地使用socks代理。
1 | ssh $HOST -p $PORT -L 0.0.0.0:8086:127.0.0.1:6666 -N |
这条命令把主机C的8086端口转发到了主机B的6666端口,这样我们就可以在本地使用主机C的8086端口作为socks代理了。
1 | $ curl -x 'socks5://localhost:8086' https://api.myip.com |
几个月前开始看奎因的书,看完了《罗马帽子之谜》。我本来是冲着“奎因讲逻辑”这条去看的,但是第一我记不住里面的人物名字,第二虽然讲逻辑但是读起来还是有点枯燥的。整本书围绕着一个我觉得并不刺激的毒杀案展开,也没有什么猎奇悬疑的元素,甚至也没有冒险元素,是一本味儿特别正的本格推理。看到第二本《法国粉末之谜》的时候,我实在是受不了又长又难记的人名(偏偏记不住人名破案逻辑就无从谈起)就搁置下了。
再之前我把高罗佩的《大唐狄公案》读完了,说实话推理味儿有点淡,但是至少还有点冒险元素,读起来也还算是不错。
还有乱步,我之前读了他的《怪盗二十面相》,是明智小五郎系列的一本,但不是第一本。不知道是不是翻译的原因,乱步给我的感觉就是相当忽视周围环境的描写,语言非常平铺直叙而且口语化,其中还夹杂着第三人称故事讲述者的自言自语,看起来像说书。然后看了他的《两分铜币》和《人间椅子》这两个著名短篇,《人间椅子》的构思还是挺有意思的,至少我现在读来还有新意,但是我怀疑它到底能不能被归类到推理小说的范畴。《两分铜币》就比较一般了,毕竟是处女作,而且也是100年前的小说了。上周我读了另一本明智小五郎系列的《魔术师》。整体的气氛渲染还是可以的,但是重点的密室杀人就草草带过了,门上有可以供小孩出入的气窗这种把戏已经被用烂了,身份交换这种戏码也很容易猜到。说是计划了40年的复仇,但是整个事件看起来并没有特别精心策划的感觉。我读完之后觉得最不合理的就是这个所谓的计划了40年的复仇,几乎全部依赖某个人在某时的偶然想法。比如被害家族的女儿,就算她本来是凶手的亲生女儿,但是她也是从小就在养父母家长大,被一个都不知道是真是假的“亲生父亲”忽悠两句就能痛下杀手?一个还没有结婚的年轻大小姐,竟然能收养一个比她小不了多少的养子,还能把他训练成莫得感情的杀手?还有她大哥,不知道为啥跑到钟楼上去,不知道为啥脑子抽了听见声音就要把头从钟楼表盘上的洞伸出去,还就是打死不缩回来。对了,利用钟楼的表盘和指针杀人我记得岛田庄司也玩过,不知道是不是从这来的灵感。我还是更喜欢横沟正史的风格,既有气氛,又有逻辑,有时间把金田一系列再看一遍。
这周看了京极夏彦的《姑获鸟之夏》。开篇第一章先看了半个小时京极堂关于灵魂,意识和大脑的哲学陈述,差点没坚持下去。不过我已经大概能猜到后面的故事肯定少不了幻觉,失忆和精神分裂,结果证明我猜的一点不错……除了冗长的哲学对话,京极堂在第一章关于“妖怪”这个可以说是全书、乃至全系列主题的阐述我觉得还是挺有意思的。我一向是对鬼怪妖这种怪力乱神嗤之以鼻,认为这些都是人类脆弱精神的牵强附会,抑或是对无法解释现象的自我安慰,是绝对不存在的。但是即使从自然科学的角度不存在,从民俗学或是社会心理的角度来看,人们一直以来都愿意相信怪谈却是实实在在的,这种大众心理的潜移默化的影响,是不是就让“妖怪”真的出现了呢?说起来《女神异闻录5》讲的好像也就是这样的故事,简直是梦幻联动!不过这也不奇怪,P系列的“Persona”这个词就是来自荣格,P5中印象空间也是来自荣格的集体潜意识。京极堂也是引用了荣格和佛洛依德的理论来讲述他关于灵魂和意识的看法(虽然我不敢苟同)。
过了第一章,事件正式开始的时候,我就觉得不大对了。谜面还是相当引人入胜的,丈夫从密室中消失了,妻子怀孕二十多个月还没有生产,妇产科医院有婴儿失踪,还牵扯到十几年前秘密的真相,可以说是吊足了我的胃口。但是坑爹的是,作为第一人称讲述者,并且跟事件有千丝万缕的联系的主角关口,竟然失!忆!了!!而且是心因性失忆,自己都不知道的那种!看起来的感觉是这样的:我好像有印象;我好像想起来了;不对,我没想起来;啊我又想起来了!但我就是不告诉你这个读书的。关口你把情书送错人了我拿jo指头都能想到,你对女主接下来干了啥导致你失忆我拿另一个jo指头也能想到,但你就是在那傻了吧唧的跟丢了魂似的脑子里只想着女主。还有你都结婚了,你在那追着女主屁股后面拼命献殷勤是想干啥?真是又蠢又渣!
接下来的故事就更加匪夷所思了,失踪的人根本没有失踪,就一直躺在屋子里,躺了快两年,那么为什么一直没有被发现呢?因为所有进过屋子的人,都看!不!见!尸!体!真是见了鬼了,幻觉好用也不是这么用的吧,虽然所有人都有精神创伤但是也不能这么巧都看不见吧?哪怕有一个正常人搂一眼就啥事儿没有了,结果尸体就被捅着刀躺在地上,还尸蜡化了。还有死者的妻子,假性怀孕还能真把肚子弄大了?更扯的是最后还能炸开,嗯?炸开??我严重怀疑叙述者关口不仅失忆而且脑子有病。主要凶手女主不仅有遗传病,还在小时候被性侵,然后生了畸形孩子被当面杀死然后彻底崩溃变成三重精神分裂(说着都觉得太惨了)。总之所有的事情都归结到遗传病、封建迷信和精,神,分,裂;再加上不知所谓的香艳描写(日本小说感觉总是会有这些),国产恐怖惊悚片是不是就是从这找的灵感?
京极夏彦本来应该是是新本格派,但是看完《姑获鸟之夏》我真的觉得这不应该是变格吗?这个案子也实在是太扯了而且几乎没有什么推理元素……不过这个系列我还是会看下去的,至少文学性还是挺好的,下一本应该是《魍魉之匣》,还改编了动画呢。
]]>说来也很巧,我第三次无日本是在我敲下这些字的时候的整整一年前,不多也不少。这次去主要是带着父母去关西玩一趟,所以有很多地方都是我第一次去的时候就已经去过的,这一篇我打算只写一写我之前没去过的地方,最后再聊一聊我接下来想去的地方。
我想去姬路城的原因是姬路城是文明5的奇观之一,而且其在现实中的所在地也离大阪不远。从大阪坐电车往西约一小时就到姬路市了,从车站出来远远地就可以看到姬路城天守阁,步行大约十分钟就可以走到姬路城脚下。
姬路城建于越700年前,其大天守是目前日本保存最完好的,而且也是可以进去参观的。大阪城的我没进去,但是姬路城还是有点兴趣的。从最底下走到顶层再走下来,全程大约花了30~40分钟。
天守阁的窗
除了大天守以外,还可以进入西の丸参观。
姬路城旁边有一个名叫“好古園”的日式庭院,我记得姬路城的门票是包含好古园的,而且里面的景色还是非常值得一看的。
姬路城附近的一栋楼的楼顶有一个展望台,这里可以看到姬路城的全景。
透过展望台上的望远镜拍的大天守
贵船神社在不少京都旅游的文章中被大力推荐,第二次来京都我就决定去看看。贵船神社在京都市北部的山里面,可以坐公交车也可以坐电车。我还是比较推荐坐电车,搭睿山电铁鞍马线到贵船口站下车,如果正值红叶季的话,这条线路还会穿过一条名叫“红叶隧道”著名赏枫景点。在贵船口站还要再坐一趟巴士继续向北一段距离,然后再走一小段路才能到。
贵船神社面积很小,跟伏见稻荷大社这种完全没法比,爬上两边布满红色灯笼的石梯进入神社,一共没有几间房子,走几步路就出来了。虽然神社很小,但是历史却非常的悠久,以至于创立时间不可考,传说是在公元五世纪建立的。
贵船神社的抽签占卜很有特色,是抽出签后放到水中才会显现出文字,有兴趣的一定要试一试。
我这次去日本是在京都动画2019年的事件过后半年,当时的现场还没有被拆除,仍在进行现场处理工作。我专程去了第一工作室的现场看了看,实在没有心情驻足观望所以又匆匆离去,直到现在我仍然对于那里发生的惨剧耿耿于怀。
丰乡小学校是滋贺县一个偏僻的乡下学校,从京都站要换乘一次,其中第二程电车的车站甚至不能用IC卡,总时间一个半小时。我之所以去这么一个偏远的乡下地方是因为丰乡小学校是《轻音少女》的取景地,那里现在还保留着轻音部房间的布置。
丰乡站站牌
从车站出来直接往右边走约10分钟,穿过“真·农村”就到了。
熟悉的校舍
蓝白碗
梦开始的地方
我的眼泪差点没止住,仿佛她们真的在这里
喜欢京都动画/轻音的一定一定要抽时间来一次,绝对不虚此行。
这次我还去了广岛,但是最该去的原爆纪念馆我没有去,而是去了严岛神社。本来是想去拍那个著名的海上的大鸟居的,但是可惜去的时候鸟居在维修,被包的严严实实,只在神社里转了一圈便返回广岛然后去吴市的大和博物馆了。
吴市是海军重镇,二战前的“吴海军工厂”便是建在这里,而吴海军工厂就是建造大和号的地方,所以在吴市会有一个大和博物馆也就不足为奇了。
1/10的大和模型
基本上日本我最想去的地方都已经去过了,但是还有一些要么太小众,要么太偏僻的地方还在我的必去清单里,对于我的下一次日本旅行,现在的打算是呆的时间久一点,大概一个月左右,然后从东京出发顺时针来一趟环本州岛旅行,顺便去一下九州和北海道。但是现在的这个疫情情况也不知道要等到什么时候了。
]]>从旧金山起飞的飞机,大多数还是飞东京的,这次我是3月31日下午抵达东京,等到宾馆的时候已经是夜幕降临了。因为时差的关系,我第二天早上五点钟就起床了。第一站是紧邻皇居西墙的千鸟渊。千鸟渊也是一个久负盛名的赏樱之地,其本身则是皇居护城河的一段。
清晨的樱花
从千鸟渊公园可以看到不远处的国会议事堂
千鸟渊沿着皇居的城墙一直往南走的话,会看到皇居的南门,樱田门。樱田门的对面就是东京警视厅的总部,也是名侦探柯南中经常出现的地标性建筑。我在岛田庄司的吉敷竹史系列的某一本小说中知道东京警视厅就坐落在皇居樱田门的对面,因此也有用樱田门来代指警视厅的说法。
还有值得一提的是,当天正好是新年号发表的日子,还是挺巧的。
皇居乾門外的首都高速公路出口
皇居的正北方,千鸟渊旁边有一个北の丸公园,日本武道馆便坐落其中。武道馆因为有很多世界顶尖乐队及歌手在此演出过而闻名于世,也是《轻音少女》轻音部众人的目标。
田安门
上野公园,全名上野恩赐公园,位于离皇居不远的台东区上野。上野公园是日本第一座公园,其中的上野动物园也是日本最古老的动物园,从中国来的大熊猫便是在这里。不过我去上野公园是为了赏樱的,所以没有去动物园。
当天是周一,也不是假日,但是上野公园内也是游人如织,路两边的樱花树下有很多野餐垫,不过我去的时候时间尚早,只有三三两两的占位子的人。
上野公园的樱花
上野公园里有一个小湖名曰不忍池,其中有一条长堤,两边都是樱花垂柳,非常好看。
不忍池
离开上野公园,我的下一站是《路人女主的养成方法》中出现的のぞき坂
安艺伦也就是在这里遇到加藤惠
这个坡给我的感觉非常陡,伦也能骑车骑上这个坡是真的强。
下一个地方则是一个叫“須賀神社女坂”的地方。名字没有听说过不要紧,我放张图你可能就知道了。
完全一致
虽然右边的墙被改掉了,整体高度也有变化,但是还是能看出来的。Google Map上这个楼梯的名字已经是“你的名字楼梯”了……
上一次已经来过一次目黑川,这一次来的时候樱花似乎比上一次还要更盛一点,不少河道上樱花铺满了天空。
只不过人还是一样的多。
上次来东京的时候我去了东京塔脚下,但是离得太近了反而看不太清楚,这次在东京我去了位于六本木的六本木之丘(六本木ヒルズ)。这是一栋摩天大楼,但是可以登上露天楼顶,可以俯瞰东京夜景,同时也把东京塔尽收眼底。本来在下午就是阴沉沉的天空在夜幕降临的时候飘起了雨滴,但是不是很大所以顶楼天台还是开放的。要注意的是出于安全原因顶楼室外是不能使用三脚架的,所以要长快门拍夜景的就靠一双铁手吧。次一层的展望台可以隔着玻璃欣赏夜景,没有风吹雨打。
在下雨,有点雾蒙蒙的,姑且看看
脚下灯火通明
新宿方向,远处的建筑已经在雨雾之中,中间的楼就是言叶之庭中经常出现的NTTドコモ代々木ビル
第二天我的第一个目的地是横须贺。横须贺位于神奈川县东南的三浦半岛,扼住东京湾进出要道。横须贺在日本海军的历史上是个非常重要的城市,横须贺海军工厂从明治初期开始便负责建造军舰,慢慢发展成为一个军港城市,19世纪末设立横须贺镇守府,简称横镇。你游第一个服务器便是横镇。曾经参加过日俄海战的联合舰队旗舰三笠号,也是当时东乡平八郎的座舰,现在作为纪念舰还完整保存在横须贺。横须贺现在也是海自和美国第七舰队的司令部所在地。
从东京站或者品川乘横须贺线可以直达横须贺。我先去了三笠参观了一番,作为100多年前的战列舰,三笠给我的视觉冲击力没有洛杉矶的衣阿华号战列舰大,主要是体型不够大,主炮口径也只有30.5cm。(大和:食我46大根啦
东乡名言
中午吃了你游用来骗钱的海军咖喱😾。
吃完饭我就去了一个叫做“YOKOSUKA軍港めぐり”的乘船环游军港的项目,就是搭船在港口里绕一圈,还会对停泊在港口里的军舰有一些介绍(日语)。当时在港里的大船有海自的出云号直升机航母护卫舰,里根号核动力航母。对于舰C玩家这个旅游项目还是很值得一去的。
军港周边的公园里有一些原帝国海军有关的东西,比如长门和山城的纪念碑以及陆奥的四号炮塔(不是三号!)上的一个主炮炮管等等……
从横须贺返回东京的路上路过镰仓。镰仓对于ACG爱好者来说最先想到的是《灌篮高手》中出现的那个道口,以及近几年的《青春猪头少年不会梦见兔女郎学姐》中的圣地江之岛。镰仓本身也是一个历史名城,12到14世纪的时候,幕府便是坐落在镰仓,因此那个时代被称为镰仓幕府时代。
不过因为时间的关系(只有几个小时)我没有怎么去镰仓的古迹,也没有去江之岛(要走不少路)。只在《灌篮高手》的道口附近转了转,那里拍照的人非常多,几乎不可能拍出没有人的还原度比较高的照片。
河口湖是富士五湖之一(河口湖,本栖湖,山中湖,精进湖和西湖),不仅可以在比较合适的距离欣赏富士山,而且可以乘“富士回游”号特急列车从新宿直达。我当时没注意富士回游号是全车指定席,只买了自由席车票,结果当天满座,我只能在车厢一头的过道里席地而坐。
这个位置构图很独特
新倉山浅間公園
我住的地方就在河口湖站出来不远的地方,然后在附近找了一家自行车行租了一天的自行车。河口湖还是比较大的,靠步行不仅浪费时间还浪费体力,所以自行车是比较好的选择。
那天天气很好
河口湖边上有一个很有名的地方,名叫青木原树海(青木ヶ原樹海),也就是传说中的自杀圣地,据说每年都会在其中发现两位数以上,甚至三位数的自杀遗体。对于这种现象一种比较广为接受的解释是在这个风景优美,人迹罕至的地方自杀可以很长时间不被发现,也不容易给别人添麻烦。选择卧轨会导致列车延误,跳楼会给附近人造成影响,在家吃安眠药也会给房东/家人带来麻烦,所以在森林里悄悄结束生命才会在轻生群体中流行起来。可以,这很日本。
我在到河口湖的那天下午骑车绕湖大半周。第二天早上则骑车去了十公里外的西湖边(跟杭州的西湖没有关系)。
下午则还了车,上了去往岐阜县高山市的巴士。
我在上一篇中说过,高山市是我一直想要去看一看的城市,它在岐阜县的群山之中,是个货真价实的山中小城。高山市旁边是飞弹市,常与高山市合称“飞弹高山”。飞弹市原本就以“飞弹牛”(一个和牛种类)出名,在《你的名字》中,宫水三叶的老家糸守町便是在飞弹市(但是飞弹市没有湖,湖的原型是在长野县的诹访湖)。
高山市地处群山之中,从关东地区过去有几种选择:一是走东海道新干线到名古屋,再换高山本线到高山。二是走北陆新干线到富山市再转高山本线。三是乘巴士,新宿和河口湖都有巴士往返高山。如果选择铁路的话,必须搭新干线否则路上可能就要耗费一天多,考虑到从河口湖出发,要坐新干线必须返回东京,巴士便是最适合我的选择了。
飞弹高山并不是非常热门的旅游目的地,多数游客也会选择铁路交通,从河口湖过去的游客就更少了,所以我很幸运的成为了那一趟巴士的唯一一个乘客(也不知道这条线路怎么盈利)。大概五个小时车程只有我和司机相顾无言(互相听不懂,司机的英语非常蹩脚且日式)。这条巴士路线会路过我刚才提到的诹访湖,然后翻过日本中部的群山。在靠近山巅的地方,有一个温泉乡叫“平汤温泉”,那附近的积雪在四月份都还没有融化,我一直想体验一下在雪中泡露天温泉来着,可惜这次只是过客。山路本就蜿蜒再加上日本道路又窄,我不止一次惊叹于司机的精湛车技,有的地方的转弯半径都小于大巴车的长度,甚至没法一次转过去……
我是不喜欢坐大巴的,尤其是山路上的大巴。上次坐大巴从成都到九寨沟我坐了整整八个小时,在最后的山路上被晃吐了。但是这次的日本大巴体验还是不错的,至少我没有感到任何不适。
抵达高山的时候太阳已经下山了,巴士站就在火车站旁边还是挺方便的,我订的旅馆也在火车站对面。这还是我第一次到一个不是很热门,或者说对于外国游客不是很热门的地方,跟东京,京都这种城市比起来,高山站前的这家旅馆设施明显要老旧一些,外国游客也不多。
我还能记起在旅馆安顿下来之后我下楼去找吃的,信步走进了附近一家小店,里面的白炽灯的暖光很昏暗但是顾客却很多,是那种一看就是当地人去的店。我点了一份炒面,量大又便宜,是我在日本少有的感到经济实惠的一餐。
第二天一早我就开始了我的圣地巡礼,一大早去的就是“宫川朝市”。宫川朝市的地点在一条叫“宫川”的河川旁边而得名,其形式类似于赶集(如果你知道什么是赶集的话)或者ACG作品中的夏日祭典,道路两旁都是小摊和店铺,卖的东西主要是手工艺品和瓜果蔬菜。
宫川朝市
一毛一样
接着沿着宫川一直往北走,就差不多可以走到“岐阜県立斐太高等学校“ 门口,这所高中就是《冰菓》中神山高等学校的原型。
非常还原
当天不是休息日,在学校门口转来转去感觉不太好,我只拍了几张照片就掉头往回走了。走回宫川朝市后继续沿着河往南走两个路口,左手边有一家叫做“バグ・パイプ”的咖啡店。这里就是吃蛋挞和折棒约会喝咖啡的地方。
店外
店内,差一位美少女圆满
在收银台旁边还能看到一些冰菓的宣传材料,不过动画的巡礼地图已经没有了,只有真人版的。我也没太好意思问老板还有没有。
冰菓OP画面
从咖啡店东边有一片古街,这些是从江户时代至今保存了数百年的建筑,值得一看。
再往东走一点则是冰菓中神山市图书馆的原型:高山市图书馆。
又名焕章馆
从高山市搭乘高山本线的列车向北便是飞弹市,而往南的下一站叫做飞弹一之宫(飛騨一ノ宮),这个车站所在的小镇便是冰菓最后一集中女儿节祭典(现实中的生雏祭,生きびな祭り)的舞台。祭典是由水无神社在每年4月3日举行,我很不巧的错过了,下次有机会再说吧。动画中出现的那一大株樱花树名叫卧龙樱(臥龍桜),据说已经有1100岁了。可惜的是卧龙樱在4月中旬才开花,所以动画里在四月三号罕见地遇到满开的樱花才会有人设计故意绕远路。
下午我搭车去参观了一下白川乡。白川乡因为独特的合掌造民居而被登录为世界遗产。合掌造就是茅草屋顶很高很尖的房子,因为房梁很高,所以人字形的屋顶坡度很陡,在下雪的时候不易积雪。
白川乡
我觉得白川乡最佳的拍照时间是冬天下雪的时候,我记得看到过不少积雪很厚的时候的白川乡照片,很有童话氛围。
不少人的心理阴影,《寒蝉鸣泣之时》的原作游戏和动画的背景都是取材自白川乡。日本的这种山中闭塞的小村落感觉确实很契合惊悚恐怖故事,无处可逃的压抑感很容易引起共鸣。现实中这种小村庄也确实发生过不少可怕的故事,比如津山事件;再比如三毛别棕熊袭击事件,不过津山事件的发生地在冈山县,而棕熊袭击事件则是在北海道。
最后我从高山市搭高山本线到名古屋然后转乘东海道新干线返回东京。高山本线是我第一次见到在国内很少见的柴油动车,虽然是分散动力的动车组,但是每节动车都是柴油动力的。也许是山中的铁路电气化成本太高得不偿失吧。回到东京后就是逛了两天秋叶原,然后我的第二次日本之行就结束了。
最后我想引用一下千反田在冰菓最后一集最后的话:
这里是我的故乡
只有水和土地
人们也在渐渐老去,失去活力
我并不觉得这里是最美的地方
也不觉得这里充满了可能性
但是……
我想向折木同学介绍这里
可能正是因为这席话,我才会跨越千山万水来到这里吧。
缘,妙不可言。
]]>写着写着发现要写完三次游记实在是太长,所以会分成几篇文章。
⚠️大量图片预警
说到我为什么想要去日本旅游,那不用问当然是我看的日本动画和漫画的影响。
我好像还没有怎么跟人提起过我的入坑作,那就在这里顺便说一下吧。2014年的六月末,那是成都闷热的夏天,大二下学期的期末考试也接近尾声,但是因为还有小学期要在学校呆到七月中下旬,所以我就只能在宿舍里想办法打发时间。不知道是什么原因,我鬼使神差地开始用iPad看起一本叫《只有神知道的世界》(简称《神知》)的漫画,结果一下子就看得入迷了。在此之前日本漫画我只看过火影这种热血大长篇,校园恋爱后宫类只看过一些以前很流行的网络YY小说,漫画这种形式还真的没有看过,再加上若木民喜老贼的画风还挺对我的胃口,让我看完了漫画后仍然意犹未尽。于是一番搜索发现《神知》是有动画的,所以又看完了三季动画。看完后还是没有尽兴,于是慢慢打开了新世界的大门。我还记得《神知》之后我看的是《约会大作战》第一季,也是我在B站看的第一部番。万幸《约战》第一季还算是制作精良,让我有动力继续找其他的番来看,进而一发不可收拾彻底入坑。
而真正勾起我想去日本看看的强烈欲望的,是在一个多月后在我看《冰菓》的时候。《冰菓》当时是真的惊艳到了我,在那以前我从没有想到过动画可以做到如此精致细腻。它第一次让我强烈感受到了日本这个国家的美,让我迫切地想要亲自踏上那片土地,用我的双脚和双眼去感受孕育出那些动画和那些人的地方。《冰菓》也第一次让我知道“圣地巡礼”这种事物的存在,也让我记住了故事发生的地方:岐阜县高山市。
千反田俺の嫁
后来我看过的越来越多的动画和漫画,都一直在加强我的这一愿望。与此同时,我在2015年的时候赚到了一些外快,算一算正好够我去趟日本来一次自由行。于是我毫不犹豫地把旅行时间定在了2016年的三月底,去看一看享有盛誉的樱花季🌸。
护照,签证这些东西就不再赘述了。2016年3月24日的清晨,我登上了上海飞往大阪的飞机,这是我第一次出国旅行,也算是第一次自己一个人进行长途旅行,当时兴奋的心情从那以后我都再也没有感受到过,即使是后来第一次飞纽约的时候也没有。
第一站是飞机的目的地,大阪。其实大阪对我来说没有什么特别想去的地方,也就是大阪城需要打打卡。即使是大阪城,也不是丰臣秀吉所建的那一个了,而是昭和初年用钢筋水泥重建的。
通天阁
刚到的那天晚上我就到住处附近的通天阁和道顿堀转了转,虽说有不少餐馆,但是一是我本来就不贪图口腹之欲,二来我实在是没有勇气一个人走进去看着日语菜单出糗。只在小摊买了两盒章鱼烧和一个鲷鱼烧果腹。即使是街边小吃,我也是第一次见到鲷鱼烧这种只在动画里见过的食物。
大阪城天守阁
说实话像我这样不买东西也不爱美食的人在大阪没有什么好去的地方。对我来说,大阪这个商业城市还是少了点“味道”吧。我想也是因为类似的原因,即使关西作为修学旅行的常见目的地,奈良和京都的存在感要比关西最大城市大阪要高得多了。
动画中的奈良总是随着它最有代表性的鹿出现。但是作为1000多年前做过日本首都的城市,它的历史和文化底蕴也足以让我把它列在必去清单中。
从大阪天王寺坐有直达电车,一小时左右就到了奈良。步行游览奈良公园,春日大社和东大寺的话大半天时间就够了。出了JR奈良站,去游客中心拿一张地图,然后沿着车站门前的大路笔直地往前走就会穿过奈良公园。奈良公园有大片大片的鹿群,我猜这里就是《妄想学生会》中的天草会长被鹿推倒(不是)的地方。
奈良的鹿
穿过奈良公园就是春日大社。春日大社建于1300多年前,是奈良时代遗存至今的古迹。日本的神社、佛寺,即使是有着货真价实的千年历史,从表面上却也看不出非常明显的时间摧残的痕迹,我想这得益于不间断的修葺和维护,真正的忒修斯之船。
从春日大社出来沿着右手边的路向东大寺走,会路过若草山。这里是奈良少有的可以登高远眺的地方。
奈良市全景
下山后我接着往前走,便会到东大寺。东大寺距今也有近1300年的历史,后来毁于动乱,现在的东大寺大佛殿是300年前重建的,其最负盛名的便是高15米的大佛。
我当时走了这一圈已经是下午四五点钟了,没有时间再去奈良附近的寺庙,于是便打道回大阪府。后来2019年时与父母再访奈良,基本上是走了一模一样的路线,但是最后还是剩了一些时间又再多去了一个唐招提寺。
中国所保留下来的唐代建筑几近于零,在奈良却还能体会到一丝唐风。
东大寺大佛殿
京都应该是日本最热门的旅游目的地之一了吧。在动画中,除了舞台就设在京都的动画(比如《四叠半神话大系》,《稻荷恋之歌》)以外,在有修学旅行剧情的动画中很多也都会到访京都(比如《轻音少女》,《我的青春恋爱物语果然有问题》,《摇曳百合》)。
京都市内的景点极多,我当时花了三天时间走完了一些必去的地方。京都市内电车并不发达,大概是古迹太多以至于没法大规模修建铁路和地铁,也有可能是出于维持城市原貌的目的,总之主要交通方式是坐公交车。
从大阪乘电车很快就可以到达京都站,但是我当时住的地方并不在京都站附近,而是在伏见稻荷大社附近,在京都站以南几站的地方,所以我在宾馆落脚以后就直奔伏见稻荷大社了。伏见稻荷大社的名片便是千本鸟居,千本鸟居在伏见稻荷大社走进去左手边不远的地方,鸟居排列非常密集但是大小上却都是属于小号,高度大约只有两米左右,其中到底有没有一千座鸟居我也没有数过。千本鸟居有来回两段,每一段大概只有数十米长,而且游客众多不管怎么拍都肯定会拍进去一大堆人头。好在穿过千本鸟居后可以选择爬上神社后面的小山,蜿蜒的山路两边也是一座一座紧挨着的朱红色鸟居。这山路上的鸟居体积就要大了一号,而且布满了上下山小路两边,我猜没有上万座应该也有几千座了。
小时候看的柯南剧场版《迷宫的十字路口》ED的画面中就有不少伏见稻荷大社鸟居的镜头。可是那时候我都看不出来什么,只是觉得很美。
稻荷神是主管谷物丰收的神,后来又被赋予了保佑商业繁荣的职责,伏见稻荷大社作为全日本所有稻荷神社的总部所在所以香火旺盛也是情理之中,这满山的鸟居每一个都是要花真金白银才能建造,可不是我这种只往赛钱箱里扔几枚五円硬币的穷鬼能比的。
鸟居
走完神社后面的山路还是需要不少时间和体力的,另外,最好要在阳光充足的午后到傍晚的时候去,这样阳光暖色会让鸟居的红色更鲜艳。
特色狐狸绘马
傍晚的时候从伏见稻荷大社出来,我又去鸭川旁边转了转。
《轻音少女》OP中出现过类似的石桥
第二天一早我就去了另一个著名景点:清水寺。我先从京都站坐公交到清水寺站,然后沿着清水坂一直往上走便到了清水寺。清水寺作为动画常客最出名的是清水舞台,以及清水舞台后面据说祈求姻缘非常灵验的地主神社。
清水舞台,那时樱花还没有满开,我下次再来的时候就已经在维修了
从清水寺出来往北走,穿过古香古色的二年坂和三年坂。再一直往前就到了八坂神社。我记得我在走到八坂神社的时候天降骤雨,幸而神社里有一个棚子可以躲雨。
二年坂
银阁寺本身可看的并不多,有名的枯山水我也不太欣赏的过来,但是银阁寺门前的哲学之道(哲学の道)是很好的赏樱地点,可惜我去的时候还没有满开,真正看到满开的樱花是在后来在东京的时候了。
🌸
在京都的第三天我起了个大早去岚山搭嵯峨野小火车。本来也是很适合赏樱的,但是还是太早,岚山的气温比京都市还要低一些,开放的樱花更少。
小火车从龟冈站出发,到达嵯峨岚山后出站走几分钟就到了著名的岚山竹林(大老师自爆现场)。
岚山竹林
同样,竹林也是需要有充足的阳光才更美。接着沿着竹林小径往前走,顺路转了转天龙寺,路过宝严院再往左拐就到了渡月桥了。对于渡月桥我最初的记忆依然还是在轻音的修学旅行篇里。现实中的渡月桥离岚电岚山站和JR嵯峨岚山站很近,人很多,旁边还有很多纪念品商店和小餐馆。
仓木麻衣有一首歌叫做《渡月橋 ~君 想ふ~》,是柯南剧场版《唐红的恋歌》的ED。这部剧场版虽然不咋样,但是歌还是好听的。
金阁寺,京都御所我就跳过了因为没有什么好说的,就放一张金阁寺的照片吧。
金阁寺
我在京都的最后一站就是位于京都市南边的宇治市的京都动画了,京都动画作为我最爱的,也是制作《冰菓》,《Clannad》等我心中神作的公司,是不能不去看看的。从京都站搭奈良线电车到木幡下车(如果我记得没错的话,这个站小到只有各停列车才会停),出了车站就是京都动画本社那不起眼的三层小楼了。
京都动画本社
那个时候外面的海报还是京吹剧场版总集篇和无彩限BD呢。公司大门是进不去了,所以我就继续往前走了一段路去了京都动画商店。
京都动画商店后来搬了新地方
现在翻出这张照片我才发现,除了京吹,无彩限和Free以外,竟然还有京紫的海报,当时完全没有注意到啊。
看着这为数不多的几张照片,我又想起了去年夏天京都动画第一工作室发生的惨剧……真是上天不公,好人没有好报。
离开京都,我的下一站是箱根。为什么选择了箱根呢?首先是箱根的温泉很有名,其次是据说在芦之湖可以眺望到富士山,最后是箱根是EVA中第三新东京市的位置。
东海道新干线希望号N700系
我搭新干线到小田园,然后转箱根登山电车到箱根汤本。可惜的是大涌谷的缆车因为有喷发迹象而暂停了,所以实际玩的只有芦之湖上的游览船,但即使当天天气晴朗我也没有看到富士山的影子。
在箱根我专门找了一间温泉旅馆,可是我在温泉里泡上一会就觉得头晕脑胀不得不停下来,看来还是不太适应泡澡啊。我选的也是一间和室,也就是铺着榻榻米的房间,而且还有被炉。箱根海拔比较高,当天夜里气温接近零下,我第一次体会到被炉在这种天气有多爽,真是钻进去就再不想出来。
对了,箱根汤本车站前有一个EVA官方商店,喜欢的话绝对不能错过哦。
接下来就是我这次旅行的最后一站,东京了。我到东京的那天晚上正好是Lovelive缪斯的最后一场演唱会,虽然我不是拉拉人,也没有买票,但也还是去东京巨蛋外面凑了凑热闹,还买了我人生中第一盒实体CD。接着去了东京地标东京塔,但是这种大型建筑,离得太近了反而看不清楚,我下次再访东京的时候就学会了,从六本木的高楼上看东京塔更符合我想象中的样子,留到下一篇再说吧。
宅男胜地,二次元宇宙中心(笑)。秋叶原是我怎么逛都不觉得无聊的地方,好玩好看好买的东西太多了,但是彼时我并没有多少可以支配的资金能够在这里挥霍,所以大多数时候只能对着各种周边流口水(擦)。
秋叶原也是一个圣地巡礼的宝地,我印象中最出名的就是《命运石之门》和《LoveLive》了。这两部动画中的很多事件都是发生在秋叶原,要是把圣地巡礼的照片都贴出来的话也没什么太大意义,网上已经有很多圣地巡礼攻略了。我想提一嘴的是神田明神神社,它在LoveLive动画中有登场过,主角们练习体力的那个台阶顶上就是神田明神神社了。我在那里偶遇了一场由神官主持,新娘穿白无垢的日本传统婚礼,运气还是很不错的。
果皇痛车(给俺也整一个)
新宿御苑是新海诚的剧场版动画《言叶之庭》的主要取景地,我去的时候正好是东京的樱花满开的时候,总之就是一个字,美!我在东京的那一天基本就是一直在看樱花,这辈子如果没有看过樱花满开的盛景那真的是一大遗憾。
从新宿御苑出来往西南走一会就到了明治神宫。如果要是看樱花的话,我印象中明治神宫并没有多少樱花树,反而是参天的古木非常多。穿过明治神宫,有一个叫参宫桥的小田急线车站,这个车站往南走到第二个道口,也就是“小田急线参宫桥第二踏切”这个地方,就是著名的新海诚动画《秒速五厘米》中最后出现的那个道口。我作为秒五的死忠粉,这个地方是肯定不会错过的。
道口附近逛一逛还能找到不少熟悉的场景,渋谷区立参宮橋公園则是动画一开始的时候场景。
再往南走一走的话代代木八幡宫也是秒五的圣地之一。
接下来我路过涉谷车站,摸一摸已经被磨得锃亮的八公像的前腿。《忠犬八公》还是高中时音乐课老师给放的(没错,音乐课……),当时把我给感动的稀里哗啦的。
然后从涉谷前往目黑川。目黑川如果以河的角度来看的话是一条很小的河,而且还是穿过东京闹市,但是它的那一段河岸两边种植了大量的樱花树,所以也是赏樱圣地之一。
目黑川的樱花
樱花季的时候目黑川的人非常非常多,河两边的路也非常的窄,是字面意义上的摩肩接踵。我后来2019年再来的时候人也还是那么多。
台场,或者叫御台场,在东京的东南边深入东京湾。台场是一个人造陆地,是近几十年才开发起来的,台场与东京都港区连接的桥梁名叫“彩虹大桥”,在很多日剧里作为背景板出现过。
我为什么要去御台场呢?因为御台场可能是我脑中记住的第一个日本地名,比东京还要早。它是《数码宝贝》第一部中大多数主角生活的地方,在我还没怎么有日本这个国家的概念的时候,御台场这个地名就深深印在了我的脑海里。后来我知道御台场是现实中存在的地方时候就想去看看了。
BTW,御台场还有一个宅圈有名的建筑,那就是每年Comic Market举办的地点:东京国际展示场。
即使是已经快五年前的事情了,但是我现在的脑海里第一次日本旅行那两周的记忆还是那么鲜活。我还能记起很多细节,比如我在京都的时候坐公交下错站被一个老奶奶搭话时的手足无措,还有在参观伏见稻荷大社之前,我在正门对面的便利店买了两个面包,然后就坐在店外的长椅上一边看着神社入口的大鸟居一边吃。
在东京的最后一天我全部花在了逛秋叶原和买东西上,当然因为没有钱最后也没有买多少。当时买的手办后来随着我漂洋过海来到北美,现在就摆在我身后的架子上,想来还有一点不太真实的感觉呢。
好了,第一次的日本之旅就写到这里了。下一次我会到访富士山,然后真正的前往我心心念念的《冰菓》舞台岐阜县高山市。下一篇再见啦。
最后贴一张从浅草寺拍摄的云中的天空树
]]>Google内部对于Google员工称为Googler,而新入职的New Googler则被称为Noogler。在入职办手续的时候,在入职Orientation的时候总是能听到这个词。一开始的时候我要参加一个为期数周的培训,说是培训,其实是一些老员工来给新人介绍介绍内部工作流程和内部工具。
Google内部有一大堆的内部工具,似乎大公司内部都很喜欢自己造轮子?一方面是大公司的需求可能是地球上独一份的,比如Google的代码管理显然不能用基于Git的,又比如海量数据存储分析倒逼Google开发大数据框架(其开源实现就是Hadoop)。而这种前沿需求又意味着抢先开发完善该领域就极有可能在未来成为事实标准,最近的例子就是Kubernetes,K8s其实不是Google为了内部开发的,内部有名为Borg的类似容器编排系统(Container Orchestration System)的工具,K8s借鉴了一些Borg的设计重新在开源许可证下实现了一套容器编排系统,并成功成为了现在行业的事实标准和云原生(Cloud Native)应用的基石。另一方面就是大公司有足够的人力资源和技术储备来开发和维护内部系统。现在传统行业,或者说非互联网行业向云计算迁移,一个主要动力就是自己维护IT基础设施需要持续、大量的投入才能达到勉强可用的水平,这部分的成本其实本身并不是必须的,云计算提供了一个把这部分工作“外包”出去的可能。但这对于大型科技公司来说不是问题,毕竟这是它们的老本行。并且由于上一个原因,开发这些东西在未来是很有可能带来收入的,所以大公司更倾向于开发和使用自己的内部工具。
说到造轮子,我所能想到的最典型的就是自己造编程语言了。Apple为了自家平台搞了Swift还挺顺理成章的,Google的工程师用C++用着不爽怎么办?造个新的你不会吗?于是一个静态链接,二进制分发,性能比肩C/C++,语法简洁类似C,还不用头疼指针的Go语言诞生了(当然,语法简洁必然带来的是表达能力的下降,比如我很不喜欢的if err == nil
和没有构造函数只能用工厂方法)。另一边Facebook的工程师也不爽PHP,于是他们也另起炉灶搞了一个Hack语言,虽然我没有学过Hack,但是光看例子就有一股宇宙第一语言的味儿扑面而来。该说各个公司造的语言还都挺有各个公司的特色的吗?
扯远了,培训就是主要讲内部用的代码编辑器,提交review,跑test,提bug一类的东西。由于我的日常工作是在GitHub上的开源项目,所以培训之后我也再也没用过这些东西。
对了,所有这些工具全部都是跑在浏览器里的,这一点是最让我大开眼界。也不知道是这些内部工具催生了高性能浏览器的需求,还是Chrome强悍的性能让完全WEB化成为可能。浏览器里面跑一个全功能IDE,并且要在Google这种代码量下达到可用,比后来的VS Code要强多了。另外我也是第一次知道Chrome有扩展可以实现完整的SSH客户端,以及黑魔法一样的远程桌面(同样是跑在浏览器里,非内网环境却几乎感觉不到延迟,我怀疑跟Google Stadia的技术有共通的地方)。还有GSuite那一大堆办公套件全都是纯WEB的,感觉Google里是万物基于Chrome(怪不得会有Chrome OS这种东西呢)。
经过了一开始的一两个月之后,我就开始在慢慢上手我现在主要工作的项目了,项目本身是用Go语言写的,属于Kubernetes的相关工具吧。上手倒是没什么太大的难度,代码都在那里摆着,看就是了。从一开始的修修bug,再到后来慢慢写写小功能,做一些同组其他项目的工作,也还算是轻松愉快吧。唯一有点头疼的写设计文档,也许是我一直都是move fast的所以经常在写文档的时候不知道该写什么,一个我已经理解的东西再把它解释一遍让我很烦躁,可是不解释的话又觉得整个文档都没什么好说的,毕竟我得先理解了才能写。
我还有一个很深的感触,那就是大公司真的太大了,当然也许是WFH给我造成的心理错觉,我每天能有联系的也就是同组的几个人,所以开会和邮件里大片大片的陌生名字。还有就是大组100多号人都只是在做Google Cloud下的一个service,Cloud也只是Google的几个大部门之一,更别说Google是AlphaBet旗下的一个公司了。真正的是成为螺丝钉了,ま。いいんじゃない?我是觉得不太care的。
说到WFH,来大公司我最看重的免费三餐一次都没吃到,天坑啊,导致我天天都要纠结点什么外卖或者要做什么。还有免费咖啡,啊啊啊,好气啊。现在说要WFH到明年七月,也就是说还有大半年,说着说着快要过了一半了,似乎也没有那么遥远了。
]]>这次我是通过GitHub Actions来实现在Issues发布的内容,自动转换为Hexo文章,然后push到repo,再自动生成、部署。
https://blog.xiadong.info/2020/11/04/This is a test blog post/这篇文章就是这样写的,本文也是。
主要的workflow文件:
自己写的Action:
Workflow和Action之间都是用base64编码过的字符串,以防止特殊字符的影响。
整个流程挺直观的,主要步骤是:
github.event.issue
获取Issue信息自定义的Action其实是一个Docker image,只不过是由GitHub Actions在运行时构建的,我写了一个简单的Python脚本来处理输入的JSON字符串,然后生成一个Hexo的文章。
其实不需要啥功能,只有如下几个:
tags/...
,categories/...
的issue tag自动添加文章tag和category。BlogPost
tag的issue,这样可以灵活控制是否发布。问题:
bold
italic
首先考虑的就是POI的代码中还是有BUG,于是我从源码直接跑POI,PAC代理竟然神奇地work了,我以为是10.6.0之后修了什么bug,于是重新build,安装,又不行了……于是我花了好久看代码,但是看不出什么所以然,毕竟直接run是没有问题的,build之后问题才会出现。POI使用electron-builder来进行打包,我也不是很清楚怎么debug打包后的application,于是我尝试在proxy.es文件中用console.log
来打log。
由于这些log是打在electron的main process中的,所以它们不会出现在开发者工具的console里,而是会输出到stdout,所以我尝试着从terminal里运行打包后的application,命令如下
1 | open -W /Application/poi.app |
但是这样是不会在terminal中打出log的,怀疑与macOS的application加载机制有关。于是我就直接运行了POI的binary而不是整个application
1 | /Application/poi.app/Contents/MacOS/poi |
这样就可以看到console.log
的输出了。神奇的事情发生了,通过这种方式打开POI,PAC代理的问题消失了,功能完全正常,当时我就一脸黑人问号.jpg。这是什么神奇的bug?搞了半天是macOS的application加载机制作祟。我猜测是electron+electron-builder+pac-proxy-agent+macOS产生了什么不为人知的神奇化学反应导致了这个现象。
知道了问题,那么只要直接跑/Application/poi.app/Contents/MacOS/poi
就可以了。我用macOS自带的Automator建了一个一行shell语句的application
1 | nohup /Applications/poi.app/Contents/MacOS/poi > /dev/null 2>&1 & |
然后就可以通过运行这个application来启动PAC正常工作的POI了。
]]>家里刚刚添置电脑的时候,对什么都很好奇,总是迫不及待的想要体验最新的功能,用最酷炫的界面。我家的电脑一开始预装的是XP,后来很快的微软发布了Vista,作为跟Windows 8一样现在风评不佳的版本在刚出来的时候着实让我眼前一亮,尤其是一直沿用到Windows 7的Aero UI风格深得我心,可惜的是毛玻璃特效从8开始就消失了变成了扁平的我个人觉得很难看的Metro UI。我记得我当时在什么是ISO文件,什么是MSDN,甚至装系统到底是怎么一回事都不知道的时候就用4M小水管下了2.5G(也有可能是3.5G)的安装文件用虚拟光驱(现在的小朋友大概有很多已经不知道什么是光驱了吧)装了Vista尝鲜。
说到装系统,其实我第一次动手装系统完全是因为一场事故。我已经不记得是哪一年的事情了,但是应该是初中的某一天,我偶然发现了Windows有个“显示隐藏文件”的选项,然后就仿佛发现了新大陆一样,在C盘的根目录里面发现了不少隐藏文件,比如bootmgr,比如Boot.ini,比如NTLDR之类的,无知给我勇气,把它们统统删了个精光,然后毫无意外的重启起不来了。
对一个领域不了解的人总是无所畏惧,拥有不知从何而来的勇气,而了解的越多,就越发的谨慎。我想这也是我后来不再折腾软件的原因之一吧。这件事最后被从同学那里借来的一张OEM XP安装盘解决。其实我不知道有多少人见过XP的正式安装界面,因为那时的组装机应该还是Ghost安装盗版占据主导地位,而品牌机都是预装的OEM系统。当时买电脑附送的说明书中还说了怎么使用安装光盘装系统,但是不知道为什么我从来都没有见过附送的安装盘。而那本说明书其实也是我闲暇时候的读物之一,薄薄的一本跟当时我的电脑课教材一样被我翻了很多遍,现在想想还真是很无聊的。
2010年前后流行过很久的一段时间“电脑/软件管家”类的工具,比如360和腾讯软件管家,我相信它们一直到现在都还活的很好,毕竟在中国不懂如何管理软件的人比比皆是。但是还是小白的我毫不意外地成为了某软件管家的用户(到底是哪一个我不记得了),经常没事打开检查一下更新,不管有用没用都统统更新,不知道可能还以为我有强迫症。其实所谓的软件管家就是现在手机上的应用市场,只不过Windows的开放性让它们变得可有可无。
我自己有另一个挺好的例子,那就是Office套件了。可能很多人用过Office 2000,2003,2007 etc,但是2000和2003之间还有一个版本就叫Office XP,我家的电脑上一开始就是装的这个Office版本,但是在买了它之后不久,Office 2007就release了,于是我就又手痒地装上了2007(毫无意外的是盗版)。之后也第一时间升级2010,丝毫不管其实我几乎从来没有用过Office套件。一个苦逼中学生除了偶尔打印一些东西,谁会用到PPT和Excel呢?但是但是这些事情都不在我的考虑范围之内,一味地追求“新”。
转变应该是发生在大学之后,上大学以后我有了自己的笔记本电脑,天天都要用它,渐渐地失去了对于软件新功能的好奇心。另一方面,开始正式学习计算机之后我的兴趣慢慢转到了软件内部实现和计算机底层机制上去了,那些针对用户使用的更新已经不能再引起我的兴趣了。其实这也是我之前说过的,对于不是非常了解的事物,人们总是会去追求外在的东西,深入了解之后才能体会到真正核心的东西是什么。比如不了解汽车的人就会看重外观和牌子,而忽略掉最重要的发动机,变速箱等核心部件。曾经有显卡厂商通过片面宣传大显存而把低端GPU卖出高价,也是利用了这一点。
另一个问题我想就是现在的软件更新说明都相当的模糊了,现在我手机上的App更新说明,十个有八个是“bug fix & improvements”,尤其以大厂应用为甚。这种废话一样的更新说明简直就是在说:不要管我更新了什么,更新就对了。可是作为一个码农,“bug fix”可能还不错,“improvement”这种话真的让我摸不着头脑,我非常确信这些improvement一定会引入新的bug,说不定这次fix的bug就是前几次improvement引入的呢?而即使是真的improvement,也不一定是我用得上的东西,比如微信这个蠢玩意儿,我实际上只用聊天和朋友圈两个功能,你更新小程序关我什么事呢?但是开源软件是个例外,原因很简单,开源软件所做的更改我都是可以看得见的,虽然我不一定会去看,但是这种透明感就很让我信任。
最后一的一点原因就是我的软件使用习惯变了,十几岁的时候软件对我来说是一种玩具一样的存在,本来我就不怎么“使用”它们,而是从中找乐子,比如探寻各种不同的选项,比如在Word里敲些东西装作很专业的样子。而现在不一样了,我安装的每一个软件都是要解决特定需求的,比如我的Mac上装的BetterTouchTool就是为了自定义鼠标侧键,解决了这个问题就OK,我不需要你提供什么新的功能,除非有影响我使用的严重bug不然我也不需要bug fix,自然我也不想让你更新。再比如手机上的Twitter,能刷推就行,不需要什么别的更新了。
也许可以说我失去了探寻新软件的热情了,也许是软件的世界变了,从售卖license到售卖服务到售卖广告再到中国最先进的售卖客户自己,我对于大部分闭源开发商的信任都降低了很多,毕竟他们是要我身上赚钱的,所有的更新都要朝着这个最高目标优化嘛。
]]>我的博客里目前有343篇属于LeetCode类别的文章,而我实际在LeetCode上solve了834题,翻了提交记录发现我的第一次提交是在5年两个月前,也就是2015年的3月份。现在我已经忘记了当时为什么要开始做题,那个时候我还没有能出国、能来硅谷的奢望,估计大概是为了准备那一年的蓝桥杯和暑假里的保研夏令营吧。
我一开始的做题过程完全没有章法,纯粹是随机挑一题开始做,第一次提交竟然是#191,不知道当时是怎么找到这一题的。我本科的时候曾经还参与过学校的ACM比赛,水平实在是过于垃圾所以我用“参与”而不是“参加”,那个时候我看过刘汝佳的白书(算法竞赛入门经典),虽然几乎什么都没有记住,但是也算是对于LeetCode这种形式不是一张白纸吧。
我真正开始正视刷题这件事应该是在16年下半年的时候,毕竟有在北美找工作的压力,但是也还是没有什么计划性,我记得那时候应该是按照题号从小往大来刷的,笔记啊,整理啊更是统统没有(其实我现在也是没有🤷♂️)。我应该是从那个时候开始做周赛的,从那之后一直做了好几年。17年的时候应该一直在刷题,但是同时CMU的课业也是相当繁重,所以我也不清楚做了多少题。
绝大多数的题我都已经没有印象了,但是我还清晰的记得某些难题做不出来的时候,那种感受跟高中时的数学或者物理试卷上碰到难题的感觉差不多,似乎能抓住一点尾巴但是脑袋里面总是像是堵满了浆糊。
从18年,或者19的时候开始,大概做了400到500题左右,我能感觉到我的做题水平进入了一个新的阶段。很难精确地去描述这种感觉,我能感觉到我已经能在脑中快速过一遍LeetCode题目用到的所有的数据结构和算法,在看到一道题的时候,读完题我大概就知道需要用什么数据结构和算法来做。还有一个表现就是抽象能力的提高,稍微复杂一点的题目的文字描述总是会找一个情景套进去,从这个情景的描述中快速抽象出实际上应该使用的数据结构和算法是很重要的。
很多人总是会说做题无用,数据结构和算法在实际工作中基本上用不到。v2ex上这种自称CRUD boy的人尤其的多。不错,我工作快两年来一次都没有用到过DP和图论之类的东西,但是我认为更重要的不是你能记住几种算法,而是面对实际问题快速把它抽象为计算机语言的能力。
其实我是不喜欢“刷题”这个说法的,它给我的感觉总是有点功利化,有点漫不经心。做题本身应该是一种解决问题的娱乐方式,就像做数独,读侦探小说一样享受解谜的快感。而不是机械得去“刷”。
有一个很好的例子,在我写POI浏览器的舰娘收集进度插件的时候,遇到过这种情况:舰C服务器返回的数据中,舰娘类别数据和拥有的舰娘本身的数据是分开的。可以把类别数据当作是一个类,而实际拥有的舰娘是类的实例,比如你可以有两艘吹雪,她们都是同一个“类别”,每个舰娘的属性有一个ID会指向她的舰种。我现在的第一舰队旗舰是Fletcher改,她的舰船ID(api_id)是24326,舰种ID(api_ship_id)是692。而收集进度插件在处理的时候应该考虑类别而非实际舰娘,也就是即使你有两艘吹雪也只应该代表着“吹雪”这艘船已经收集了。但当考虑到改造的时候,问题就变得复杂了,在舰C服务器的数据中,每个舰娘类别中都有一个api_aftershipid属性,它指的是改造后的舰娘类别ID;与此同时吹雪、吹雪改和吹雪改二在收集进度中应该考虑为同一艘船,那么在有吹雪多号机以及不同改造形态的情况下,如何判断一艘吹雪改和一艘吹雪改二都是“吹雪”?稍微了解一些数据结构就能很容易地想到这个结构是一个典型的单链表:吹雪=>吹雪改=>吹雪改二,那么问题就抽象为,给定两个单链表节点,它们可能在也可能不在一个链表中,你要实现一个函数,返回它们是否在一个链表中。bruteforce的方法就是从一个节点开始遍历看能否到达另一个节点,因为两个节点的先后顺序不确定,所以前后调换再遍历一次。
让这个问题变得更有趣的是,舰娘改造现在是可以“反复横跳”的。Fletcher改 Mod.2的api_aftershipid指向Fletcher Mk.II,而Fletcher Mk.II的api_aftershipid又指向Fletcher改 Mod.2,在游戏中的表现就是形态切换了。而这个机制的存在就让上述的链表算法可能陷入死循环中。问题现在加了一个条件,这个单链表可能有环。要在链表的基础上解决这个问题就有点麻烦了,你也许会说:Fletcher这种情况,只要判断aftershipid是不是前一个节点不就行了?对于Fletcher这个特例,或者说大多数双形态切换来说都可行,但刷过题你应该就知道,用特例来通过边界条件是大忌,因为你不知道还有没有其他的边界条件。夕张就是这么个边界条件,她是三形态切换,具体的表现就是夕张改二、夕张改二特和夕张改二丁首尾相连都在环中。你需要一个更具有普适性的算法。
想到链表其实是一个有向图,而在我们的问题中,方向并不是很重要,所以可以抽象为一个无向有环图,实际上要解决的问题是非连通无向有环图中判断两个节点是否连通,或者说这两个节点是否在一个集合中。说到这里是不是觉得很熟悉了,刷了题你就应该知道无向图中两个节点是否连通是个非常常见的问题,你可以用DFS,BFS或者并查集来解决。而并查集简直就是为了解决这个问题而存在的。到此为止,这个问题终于有了一个简洁优雅的算法。
算法题没有做到熟练,对于数据结构不够熟悉,你可能要在这个问题上耗费不少的时间写出bug一堆的代码。谁也不知道在实际工作中会不会哪一天就碰到这种问题,如果没有过这种经历的话,恐怕真的到了那个时候才能体味一下刷题的况味吧。
]]>这几周因为工作的原因,要学习k8s的知识,同事推荐了一本Kubernetes in Action,这本书要出新版了(似乎是七八月份,但是现在的情况也不知道还能不能按时出版),所以我就预订了新版的实体书,同时赠送旧版的电子书。因为这个原因我其实在看的是电子版,主要是在iPad上看EPUB。
电子书的体验还是不错的,但是我发现我总是看大概十几二十分钟就走神。也不仅是这本书,之前我看Understanding ECMAScript 6,甚至《重构》Refactoring、The Art of Unix Programming这种经典中的经典也有这种感觉。仔细想想我应该不是单纯的“读不下去书”,而是针对“技术书籍”有点读不下去。
去年回国的时候,家里面有300块的书店代金券,我父母是不怎么读书的人,他们的打算是拿去书店旁边的面包店花掉算了。但是对于体验过美国的书有多贵的我来说,去逛一逛许久未去过的书店是个更好的选择。当天我就去了书店把这些代金券花得差不多了,买了大概有六七本书,然后跨过重洋把它们带回了家。在那之后我花了大概有三个月的时间慢慢读完了其中一本叫做《简明日本古代史》的书,这是本天津社科院的人写的书,说实话挺一般的,因为成书较早所以经常有一些时代特征过于明显的话出现。之后我在这周看完了《日本最漫长的一天》这本书,实际花了大概两天时间读完,这种有点小说性质的,或者说纪实文学的书本身就有情节的跌宕起伏,作者和译者的文笔也都不错,这些因素加起来才让我有了一口气把它读完的冲动。《日本最漫长的一天》我还是挺喜欢的,可能会单独写一篇文章吧。
说句题外话,在我买的那些书里,有一本书叫做《京都》的,我本来以为它是一部简单讲述历史的书,但是我错了,实际上它的内容对于对日本历史,尤其是京都历史不是非常熟悉,也没有在京都常住过的人来说相当晦涩。这本书能在国内出版我有点好奇它的受众群体是谁。
说起来去年我读的最多的大概还是网络小说了吧(笑
为什么技术书我最近有点读不下去了呢?我想第一个原因是技术书籍没有一条情节的主线串联起来,当然对技术书要求情节实在是有点强人所难,但是章与章之间的割裂感很多时候是真实存在的。像Kubernetes in Action,Understanding ECMAScript 6这种书,说实话让我想起来教科书,一个一个的专题,先讲概念,再讲应用、举例子,然后说注意事项。虽然是非常正统的“学习”的感觉,但是我现在已经不是可以在书桌前一坐几个小时的年纪了。
第二个原因我想就是现在让我分心的东西太多了。遥想中学的时候,在家里就是呆在书房里看书写作业。高中在学校就是趴在桌子上做题,没有什么真正的堪称娱乐的东西。但是现在就不一样了,面前就对着电脑,手机就放在旁边,想起来什么事情马上就可以去做,想买个东西就打开亚马逊,想刷推特就拿起手机,时间就这么一点点的消磨掉了。毕竟看技术书哪里有不带脑子看《月曜夜未央》轻松呢,没错我最近沉迷日综《月曜夜未央》。
还有一个原因是对于技术书籍来说,我的知识水平可能也跟以前不一样了。大学的时候图书馆里计算机科学的书随便拿一本我都得一字一句仔细钻研才能勉强弄懂,但是现在拿Kubernetes in Action来说,我只想看有关概念的部分,碰到命令行实例的时候我基本都想跳过,需要的时候再去查文档就好了。这种心态的变化也让我没有以前那么专心了吧。
去年我一共读完了几本书?我想充其量十本左右吧,文档倒是看了很多,毕竟是工作需要。但是果然还是想要更多的通过看书来充实自己啊。
]]>这是我第一次使用Service Worker,也没有花很多时间去研究,所以肯定会有很多疏漏。
单纯发送通知其实是很简单的,只要new一个Notification
就可以了。注意要先用Notification.requestPermission()
申请通知权限。
1 | new Notification("Hi there!"); |
事情到这里进行得还算比较顺利,问题出现在我想要在通知中加入一个重启计时器的按钮,这样我就不用点开计时器的标签了。类似这样的
这种按钮在Notification中称为Action。在Notification
构造函数中有一个Actions
数组,其成员是NotificationAction
,这里面就可以添加你想要的Action了。既然可以添加Action,那么按照JavaScript的惯例,肯定有个地方要添加相应的callback了。对于Notification的Action来说,callback是定义在Service Worker中的。
Notification中的Action不能直接定义在前面那样的构造函数中,而必须通过ServiceWorkerRegistration.showNotification()来定义。
1 | // 这里使用了React的props变量 |
A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don’t need a web page or user interaction.
我的理解是Service Worker是浏览器替网站执行的本地后台进程,前台网页可以把一些background任务交给service worker让它在后台运行,更重要的是,service worker还具有离线运行的能力。
关于service worker的life cycle之类的可以去看前面的Google的文档。
Service worker是一个单独的js文件,需要前台网页来register。我用了register-service-worker这个库来简化这个流程。
1 | import { register } from "register-service-worker"; |
我一开始看到的例子是使用MessageChannel来进行通信,注册SW之后直接通知SW使用全局变量保存channel的信息。问题出在SW在一段时间后(几分钟or几十秒)会被浏览器stop,在有事件的时候会再次唤醒。全局变量会被清除,SW也不能用local storage。
所以要么你在每次show notification之后都重新通知一次SW channel信息,要么使用广播模式。我选择了广播模式
1 | self.addEventListener("notificationclick", (event: any) => { |
Action Workflow:https://github.com/Shell32-Natsu/Shell32-Natsu.github.io/blob/src/.github/workflows/deploy.yml
今天还写了个远征计时的小玩意儿,用React的小App,也用了Action自动部署到GitHub Pages。
]]>text
, we are allowed to swap two of the characters in the string. Find the length of the longest substring with repeated characters.Example 1:
1 | Input: text = "ababa" |
Example 2:
1 | Input: text = "aaabaaa" |
Example 3:
1 | Input: text = "aaabbaaa" |
Example 4:
1 | Input: text = "aaaaa" |
Example 5:
1 | Input: text = "abcdef" |
Constraints:
1 <= text.length <= 20000
text
consist of lowercase English characters only在可以swap一对字符位置的情况下查找最长的相同字符子串。用双指针来搜索这种子串,搜索过程中要注意可以跳过一个字符,记录下跳过的字符的位置,在遇到第二个需要跳过的字符或者字符串结尾的时候判断跳过的字符能不能被swap(也就是找到不在这个子串范围内的可以跟跳过字符swap构成同字符字符串的字符)。
先把每个字符的出现index记录下来,它自然是一个有序的序列,然后在每次查找时使用二分搜索搜索不在找到的子串的范围内的index,如果有那么就是可以swap的。
要注意的有三点:
p2-p1-1
已经必然是一个可行解了,在这种情况下,[p1, p2)
之间是p2-p1-1
个相同字符+1
个不同字符,必然可以swap成一个p2-p1-1
长度的同字符序列。1 | class Solution { |
d
dice, and each die has f
faces numbered 1, 2, ..., f
.Return the number of possible ways (out of fd
total ways) modulo 10^9 + 7 to roll the dice so the sum of the face up numbers equals target
.
Example 1:
1 | Input: d = 1, f = 6, target = 3 |
Example 2:
1 | Input: d = 2, f = 6, target = 7 |
Example 3:
1 | Input: d = 2, f = 5, target = 10 |
Example 4:
1 | Input: d = 1, f = 2, target = 3 |
Example 5:
1 | Input: d = 30, f = 30, target = 500 |
Constraints:
1 <= d, f <= 30
1 <= target <= 1000
基本思路是使用动态规划,有n
个骰子投出m
点的可能数量为sum(n-1个骰子投出m-1的数量, n-1个骰子投出m-2的数量,..., n-1个骰子投出m-f的数量)
。对于每一个d
都要遍历一遍f
个点,每一次遍历中要再遍历一次d-1
时的f
个点所以最佳时间复杂度应为O(df^2)
,在我的实现中因为不知道d-1
时的可能点数的起始位置所以实际遍历了所有d*f
个可能,实际复杂度为O(d^2f^2)
。
1 | class Solution { |
My compay uses BitBucket server. However, although there are several BitBucket server plugins available, all of them are not free (and they are even not cheap!). So far, I just want to invoke a Jenkins job when some events happen. Should we pay thousands of dollars for such a easy (relatively) use case? So I decide to find some free alternatives.
Webhook is a very convenient feature. It’s very simple. Just send a HTTP request to a URL when an event occurs. Fortunately, BitBucket server support Webhook natively, which means you don’t need to install a plugin.
It’s very easy to configure a Webhook. Just follow the documentations.
You need two plug-ins on Jenkins:
You need this plug-in to parse the payload in the POST body sent by BitBucket.
BitBucket will send a POST request to the URL you set. The information is a JSON object in the body. Jenkins cannot parse the JSON object in the body so we need this plug-in.
After intalling Generic Webhook Trigger Plugin, You should set the Webhook URL to {JENKINS SERVER}/generic-webhook-trigger/invoke
.
For more information, see here.
After a Jenkins job finishes, you definitely want to get a notification. Sure, you can choose to send an email to the author or the code reviewer of the pull request. But there is a better way. BitBucket can accept the build status by a REST API (well, another Webhook). This plug-in is used to send this request.
Note that this plug-in only supports username/password credentials but you can use personal access token to secure your password.
When a job finishes, a build status icon will show beside the commit message and pull request if there is one.
]]>