看起来确实非常的挫，其实之前一直也想做一个 GScript 的在线 playground ，于是国庆期间学了一点 皮毛 Vue 加上老弟的帮忙（他是前端开发），最终完成了下面这个网站：

前言本篇文章主要是记录一下在 GScript 中实现递归调用时所遇到的坑，类似的问题在中文互联网上我几乎没有找到相关的内容，所以还是很有必要记录一下。在开始之前还是简单介绍下本次更新的 GScript v0.0.9 所包含的内容：支持可变参数优化 append 函数语义优化编译错误信息最后一个就是支持递归调用先看第一个可变参数：...

前言先带来日常的 GScript 更新：新增了可变参数的特性，语法如下： {代码...} 得益于可变参数，所以新增了格式化字符串的内置函数： {代码...} 下面重点看看 GScript 所支持的运算符重载是如何实现的。使用运算符重载其实也是多态的一种表现形式，我们可以重写运算符的重载函数，从而改变他们的计算规则。 {代码...} 以...

前言在上一篇《终于实现了一门属于自己的编程语言》 介绍了自己写的编程语言 GScript ，在文中提到希望最终可以使用 GScript 开发一个网站。到目前为止确实是做到了，首页地址：[链接]要称为一个网站确实有点勉强，不过也是一个动态网页，因为返回的是 HTML，所以在当前阶段只要不嫌麻烦其实也能写一个“合格”的网站，有...

都说程序员的三大浪漫是：操作系统、编译原理、图形学；最后的图形学确实是特定的专业领域，我们几乎接触不到，所以对我来说换成网络更合适一些，最后再加上一个数据库。

前言上次利用 Antlr 重构一版 用 Antlr 重构脚本解释器 之后便着手新增其他功能，也就是现在看到的支持了作用域以及函数调用。 {代码...} 整个语法规则大部分参考了 Java，现阶段支持了：函数声明与调用。函数调用的入栈和出栈，保证了函数局部变量在函数退出时销毁。作用域支持，内部作用域可以访问外部作用域的变量。...

前言在上一个版本实现的脚本解释器 GScript 中实现了基本的四则运算以及 AST 的生成。当我准备再新增一个 % 取模的运算符时，会发现工作很繁琐而且几乎都是重复的；主要是两步：需要在词法解析器中新增对 % 符号的支持。在语法解析器遍历 AST 时对 % token 实现具体逻辑。其中的词法解析和遍历 AST 完全是重复工作，所以...

前言最近在持续优化之前编写的 JSON 解析库 xjson，主要是两个方面的优化。第一个是支持将一个 JSONObject 对象输出为 JSON 字符串。这点在上个版本中只是利用自带的 Print 函数打印数据： {代码...} Output: {代码...} <!--more-->本次优化之后便能直接输出 JSON 字符串了：实现过程也很简单，只需要递归遍历 obj...

前言在上一篇中介绍了 xjson 的功能特性以及使用查询语法快速方便的获取 JSON 中的值。同时这次也更新了一个版本，主要是两个升级：对转义字符的支持。性能优化，大约提升了30%⬆️。转义字符先说第一个转义字符，不管是原始 JSON 字符串中存在转义字符，还是查询语法中存在转义字符都已经支持，具体用法如下： {代码...} ...

在之前实现的 JSON 解析器中当时只实现了将一个 JSON 字符串转换为一个 JSONObject，并没有将其映射为一个具体的 struct；如果想要获取值就需要先做断言将其转换为 map 或者是切片再来获，会比较麻烦。

以前我也有思考过它是如何实现的，过程中一旦和编译原理扯上关系就不由自主的劝退了；但经过这段时间的实践我发现实现一个 JSON 解析器似乎也不困难，只是运用到了编译原理前端的部分知识就完全足够了。

最近又在重新学习编译原理了，其实两年前也复习过，当初是为了能实现通过 MySQL 的 DDL 生成 Python 中 sqlalchemy 的 model。

前段时间同事碰到一个问题，需要在 SpringCloud 的 Feign 调用中使用自定义的 URL；通常情况下是没有这个需求的；毕竟都用了 SpringCloud 的了，那服务之间的调用都是走注册中心的，不会需要自定义 URL 的情况。

大概在两年前我写过一篇 撸了一个 Feign 增强包，当时准备是利用 SpringBoot + K8s 构建应用，这个库可以类似于 SpringCloud 那样结合 SpringBoot 使用声明式接口来达到服务间通讯的目的。

背景许久没有分享 Java 相关的问题排查了，最近帮同事一起排查了一个问题：在使用 Pulsar 消费时，发生了同一条消息反复消费的情况。排查当他告诉我这个现象的时候我就持怀疑态度，根据之前使用的经验 Pulsar 在官方文档以及 API 中都解释过：只有当设置了消费的 ackTimeout 并超时消费时才会重复投递消息，默认情况下是...

我猜测大部分长期使用 Java 的开发者应该较少会接触 gRPC，毕竟在 Java 圈子里大部分使用的还是 Dubbo/SpringClound 这两类服务框架。

