If you are interested in software product operations, Dev*Ops or site reliability engineering (SRE), please don’t hesitate to apply it here, or directly contact with me

因为在测试一个安全模块的时候错配了端口，导致我自己无法访问这台虚机，而且一坏就是大半年，囧`

看看今天是不是修好了。发条测试消息试试

为什么我不喜欢微信

微信，也叫WeChat，本应正如其名所指，就是个即时通信的chatting工具。然后，我认为就应该到此为止了。按照这个定义，现在微信中除了聊天和群聊以外的其它功能在我看来都是多余的。但显然腾讯不这么认为，它的目标是把微信变成平台，甚至变成操作系统。按照现在微信的功能设计，以后出现一种里边只有微信的专门设备也一点不奇怪。但我并不喜欢这个产品，就像我不喜欢一切笨重、臃肿、封闭、不可定制的软件产品一样，因为这对我来说就等于复杂，等于丑陋（“小程序”，这真不知道是谁起的名字，丑到爆炸。按照这个起名字的水平，以后出个专门只运行微信的手机，是不是就叫“微机”？然后在发布会上举着走出来说：“我们重新定义了‘微机’…”）。

现在，微信作为一个名词，前面的动词通常是“刷”。微信重度用户通常都会使用“刷微信”这个组合。微信的几个杀手级特性很精准的抓住了很多用户的日常习惯，所以能够让一个普通聊天工具成为几乎大家没事就可以打开刷一刷，而且一刷就可以是几个小时的高黏性应用。这几个特性在我看来是：订阅号，群聊，朋友圈，还有支付。

我个人仍然倾向于将微信作为即时通信工具，所以只有在有消息提醒的时候才会打开看，处理之后立即退出。然而，订阅号的出现让我不得不有的时候要在微信里面多呆一会。不得不承认，的确有一些能够提供优质内容的订阅号存在，它们的文章值得一看，大约就类似传统的报刊杂志吧。但订阅号的问题有三个：一是它们目前绝大多数都是自媒体，内容质量极其没有保障，对于读者的鉴别力要求是很高的（难道腾讯是在用这种方式强行提高很多人孱弱不堪的独立思考能力？如果真是这样，那这盘棋下的很大）；二是系统封闭，成为开放的互联网世界中一块可以随时与世隔绝的独立王国；三是与其它聊天会话并列一起。最后一点是让我最无法忍受的。阅读本应是安静的，纯净的，不受打扰的，所以才会有图书馆，阅览室，书吧。如果要聊天可以去茶馆酒吧咖啡厅。然而在微信里看订阅号，就是有一种在嘈杂的茶馆里阅读的感觉，体验非常不好。互联网上优质内容的聚合阅读本来不应该是这个样子的，只是因为Google放弃了Reader，铸成大错，这个就不提了。当然好在还有Reeder这类产品。我其实希望微信能把订阅号独立出来成为一个专门的应用，聘请一些专业的编辑或AI对内容筛选一下再推送，类似Pocket的推荐文章功能。但腾讯显然不会这么干，因为它希望微信是唯一的入口。

另一个让人厌烦不已的特性就是那个该死的群聊。粗略统计了一下，我的微信里现在有24个群，肯定算少的。当情愿或者不情愿的被卷入各种“群”，情愿或者不情愿的收到各种消息的时候，心情是复杂的：看还是不看，回还是不回，退还是不退群？看，打碎时间；回，耽误时间；不看，红点时刻提醒你有未读消息；不回，被认为高冷，不接地气，不食人间烟火。现在又有了个更坏的：群红包。面对红包，你点不点？我基本不点，一是因为大部分红包都错过了，二是绝不会为了那仨瓜俩枣而暴露自己在看群消息的状态。说实话，有的群（比如500人的小区业主群）真的是充满了噪声，但如果主动退群又似乎是在宣示着什么，而且可能会错过一些重要的消息，尽管这种消息非常非常的少。更重要的是，那些群里的人知道你能看到这些消息，所以有的时候你就不能继续假装自己没看到，尽管有时其实真的不想去看那些消息，或者就真的是没看到。群聊功能很好的满足了很多人喜欢三五成群，聚在一起瞎聊胡侃、传小道消息的爱好，而且把”聚“这个动作以一种成本极低的方式从线下拉到线上，从而诞生出了无数个大大小小，名分各异，或分离或包含或相交的群。

此起彼伏的群聊，
突如其来的红包，
之后是一长串”跪谢老板“的表情包。
热闹，喧嚣，但是我觉得好吵。
你们，
怎么都这么能聊？

以前湖南交通893汽车音乐电台里有句公益广告词是”别被朋友圈圈住了生活“。那时候我就能感觉到其实很多人是被朋友圈绑架的。一边羡慕朋友圈里其他人的生活，一边还要晒自己的生活。生活是为了给别人看的么？生活难道不是首先是为了自己和家庭么？所以我基本不看更不发朋友圈，因为不喜欢把自己晒在那让人品头论足。

对我来说，微信是一个过度复杂的应用，一个很容易将时间碎片化的应用，一个信噪比特别低的应用，一个强行将线下社交拉到线上并用群和圈把用户绑架到”圆环套圆环世界“的应用。

最近时不时的会被问到一些让我哭笑不得的关于德国的问题。这里统一回复一下，不定期更新。

• Q: 听说德国人“骨子里”很看不起亚洲人/中国人，是不是这样的？
  A: 我没有钻到每一个德国人的骨头里去看过，所以我也不知道他们“骨子里”是什么样子的，和法国人、意大利人、美国人等等的骨头有什么区别。但我知道的是，如果一个人想让别人看得起自己，首先要自己看得起自己，然后是多做让别人看得起自己的事，少做让别人看不起自己的事。
  对自己所属的群体有认同感和归属感，对其它群体有防备甚至排斥（当存在利益冲突时）是人类的天性。想想你所属的家庭、班级、小组、学院、学校、公司、省市、国家、党派、民族，支持的球队、乐队……就明白了。贴标签扣帽子这事特简单，也很粗暴。所以，在试图将“个性”推广到群体身上，或者将“共性”应用在个体身上的时候，需要特别小心。
• Q: 听说这两年德国最近难民很多，恐怖活动和犯罪率都在上升，是不是严重？
  A: 最近几年难民是进来不少，但也请关注对于“消化”这些难民，帮助他们融入社会全德国所付出的那些努力。而从新闻和软文中，通常是读不到后面这些内容的。从全欧洲（甚至全世界）范围来看，德国（尤其是南德地区）仍然是治安条件最好的地区之一。然而，社会治安好不代表个人可以没有任何安全意识。自己要学会安全生存的基本规则和如何保护自己的基本方法，这在哪里都是一样的。
• Q: 全世界都知道德国制造（Made in Germany）的品质是超一流的，一口锅一把刀可以用几十年，是真的吗？
  A: 德国制造的品牌品质具有不错的口碑。但是，并不是所有德国市面上售卖的商品都是传言中的那么经久耐用，即使是那些知名品牌的刀，锅，更不用说电子产品。一个东西质量好不好背后其实是个比较复杂的问题，而且很多时候下结论都很主观。一概而论的结论往往是片面和情绪化的。作为消费者，货比三家，理性消费就好了。
• Q: 德国媒体反华？德国总理亲华？
  A: 这么分裂的问题让我该怎么说呢？批评你说你不爱听的就是亡你之心不死，净捡你爱听的说就是爱你的全天候的兄弟？
• 待续…

• New OpenRouteService.org
• New OpenRouteService maps

跟之前的版本相比，最大的变化应该是这次终于向开发者开放了API，目前共四个：

• Geocoding 地理编/解码
• Directions 路径规划，支持驾车（包括货车和特种车等子类）、自行车（包括普通车和山地车等子类）、步行等模式。每种模式都还包含了更多的约束和选项
• Isochrones 可达性分析，支持多种交通工具
• Places 搜索周边，支持在点、线和多边形附近搜索兴趣点，比如说找到一条路径之后沿途搜索加油站这种场景

API的使用目前只提供一个免费套餐（Free plan），以后还会有其它套餐推出，敬请期待。需要使用API的话，请先在[开发中心][3]注册，然后申请免费套餐的API key。申请提交之后，API key会发回到申请邮箱。请注意保管好这个key，一旦遗失我们也没办法找回来，只能重新注册一个新用户再申请。这个版本还有一个比较大的变化就是彻底抛弃了反人类的XML，而改用JSON/GeoJSON作为请求和响应的基本格式。

更多关于这版OpenRouteService (ORS)的详细信息，请参见[官方声明（英文）][1]，如果有任何关于客户端或者是API使用的问题，欢迎随时与我或项目组联系。这里我想补充一点，对于想在中国大陆地区使用ORS的用户来说，路径规划的服务质量会低于欧洲、北美、日本、港台等地区，原因很简单：ORS是基于OpenStreetMap (OSM)数据的，而中国大陆地区的OSM数据质量目前只能呵呵。有朝一日，在有理想有能力的青年科学家们的推动下，中国大陆地区OSM数据质量有质的飞跃之后，ORS的服务质量也会随之大幅提高。相信这一天会很快到来。

• 新版ORS地址：[https://openrouteservice.org][2]
• 开发中心：[https://developers.openrouteservice.org/portal][3]
• API文档：[https://app.swaggerhub.com/apis/OpenRouteService/ors-api/][4]
• 旧版的ORS还会继续运行到五月底，但地址已改：[http://legacy.openrouteservice.org][5]

btw，ORS的web前端是开源的，github仓库地址是[https://github.com/GIScience/openrouteservice-ng/][6] 。如果有关于前端的问题在这里开issue也没有问题。欢迎吐槽拍砖 ：）

[1]: http://k1z.blog.uni-heidelberg.de/2017/04/29/openrouteservice-with-new-api-functions-and-look/
[2]: https://openrouteservice.org “OpenRouteService”
[3]: https://developers.openrouteservice.org/portal “OpenRouteService Developer Center”
[4]: https://app.swaggerhub.com/apis/OpenRouteService/ors-api/ “OpenRouteService API Documentation”
[5]: http://legacy.openrouteservice.org “Old version of OpenRouteService”
[6]: https://github.com/GIScience/openrouteservice-ng/ “openrouteservice web app on Github”

As I experieced many times before, migrating/upgrating a database always hurts. That’s the reason I won’t upgrade my Postgresql to the latest version until I have to. And the day finally comes.

I have to upgrade my Postgresql server from 9.4.9 to 9.6.1 with pg_upgrade. Otherwise, I can not properly install postgis, which is another long story. I am surely not the first one who is doing this upgrading. Olivier Lacan has a great post about Postgresql database migrating. But the thing is, I still can not run the pg_upgrade command properly after unloading the homebrew.mxcl.postgresql.plist. And the most weird thing is I can not even kill the postgres process even with kill -9. After each time I enter the kill command, the postgres services appear again with a new PID just like a ghost virus program. And the pg_ctl stop command, of course, doesn’t work with whatever mode option. Finally, I figure out that there is another pList - homebrew.mxcl.postgresql.plist.bak still active in the ~/Library/LaunchAgents/ directory. And it IS the control script that starting the current Postgresql service. So I immediatly launchctl unload it, then all the postgres services are gone.

All done? Don’t be naive. After running the command

1

pg_upgrade -b /usr/local/Cellar/postgresql94/9.4.9_1/bin -B /usr/local/Cellar/postgresql/9.6.1/bin -d /usr/local/var/postgres.9.4.9.bak -D /usr/local/var/postgres

I got the error (from pg_dump_log):

1
2
3
4

command: "/usr/local/Cellar/postgresql/9.6.1/bin/pg_dump" --host '/usr/local/var/log' --port 50432 --username 'user' --schema-only --quote-all-identifiers --binary-upgrade --format=custom  --file="pg_upgrade_dump_16417.custom" 'dbname=mmrp_munich' >> "pg_upgrade_dump_16417.log" 2>&1
pg_dump: [archiver (db)] query failed: ERROR:  could not access file "$libdir/postgis-2.1": No such file or directory
pg_dump: [archiver (db)] query was: SELECT a.attnum, a.attname, a.atttypmod, a.attstattarget, a.attstorage, t.typstorage, a.attnotnull, a.atthasdef, a.attisdropped, a.attlen, a.attalign, a.attislocal, pg_catalog.format_type(t.oid,a.atttypmod) AS atttypname, array_to_string(a.attoptions, ', ') AS attoptions, CASE WHEN a.attcollation <> t.typcollation THEN a.attcollation ELSE 0 END AS attcollation, pg_catalog.array_to_string(ARRAY(SELECT pg_catalog.quote_ident(option_name) || ' ' || pg_catalog.quote_literal(option_value) FROM pg_catalog.pg_options_to_table(attfdwoptions) ORDER BY option_name), E',
    ') AS attfdwoptions FROM pg_catalog.pg_attribute a LEFT JOIN pg_catalog.pg_type t ON a.atttypid = t.oid WHERE a.attrelid = '28564'::pg_catalog.oid AND a.attnum > 0::pg_catalog.int2 ORDER BY a.attrelid, a.attnum

So it’s postgis’s show time. could not access file "$libdir/postgis-2.1": No such file or directory. Of course you could not access the file because it has already upgraded to 2.3. I tried relaunching the old 9.4.9 server, but failed because all the client toolset are already 9.6.1 which reported incompatibility FATAL error. I feel so helpless. And I think a better workflow should be:

1. Upgrade the postgis extention of your spatial database instances
2. Stop old postgresql service
3. Move old postgresql’s data cluster directory to a backup location
4. Install new postgresql server
5. Init new postgresql data cluster (with initdb)
6. Stop new postgresql service
7. Upgrade postgresql server (with pg_upgrade)

I don’t think there are many choices for me. So I decide using Postgres.app instead, and just give up all the postgresql stuff from Homebrew. I hope that will bring less pain in the future. How about the data? Don’t worry, I still have a running database on AWS.

Kindergartens in Heidelberg

《死神（Bleach）》也要完结了，下下周的686话将是最终话。我本来以为怎么也能凑个700再完结的，但看来98并没有填坑的计划，这也正常，毕竟坑太多了，灵王、星十字、蓝染、零番队、虚圈、破面、假面、完现术等等主线，以及银和乱菊、8600和剑八、现世那边的龙贵等人、一心和龙弦等等花边。

比起火影，我感觉死神的完结更加戛然而止。虽然我觉得说是烂尾，对这二者都多少有些不公，但说这哥儿俩虎头蛇尾还是不委屈他们的。其实这种热血漫画，如果没有在一开始有个比较完整的构思，然后逐步展开，前面挖坑后面填，主线支线配合，正叙与插叙交织，完全可以让读者面对眼前徐徐展开的恢宏画卷而高潮迭起。对没错，我说的就是《海贼王》。比起WT，98和AB还是属于那种想到哪画到哪的类型，当然，他们已经做得不错了。

火影完结的时候，我并没有写点什么，但死神完结我会写，因为其中有我和老婆的美好回忆。想到死神，我就会想起北院那个家属楼。虽然那里简陋的连独立厨卫都没有，虽然它早在几年前就被推掉了，但还是留下了我们很多美好回忆，包括一起看《死神》的日子。

时隔将近20年了，终于又重新做了一次模型。而且这次是EW版的重装高达！与初中那会比起来，总算是做了一回日本原产的正版模型，而且也用了更加专业的工具。前后耗时6小时左右，虽然只是拼接，没有上任何涂装，对切口的处理也比较粗躁，但还是十分令人满意的。对了，目前暂时还没有贴贴纸。

刚刚开始：

完成胸部和头部（到最后安装背包的时候才发现在组装胸部的第二步少装了一个零件，只能拆开补。。）

完成上半身：

完成主体：

手持武器、背包和弹仓安装完成：

来个活力全开的：

转个身：

组装模型是对耐心、细心的锻炼，是有效治愈手残症的良方。虽然正版模型有点小贵，但做工真的是超赞。做完赶紧留影纪念，因为不知道它在大魔王的手里能存活多久…T_T

我觉得今后呢，如果是写技术方面的东西，那么就默认使用英文，而如果是生活吐槽扯淡方面的就用中文，这样是比较合理的。

Let me make a convention about the blog writing language. From now on, the posts will be in English if they are categorized in “Programming”, or in Chinese if they are in “Life”.