我在新加坡一个月的生活费明细

来新加坡之后经常被很多朋友咨询在这边的生活水平如何,一个月会花多少钱。2020 年在世界房价前 5 名中新加坡的房价占据第三,生活水平成本占据第四。这会吓到很多想来新加坡工作的朋友。这些数字相对于个体来说可能反应不了什么,比如是否开车、从事什么职业,年收入多少,这些对于生活成本都会有不同的理解。

本博客的读者可能都是和我一样的程序员,所以我想我个人的数据对于读者来说可能具有更大的意义。

我一直有用 Beancount 记录账目的习惯,因为一月份我购买了很多家具,以及花了一些中介费(半个月的房租)、酒店费用等用来安顿下来,所以可能没有什么参考价值。二月份的开销相对稳定,所以可以在这里分享一下自己的账目。以供大家参考。

2月份一共花费 3797.18 SGD。其实不全是日常的生活费用,但是为了真实,我也记录一下这些额外支出吧。以下用一个缩进列表描述每项的花费内容。以下货币都使用 SGD,汇率可以按照 1SGD=4.85CNY 来计算。

3797.18

  • 1536.79 住房
    • 1400 房租
    • 25 宽带
    • 86.89 水电煤气
  • 89 衣服
    • 在新加坡只穿的到 T 恤,所以穿衣方面是很便宜的。我2月份只买了一双 Vans 的经典款的板鞋,比国内的电商略贵一些
  • 1413.6 其他
    • 18 银行续费:往国内汇了一笔钱,使用的汇款公司每笔汇款收取固定手续费18新币
    • 83 去迪卡侬买了一些游泳装备,迪卡侬的价格跟国内基本一致
    • 2.6 和同事去公共泳池游泳,每次 1.3 新币,很便宜
    • 1310 情人节给老婆买了个包,奢侈品的价格比国内便宜很多,可以直接参考官网
  • 755.79 日常生活
    • 678.84 吃饭
      • 200.49 年夜饭
        • 新年请大家来我家吃火锅,买的东西比较多,导致我们从七点钟吃了一晚上,吃到第二天4点,聊得很 high……
      • 478.35 日常吃饭
    • 76.95 交通
      • 13.50 打 Grab 出租车(其实公司 2.2 大促还打了两次,不过公司报销了,不记录了),大约5公里,打车还是比较贵的
      • 61.65 日常通勤坐公交车

可以看到如果不算买的礼物的话,一个月正常的衣食住行大约是 1万2 人民币左右。如果不算过年我们买了一些年货的话,1万人民币完全没有问题的。另外2月份好像出去吃饭的次数也比较多,看了下大约下馆子了十五六次……

费用解释

首先大头是房租,新加坡租房确实比较贵,我和朋友整租了一整套,可以理解成所有的费用我只支付了一半。比如宽带实际是 50/月,等。这个价格的房子在市中心的区域,去乌节路只需要20min左右,去公司15min左右。楼下就是地铁站(<30m)超市(<50m),带有游泳池,健身房,公共休息室,桑拿室,网球场等,住在30楼,楼前面无遮挡,能看到半个新加坡,视野非常好。所以如果要比的话,同样的价格在上海市租不到这种房子的,也没有贵的离谱。之前跟银行的经理聊过,他们5个人租的 HDB,每个人400新币。HDB 是新加坡为了实现“人人有房住”的住房项目,有很多优惠政策给真正需要房子的人,比如你买 HDB 有 N 年内不能出售,收入限制,名额限制等。如果有资格买的话,首付比上海要低太多,月供基本无压力。HDB 的缺点是没有泳池等设施,小区没有围墙。但是这些问题都不大,新加坡的公共泳池有很多,也很方便。

然后是交通,交通是比较贵的,公交做一次新币要 1元起,算成人民币要五六块了。但是没啥办法,太热了,不想走路。

吃饭。这个是很便宜的,因为新加坡的食阁到处都是,类似于大学时候的那种食堂,平均 5 新币一餐。但是偶尔要出去改善一下的话,就确实比较贵了。按照菜单价格点完菜之后要加收 10% 的服务费和 7% 的消费税。注意并不是✖️1.17,而是 x 1.1 x 1.07,即 x 1.177。

这是我截取的一段日常账本:

 

