开发者即服务,是(Developer-as-a-Service)的,亦可称为 “按需即用的开发者”。即当开发者使用某一工具、库,遇到任何相关的问题,可以随时找开发者为我们提供服务。哪怕是使用者使用了我们的 A 框架,但是遇到 B 框架有问题,他/她们也会觉得 A 框架有问题 ——因为 A 框架的开发者们是一种服务,一种开箱即用的服务。
在我短短几年的 TW 生涯里,我经历了多次的角色转换,经历了不同的地域,感觉了不同的文化氛围。
在我当前所在项目里,其中的某一个子系统是用 Groovy 中的 Gradle 插件。Groovy 作为一个运行在 JVM 上的脚本语言,天生具有胶水的特性。加之,它支持 DSL 与其程式的简洁语法。嗯,如果不考虑性能问题,这真的是不一个不错的语言。
现有的项目里,一次功能变更可能带来了大量的缺陷。于是乎,我试着回溯项目的开发过程,寻找出导致问题的根因。现阶段,我只能想到时的只有实施技术战略性投资,也暂时也想不到更好的方法,以在开发初期解决问题。
或许是出自于对编写编程语言的兴趣,又或许是对于创建 IDE/编辑器的兴趣,对于『IDE/编辑器是如何提供编程语言的支持』,我充满了兴趣。其中的一个主要原因是,这是每天我们打交道最多的工具,另外一个原因可能是,咦,我们怎么没有国产的 IDE(手动狗头)。
最近的几个月里,一直在编写代码识别引擎 Scie ,好不容易解决了各种奇怪的问题。随后,在尝试做了一次 benchmark 之后,发现我写了的这么一些 Rust 代码,运行起来的速度非常慢。同样是对一个代码文件的分析,Scie 差不多要 12S 完成,而同样的 Node.js Addons 则只需要 200ms。于是,我开始了我的性能优化之旅。
最近一直在编写 Gradle 以及 Intellij IDEA 相关的东西。由于市面上最复杂的相关的开源软件就是 Android 相关的,即 Android Studio 和 Android Gradle Plugin,于是我也在不断学习相关地源码。所以,我写了很多相关的文章,在介绍相关的内容。文章中包含了大量的技术细节和实现,所以这些技术文章也就只能在我的博客上看到了。
最近在为新的工具 Scie 设计一个模型,以用于描述一个具体的代码工程。而刚好最近也在学习 Gradle 相关的项目模型,便想写一篇文章记录一下相关的模型,以支撑起 Scie 的开发。
最近和同事在使用 Rust 编写 Scie,即重写 vscode-textmate,期间遇到一个严重的 bug,需要调试一下 vscode-textmate 的底层的 vscode-oniguruma WASM 绑定。