接上文中, 已经支持本地的VSCode客户端连接, 但是我感觉这还不完整, 毕竟VSCode已经推出了Web版, 比如`vscode.dev`以及`github.dev`. 之前对Gitpod的调研提供了一种思路, 在容器或是虚拟机中启动VSCodeWeb再映射出来端口即可. 所以现在这个功能加上去了, 欢迎体验.

我们的平台自从增加了dashboard功能, 从使用者们那边得到的反馈很多, 基本都是不稳定经常断线, 没法传文件这种问题. 说明大家用的很多, 并且希望它能成为稳定的服务. 所以不管从功能性, 还是稳定性的角度, 我都应该考虑下对它进行扩展.

我们平台项目中其实一直在考虑API网关的功能扩展, 目前使用的K8s Ingress以及Istio提供的Istio gateway, 额外功能实在不多, 仅仅能实现暴露接口的需求. 我近期也认真调研了下市场中的API网关产品, 针对这些产品, 简单介绍下功能以及给出一些自己对于未来发展方向的考量. 希望能抛砖引玉. 愿读者分享自己对于API网关的展望.

先前的博客中介绍了我们对K8s定时的使用以及K8s中定时任务的源码实现, 但是实际使用过后, 发现了一些会影响用户体验的问题, 我就这些问题分别探讨下解决方案, 希望能对大家有所帮助, 最后会附上定时任务的使用建议.

自建的K8s集群坑不少, 尤其是到了Node数量越来越多之后, 问题也逐渐显露了出来

Gitpod是一个可以直接打开Github项目的的网页版VSCode, 我一开始使用的时候, 它仅提供了网页版, 使用起来十分不便. 前些天再去试用时, 发现已经可以直接启用本地的VSCode, 类似remote ssh的功能, 感觉这个工具潜力很大, 有兴趣的读者可以自己探索下. 这里我就简单分析下使用方式和原理, 后半部分是对于开发模式和开发工具未来方向的探讨.

之前需要为我们的PaaS增加Webshell功能, 感觉直接复用原生的Dashboard可以减轻很多开发负担, 因此打算进行二次开发, 不过Dashboard本身的权限控制功能太弱了, 而前端的页面多而复杂, 想要结合到我们平台上, 需要精简一下前端, 然后改变后端的鉴权方式, 本篇博客主要介绍如何运行调试程序, 以及具体的裁剪过程.

我个人认为流这样的数据结构存在主要是为了推迟真实执行计算的时机, 仅在数据真的被需要时才会产生出来, 顺便, 它的存在也解决了计算机中如何描述'无限'的问题, 这篇博客主要分享一个流处理的应用--质数筛选.

基本元素是不是真的不可或缺, 如何表现和使用对象的内部状态, 却是可以有不同的思路, 读者可以把它当成是茴香豆的几种写法, 把其中蕴含的逻辑概念理清就可以了.

如何用数学的思路去组织程序, 巧妙的利用一个函数来构造另一个函数