写油猴脚本的传统艺能(Tampermonkey)- 教程

如果你在一家大公司工作,十有八九要面对百十个内部的所谓“自研系统”——大部分体验都非常拉跨。自研 SCM 的,自研 Ticket 系统的,自研文档系统的,还有一些很神奇的、搞不懂明明有很好的开源系统为啥不用偏要自研的系统。

不管出于什么原因,我们的大公司自研了这些系统,他们无一都有着一个共同点:体验很糟糕。包括:使用了先进的 SPA 技术但是 90% 的内部系统都没办法处理好 Url 的前进后退历史,翻页过滤等保持状态,甚至很多系统干脆就只有一个 URL: 比如 xdb.alipay.com…… 好吧,我猜这些都是专业团队开发的,专业领域比较强但是缺一个“专业前端”吧。

在这种环境中生存,尤其是作为一个“专业”的 SRE,我们就需要一些传统艺能:Python 爬虫,浏览器模拟器爬虫,油猴脚本。帮助你在各种险恶的内部系统中存活。

本文试图用 30 分钟(请现在开始计时)学会写油猴脚本,希望能在你快乐的 SRE 生涯中每天节约你几分钟的时间。

首先,先介绍下油猴脚本是什么(如果你真的不知道的话,我感谢你读到现在还没有走):油猴,Tampermonkey,是一个 Chrome 插件。我们都知道,JavaScript 本质上是客户端,就是运行在客户这边的软件。那么当客户这边的软件用着不爽的时候,客户是不是可以直接去修改软件呢?毕竟 JavaScript 也是脚本语言。当然可以!客户就是你,油猴就是帮助你修改 JavaScript 页面的软件。

油猴运行的方式是,你可以写一个 JavaScript 脚本,然后指定在什么 URL 运行,当你用浏览器打开这个 URL 的时候,油猴就会运行你的 JavaScript。这样,我们就可以把这些拉跨的网站变成我们想要的样子。

接下来我们安装油猴插件,Chrome 搜索安装即可。

安装好之后,我们来写你的第一个油猴脚本。

题目如下:你(其实是我自己)用 Roam Research 来记录工作笔记,你的公司用 JIRA 作为工单系统。每次你在处理一个工单的时候,你希望把这些过程都记录下来。比如你处理一个 URL 是 https://jira.mycompany.io/browse/IT-25582 的工单的时候,你想以下面的形式开始在 Roam Research 里面做记录: [[Ticket/IT-25582: Fix Alice's Computer]] ( https://jira.mycompany.io/browse/IT-25582 ) #IT #Computer #Alice。现在你是怎么做的呢?你要复制 Url,复制标题,复制工单编号,然后复制标签,最后在 Roam 里面打出来这句话。2分钟过去了……

所以我们希望能够一键做这个事情。效果是在“分享”按钮的后边会有一个一键复制的按钮,按下这个按钮,就会自动在你的剪切板插入这段格式的文本。然后你只要去 Roam 里面粘贴就可以了。

原理是:

  1. 从页面中使用 JavaScript 拿到标题,Url,标签等,拼出来要粘贴的内容
  2. 然后在页面上找一个合适的地方,加上我们的 Copy as Roam 的按钮
  3. 最后加一个监听的函数,这个按钮按一下,就把这段拼出来的文本放到剪切板里面去

首先,第一步,我们从页面找拿标题。这一步没什么难的,就是使用 JavaScript 的 API document.querySelector() 把想要的东西都拿出来即可。然后拼成一段文本。

然后,第二步,操作剪切板的函数(咦?不是加按钮吗?那太难了,待会在搞)。操作剪切板现在已经有 API 可以直接操作了。在这里我们需要搞一个假的 textArea, 然后把文字填进去,复制到剪切板。

最后一步,添加一个按钮。听起来这应嘎是最简单地一步,只要找到一个 Element 然后 Append 就好了,但确实最难的。因为现代网页用 JavaScript 太多了,你要找的 Element 也许根本就不存在。

解决方法是使用一个循环,延迟这个操作,一旦发现元素,则停止循环。

还有一个难点,因为 SPA 都是编译出来的,所以很可能整个网页都没有什么 id 可以用,如果有,它们的值也是每次编译自动生成的。这很头疼,我也没想到什么好办法,只能祝你好运了。