前言最近实现某个业务时，需要读取数据然后再异步处理；在 Go 中实现起来自然就比较简单，伪代码如下： {代码...} <!--more-->看似非常简单几行代码却和我们的预期不符，打印之后输出的是： {代码...} 并不是我们预期的： {代码...} 坑一由于写 go 的资历尚浅、道行更是浅薄，这 bug 我硬是找了个把小时；刚开始还...

前言早在几年前写过关于 LRU cache 的文章：[链接]当时是用 Java 实现的，最近我在完善 ptg 时正好需要一个最近最少使用的数据结构来存储历史记录。ptg: Performance testing tool (Go), 用 Go 实现的 gRPC 客户端调试工具。Go 官方库中并没有相关的实现，考虑到程序的简洁就不打算依赖第三方库，自己写一个；本身复杂度...

前言平时大家写完 gRPC 接口后是如何测试的？往往有以下几个方法：写单测代码，自己模拟客户端测试。可以搭一个 gRPC-Gateway 服务，这样就可以在 postman 中进行模拟。但这两种方法都不是特别优雅；第一种方法当请求结构体嵌套特别复杂时，在代码中维护起来就不是很直观；而且代码会特别长。第二种方法在 postman 中与...

前言前段时间有个项目即将上线，需要对其中的核心接口进行压测；由于我们的接口是 gRPC 协议，找了一圈发现压测工具并不像 HTTP 那么多。最终发现了 ghz 这个工具，功能也非常齐全。事后我在想为啥做 gRPC 压测的工具这么少，是有什么难点嘛？为了验证这个问题于是我准备自己写一个工具。<!--more-->特性前前后后...

不知不觉写 Go 已经快一年了，上线了大大小小好几个项目；心态也经历了几轮变化。因为我个人大概前五年时间写的是 Java ，中途写过一年多的 Python，所以刚接触到 Go 时的感觉如下图：既没有 Java 的生态，也没有 Python 这么多语法糖。写到现在的感觉就是：这里就不讨论这几门语言谁强谁弱了；重点和大家分享下我们日常...

日常开发中我们大概率会遇到超时控制的场景，比如一个批量耗时任务、网络请求等；一个良好的超时控制可以有效的避免一些问题（比如 goroutine 泄露、资源不释放等）。

前言设计模式不管是在面试还是工作中都会遇到，但我经常碰到小伙伴抱怨实际工作中自己应用设计模式的机会非常小。正好最近工作中遇到一个用观察者模式解决问题的场景，和大家一起分享。背景如下：在用户创建完订单的标准流程中需要做额外一些事情：同时这些业务也是不固定的，随时会根据业务发展增加、修改逻辑。如果直...

这样对切片的声明，先不看后面两种写法；单独看 []*T 还是很好理解的：该切片中存放的是所有 T 的内存地址，会比存放 T 本身来说要更省空间，同时 []*T 在方法内部是可以修改 T 的值，而[]T 是修改不了。

最近在实现两个需求，由于两者之间并没有依赖关系，所以想利用队列进行解耦；但在 Go 的标准库中并没有现成可用并且并发安全的数据结构；但 Go 提供了一个更加优雅的解决方案，那就是 channel。

前言最近用 Python 写了几个简单的脚本来处理一些数据，因为只是简单功能所以我就直接使用 print 来打印日志。任务运行时偶尔会出现一些异常：因为我在不同地方都有打印日志，导致每次报错的地方都不太一样，从而导致程序运行结果非常诡异；有时候是这段代码没有运行，下一次就可能是另外一段代码没有触发。虽说当时有注...

背景我们最近在做新业务的技术选型，其中涉及到了对消息中间件的选择；结合我们的实际情况希望它能满足以下几个要求：友好的云原生支持：因为现在的主力语言是 Go，同时在运维上能够足够简单。官方支持多种语言的 SDK：还有一些 Python、Java 相关的代码需要维护。最好是有一些方便好用的特性，比如：延时消息、死信队列...

最近公司内部项目的发布流程接入了 GitHub Actions，整个体验过程还是比较美好的；本文主要目的是对于没有还接触过 GitHub Actions的新手，能够利用它快速构建自动测试及打包推送 Docker 镜像等自动化流程。

前言最近在用 Go 写业务的时碰到了并发更新数据的场景，由于该业务并发度不高，只是为了防止出现并发时数据异常。所以自然就想到了乐观锁的解决方案。实现乐观锁的实现比较简单，相信大部分有数据库使用经验的都能想到。 {代码...} 需要在表中新增一个类似于 version 的字段，本质上我们只是执行这段 SQL，在更新时比较...

前言首先还是祝大家新年快乐，虽然还有300来天。哈哈，圆规正传。近三年每年我都有写年终总结，每次看上一年的新年计划时心里就会骂一句：TMD 又白写了；当然今年也不例外。虽说计划对我来说意义不大，但回顾一年的重要事项用于茶余饭后的谈资还是很有用的。回顾依照惯例还是首先回归下 2020 这一整年对我来说有哪些重要...