原文链接

在日常使用 Goland 时，团队收集了一些可以帮助我们专注于创造的同时减少重复工作的小技巧。
如果你是在 IDEA 中使用的 Go 插件，或者其他 IntelliJ 的产品，同样也有这些特性。

前言

在上一篇中介绍了 xjson 的功能特性以及使用查询语法快速方便的获取 JSON 中的值。

同时这次也更新了一个版本，主要是两个升级：

1. 对转义字符的支持。
2. 性能优化，大约提升了30%⬆️。

前言

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

1
2
3
4
5

decode, err := xjson.Decode(`{"glossary":{"title":"example glossary","age":1}}`)
assert.Nil(t, err)
glossary := v["glossary"].(map[string]interface{})
assert.Equal(t, glossary["title"], "example glossary")
assert.Equal(t, glossary["age"], 1)

但其实转念一想，部分场景我们甚至我们只需要拿到 JSON 中的某个字段的值，这样还需要先声明一个 struct 会略显麻烦。

经过查询发现已经有了一个类似的库来解决该问题，https://github.com/tidwall/xjson 并且 star 数还很多（甚至名字都是一样的😂），说明这样的需求大家还是很强烈的。

于是我也打算增加类似的功能，使用方式如下：

前言

之前在写 gscript时我就在想有没有利用编译原理实现一个更实际工具？毕竟真写一个语言的难度不低，并且也很难真的应用起来。

一次无意间看到有人提起 JSON 解析器，这类工具充斥着我们的日常开发，运用非常广泛。

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

得益于 JSON 的轻量级，同时语法也很简单，所以核心代码大概只用了 800 行便实现了一个语法完善的 JSON 解析器。

前言

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

相关文章在这里：手写一个词法分析器

背景

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

前言

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

背景

许久没有分享 Java 相关的问题排查了，最近帮同事一起排查了一个问题：

在使用 Pulsar 消费时，发生了同一条消息反复消费的情况。

介绍

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

我也是近段时间有机会从零开始重构业务才接触到 gRPC 的，当时选择 gRPC 时也有几个原因：

• 基于云原生的思路开发部署项目，而在云原生中 gRPC 几乎已经是标准的通讯协议了。
• 开发语言选择了 Go，在 Go 圈子中 gRPC 显然是更好的选择。
• 公司内部有部分业务使用的是 Python 开发，在多语言兼容性上 gRPC 支持的非常好。

原文链接

在这篇文章中，我将描述自 Java8 依赖对开发者来说最重要也最友好的特性，之所以选择 Java8 ，那是因为它依然是目前使用最多的版本。

具体可见这个调查报告：