另外添加元素的时候,可以不比写自己的 CSS,直接 Copy 一下旁边的按钮的 class 用就好了,可以完美地混入其中。

油猴的原理大致就是这样,如果你要做的事情,八成就要去看浏览器提供了什么样的 API 了。大部分情况也不必自己从头开始写,一般有人做过类似的事情了,可以直接去搜索一下现成的脚本改一改。比如我这个教程,其实源代码就是抄了别人的。只不过我觉得他写的太繁琐了,就改了一些内容。

PS:量子幽灵 提醒我可以使用 MutationObserver 这个 API,这个 API 可以直接在某个 DOM 出现的时候去调用一个回调函数。

 

完整的脚本如下,贴在这里也没法直接用,但是相似的事情可以基于这个改一改。

 

如何杀死一个进程?

我们最近在实践 Chaos Engineering,而实现的一个最简单的 Chaos,就是 kill 一个进程。即使是这么一个简单的 Chaos 实验,我也遇到不少有意思的问题,这里记录一下。

首先介绍一个 trick,我们在 Linux 上查找进程的时候,一般会使用 ps -ef | grep nginx ,但是这样一般会在结果中得到两个进程,一个是找到的进程,另一个是 grep 本身。

那么怎么让 grep 不要出现在结果中呢?

比较简单的一种方法是,再 grep 一次就可以啦: ps -ef | grep nginx | grep -v grep 。高级一点的方法可以这样:ps -ef | grep [n]ginx 。原理是 grep 接收一个正则表达式,这样虽然最后还是 match 的 nginx 本身,但是我们运行的命令因为加了 [] 就不直接含有 nginx 这个字符串了。

但是如果要直接 kill 掉进程的话,大可不必先 grep 出来再执行 kill,直接使用 pkill 命令就可以了。

我用来测试的进程名字叫做 host-networking-manager,所以 pkill host-networking-manager ,但是返回的竟然是 1?没成功吗?看了一下,果然没成功,为什么?

最后折腾了一顿发现,pkill 其实是用 pgrep 去找到进程 kill 的。pgrep 找到目标进程是通过 /proc/[pid]/stat 文件。这个文件中的进程名字其实是只有 15个字符长度的。答案在 man 2 prctl 里面:

PR_SET_NAME (since Linux 2.6.9)

Set the name of the calling thread, using the value in the location pointed to by (char *) arg2. The name can be up to 16 bytes long, and should be null-terminated if it contains fewer bytes.

Linux 中的每一个进程都有一个 struct_task_struct 结构体,这个结构体定义在 include/linux/sched.h 里面。

这里面有一个字段 char_comm[TASK_COMM_LEN] 定义了可执行文件的,不包含 Path 的名字,最大长度是 16 bytes,除去最后一个留给 null 的,就只有最多 15 个字符。

可以打开 /proc 下的文件看一下:

所以说,正确 kill 这个进程的方式应该是 pkill host-networking 。

或者使用另一个方法,pkill -f host-networking-manager -f flag 会告诉 pkill 使用 /proc/pid/cmdline 这个文件来匹配进程。这个文件里面包含了进程启动的时候的完整命令,包括参数。(为什么这里我要高亮呢?请继续阅读……)

在尝试使用 -f 参数的时候,我遇到了一个诡异的现象。比如我使用我的 chaos 程序运行一个 yaml 定义的实验的时候。chaos run kill-host-networking-manager 我的实验自己会退出…… 从 log 的信息来看,它也收到了一个 kill 命令。

就在我百思不得其解这个 kill 信号是哪里来的时候,在高人的指点下,原来是我自己发的…… 当我使用 pkill -f host-networking-manager 的时候,由于执行这个命令的进程本身也有 host-networking-manager 这个名字(chaos run kill-host-networking-manager)所以它自己也会匹配上。相当于自己也会把自己杀掉!

那么为什么不使用 -f 参数就没有问题呢?因为在 /proc/pid/stat 文件中,我的父进程叫做 chaos 所以不必匹配到……

 

另外几种比较准确地根据一个名字杀掉进程的方法:

  1. 如果使用 systemd 启动的,可以使用这个命令查看 PID systemctl show –property MainPID <unitfile>.service
  2. pidof 命令也可以准确地找到进程的 PID。

以上 Tips 是 GrayCode 提供的。

 

