bookmark_border小心审视长期的信任与依赖

说的是我对 google chrome 在技术方面的过度信任。

最近在学习 react + typescript 的组合。本想着我有多年的 react-native 开发和浏览器前端调试的经验,跟着教程一步步走会很顺利,没想到第一步就栽了。

学习新东西第一步都是搭建开发环境嘛,开发环境建成的指标之一就是可以下断点单步调试。

用 typescript 写 javascript 有一个 sourcemap 源码映射问题,就像写 C++ 程序调试时需要有源代码和实际执行的汇编代码的位置对应关系信息,这里设置不好很容易导致断点加不上。chrome 的问题是在 react 程序第一次编译后下断点没问题,但在不重启 react 服务器端的情况下修改代码编译后用 react 的热更新功能刷新页面后,在 chrome 源码页面里加断点就失效了。

我在源码里加入 debugger 命令试了试,chrome 执行到那里会停下来,所以断点功能本身没坏,他只是不认我在浏览器的调试器里实时加上的断点。

搜了一下,这个问题是有官方 issue 的。看评论这似乎是 chrome 的 sourcemap 功能的 bug,最简单稳定的对策是调试时换用 firefox 。
我从 firefox 换到 chrome 有差不多 10 年了。这期间一直知道他们对浏览器标准的实现非常积极,但因为已经习惯了 chrome 和相信 google 的技术力,所以一直没有再用过 firefox 。

现在看来,我对 chrome 的信任是有些盲目了。其实在 react-native 的开发中我就时不时遇到在 chrome 的调试器里取不到特定 scope 里的变量等问题,但出于对 google 的信任,我一直觉得是 facebook 做的不好,对 chrome 竟然从来没有怀疑过。

盲信除了懒惰,也有无知的原因。比如以前我从来不会怀疑 OS,不会怀疑编译器,不会怀疑 IDE,有错一定是我的错。参加工作以后,我遇到过 android OS 的坑,遇到过 gcc 的坑,遇到过 visual studio 的坑。在世界观被他们一次次重铸后,我学会用了批判性的眼光看技术。这次 chrome 的坑没看出来有我对浏览器领域的了解太匮乏的关系,我甚至没有能力定位到这个 bug,即使 chromium 是开源的!

我太菜了,这不行。

立一个 flag, 总有一天我要亲手定位到这个 sourcemap 断点无效的 bug 在代码中的位置。(反正说大话我最擅长了- -)

bookmark_border终于入手aws!

虽然几年前就租了一台阿里云服务器,不过那个主要是用来翻墙回国内的,没怎么正经用过。这次入手aws准备认真熟悉一下用aws管理服务器的各个流程,至少工作项目里在用的那些aws服务想都在自己的账号里摸一遍过过瘾。

为什么观望了这么多年才注册aws账号呢?主要是因为aws新注册账号会立刻开启12个月的免费套餐,注册早了怕浪费,哈哈~

不过这个免费套餐也不是什么都免费,其实额度挺小的,确实符合他们让你熟悉一下产品功能的预期。

新开的服务器要拿来做什么呢?先做个博客吧。

又是博客!没错,和现在这个并行,我想新开个博客了。

是这样的,你看,我这里开了8年,零零碎碎什么都写,尤其最近写了很多心情抱怨之类的,已经开始偏日记用途了。但是程序员嘛,总想搞个技术博客,挂出去不丢人的那种。如果把这里公开到linkedin 啊 github 账号上,被看到那么多私事,一个是很不专业,二来也不好意思。所以干脆分开两个地方写,对公只公开我的技术博客地址,给我的私人空间做一层隔离,两边不会互相添加引用链接什么的。

不过就像我在这里写出来的,我本身并不打算严格隐藏两边博主是同一人的事实。真的对我这个人有兴趣的话读者是可以根据蛛丝马迹找到另一半的我的,这个隔离只是阻隔一下面试官之类一面之缘的人。

说到身份划分,我最近还在考虑小号/马甲的事情。传说中大号岁月静好小号战火纷飞,会是种什么感觉呢?(笑)