接手一个新的项目,我会关注的3个问题

作为 SRE,在工作中,接手一个新项目是很平常的事情。离职、入职、组织结构调整等,都可能会让你来接手管理一个项目或者组件。在 take over 的时候,我总结了一些需要关注的重点问题。

1. Where did it deploy?

项目部署在哪里?这是最重要的一个问题。是直接部署在物理机上,还是部署在容器上?是用什么方案部署的,如果发布新的版本,发布的流程是怎么样的?

可以到机器上看下都有哪些进程在运行。如果是一个中间件,可以尝试使用这个中间件写一个小 demo 体验一下。

最好是能画出来部署的架构图。

2. How do we monitor?

当前的部署结构算是一个静态的,那么监控就相当于是一个动态的。

监控可以告诉你当前系统的请求量,系统的运行状态。以后的工作中可能打交道最多的也是监控了。所以学会看懂监控非常重要,需要针对当前的监控面板,问清楚每一个指标代表了什么。

然后,可以从项目所要解决的问题上,去评估,哪些指标可以告诉我们当前的服务状态,发现核心服务的状态需要哪些数据。从而也可以评估当前的监控是否完善。告警是否设置了,设置的是否合理。

3. Where is the code?

以前我可能会问:“这个项目的文档在哪里?”,但是我发现,文档要么是过时的,要么是一团糟,要么没有。但是软件要想跑起来,没有代码是不可能的,所以不如直接问一下代码在哪里?代码中什么都有。(当然,如果有文档更好)。

在开发者和 SRE 之间划一条线,代码的逻辑从不过问,遇到问题就找到开发者说“帮我看下这里问题出来哪里了?” 这样是做不好工作的。我认为一个合格的 SRE 首先要是一个好的程序员。

SRE 看代码可能更会专注于配置类,这个项目是如何连接数据库的,是如何发现其他的服务的,是如何部署在服务器上的,有哪些项目是可以配置的,配置是什么管理的。以及这个项目选择的一些依赖,用了什么开源项目。

如果不去做问题 3,那么了解部署结构、了解监控,也都是做不好的。很多工作只有清楚了代码的逻辑才能进行得更加深入。

如果有时间,多去看看项目的逻辑代码,也是挺有意思的。可以对比一下类似的产品的处理方式,也可以和同事互相学习,了解同事的品味。

 

交接的时候,主要的问题问清楚这些基本就可以了。然后先熟悉一段时间,再发现其中的问题,比如发布流程是否合理,有些运维工作是否能够自动化。慢慢地读代码,搞懂逻辑,再发现更多可以优化的事情。SRE 是和项目一起成长的。

 

React Hooks 基础教程

最近在写一个前端页面,看了一个 UI 框架的 Example,发现已经看不懂 React 了。上次写 React 的时候,还都是用 Class Based Component, 我还花了一些时间弄明白一个组件的“生命周期”,没想到这么短的时间,已经不流行使用 Class 写组件了。现在用一个叫 React Hooks 的东西,可以通过函数写出来组件。为了看懂现在的 React 代码,我又去学了 Hooks,这边文章来总结我对 Hooks 的理解。

Hooks 就是一些 React 提供的内置函数,通过 Hooks 就可以在 Function 中操作组件的状态(state)了。在我看来解决了两个问题:

  1. Function 中是不可以定义 state 的,所以以前 Function 只能用来写 stateless 的组件,如果有一天你觉得这个 stateless 的组件要加入状态了,那就必须把它先变成 Class Base Component 才行;
  2. Class 组件本身也有问题,它这个设计是要求开发者按照组件的生命周期来写代码,constructor() -> componentDidMount() -> componentWillUpdate() 这种方式,按照 React 的逻辑来组织代码,而不是按照代码本身表达的业务逻辑来组织代码。以前每次写一个新的组件的时候,我都要依靠 Vim 的模板功能生成一个代码模板,但是现在不需要了。写 Hooks 几乎没有模板代码。

通过例子认识 Hooks

下面这个例子来自官方的文档。

在这个例子中,使用 useState() ,让这个组件 “hook” 了一个 React 的 state:count 。count 的初始值就是 useState() 的参数,即0. 如果要改变 count 的值,就使用 setCount 这个函数。(之前是使用 this.setState() )。

可以这么理解,useState() 函数就关联了一个 React 的 state,调用 useState() 会给你 state 的应用,以及更新它的方法。(Hooks 都使用 “use” 开头,为什么不使用 “create” 呢?因为它只是和一个 state “关联”起来了,只是告诉 React “使用”这个 state。只有在组件第一次 render 的时候才会创建这个 state,在后续的更新中并不会创建了。)

另一个 React 提供的 hook 是 useEffect() 。如它的名字,这个 hook 不是和 state 有关的,而是产生 “effect” 的。类似于 React Class 中的 componentDidMount() 或者 componentWillUpdate() 中。

比如下面这段代码:

组件第一次更新的时候会调用 useEffect() 收到的函数,并且以后这个组件每次 render 的时候也会调用:更新页面的标题。

可以看到这里面没有和 React 组件生命周期相关的函数名字。这意味着我们可以根据业务逻辑来组织代码,可以将 effect state 等相关的逻辑放在一起,而不是把多个不相关的业务逻辑,都放到 componentDidMount() 里面去。

之前的这种按照组件生命周期来组织代码的方式,很容易出 Bug。比如,下面是一段正确的代码。这个组件订阅了朋友的在线状态,当组件 Unmount 的时候,会需要取消对这个朋友的状态订阅:

但其实 componentWillUnmount 这个函数非常容易忘记(尤其是在逻辑越来越多的情况下),造成内存泄漏。

如果用 useEffect() 来实现的话,就比较清晰了,因为这个函数接受的参数是 Effect 的函数,Effect 函数的返回值可以是一个 clean up 的函数。(好像比较绕,这个设计确实有些奇怪,为什么不将 clean up 的函数作为 useEffect 的第二个参数呢?)

useEffect() 来写的话,就是下面这种形式:

把更新的函数传给 useEffect() ,然后在自己的函数里面返回一个 callback 用来 cleanup. 因为这些逻辑都是在一起的,所以更加不容易忘记。

另外,useEffect() 会在组件 Mount 以及每次更新的时候都运行,相当于 componentDidMount() 和 componentWillMount() 两个函数合起来了。

Hooks 的原理

一个函数中可以使用 Hooks 多次,用来关联不同的 state,比如下面这段代码:

但是在调用 useState() 的时候并没有告诉 React name 是和哪一个 State 来关联,React 是怎么知道的呢?

答案是调用顺序,你按照这个顺序使用 Hooks,React 就按照这个顺序给你赋予这些 state 的值,“绑定”的过程类似下面这样:

所以顺序至关重要,知道这一点,就可以避免一些错误的使用方法。比如,一个原则是,只在 Component 的最顶层使用 Hooks,假如你没有函数的最顶层使用 Hooks,而是在嵌套结构(比如循环或者 if block 中)使用,那么绑定的时候就会出问题。

比如像下面这样:

那在 React 实际绑定组件的内部状态的时候,就会乱掉:

另一个原则是,只在 React Function Components 里面使用 Hooks。如果只在 Function Component 里面调用 Hooks 的话,你看到一个 Component 就会知道里面的 State 的变化,但是如果状态还在 Component 外面被控制,那么就很难管理了。并且 React Hooks 应该也不会在 Component 之外去帮你管理这些状态。

定义自己的 Hooks

没有 Hooks 以前,如果要抽象一部分涉及 state 的代码出来复用的话,只能再写一个 Class Component,现在可以用 Hooks 了。我们可以定义一个自己的 Hook。

比如,重用一段 Friend 订阅上下线的逻辑:

Hooks 里面会调用其他的 Hook,当然,也只能在最顶层来调用

我们自己定义的 Hooks 不像是 React 内置的那些一样参数都是固定的,Hooks 本质上就是调用了其他的 Hooks 的函数,所以我们可以自定义自己的参数和返回值:

  • 订阅一个朋友的状态:所以接收的参数是 FriendId
  • 提供的是朋友的状态,所以返回一个 onlineStatus

在 React 的视角,即使你 call 的是你自己定义的 Hooks,但是最终里面,还是调用的 React 定义的 Hooks。所以最终,你都只调用了 React 提供的 Hooks。就像我们所有的程序调用的函数最终只调用到了系统提供给我们的函数一样。

参考资料:

  1. https://reactjs.org/docs/hooks-intro.html