如果你经营一家餐厅，食材可以直接市场采购，完全不需要自己种植蔬菜瓜果。如果你想开发一款 AIGC 产品，没有必要自己去开发大模型，调用 ChatGPT、文心一言可能是更好的选择。

文章来源：[链接] 上一篇主要讲了 StatsD + InfluxDB + Grafana 的搭建并用 Grafana 创建了两种图表（Graph）： api 每个接口的请求量api 每个接口的响应时间这一篇主要讲讲两个深入使用 Grafana 的方式： 如何将 Grafana 跟 ELK 紧密的结合起来Grafana 监控报警 Grafana + ELK 在观察 Grafana 监控时，发现某个 api 接...

第 3 个 then 的参数是前两个 then 结果的逆序，即 followers 和 user。更复杂比如嵌套 promise 的我就不列了，这种实现的要点在于：如何区分 then 的层级。从 appoint 的实现我们知道，每个 then 返回一个新的 promise，这导致了无法知道当前 then 来自之前嵌套多深的 promise。所以这个想法无法实现。

twitter 上有一道关于 Promise 的题，执行顺序是怎样？见下图：我们假设 doSomething 耗时 1s，doSomethingElse 耗时 1.5s：

实现 Promise/A+ 规范的库有很多，lie 是一个精简的实现 Promise/A+ 的库，并且通过了 Promise/A+ 专门的测试集，但 lie 的代码写的有点绕，我在 lie 的代码基础上进行了修改，使之更容易阅读和理解，并发布了 appoint 模块供大家参考。Promise/A+ 规范

在石墨，我们之前使用 ELK 搭了一套监控图表，由于一些原因，比如： Kibana 经常查日志查挂 Kibana 的图表不太美观、不够灵活 所以调研了一下，选择用 StatsD + Grafana + InfluxDB 搭建一套新的监控系统。 工具简介 StatsD 是一个使用 Node.js 开发的简单的网络守护进程，通过 UDP 或者 TCP 方式侦听各种统计信息，包括...

前一段时间开始搞优化后端 API 性能的事，发现根本无从下手，Kibana 中虽然有记一些简陋且零散的日志，但也瞅不出啥眉目来。总结了下是日志太少了，所以决定先搞搞日志的事，目标是记录 API 请求相关的日志，找出哪个接口慢，最好具体到哪个函数慢。

多人实时协作是石墨文档吸引人的一大特性之一。使用石墨文档，你可以和同事、朋友同时编写一篇文档或表格，每个人的修改都会实时的同步给其他人。你可以看到每个人光标的跳动，每一个键入的文字。一篇篇运营文案、一份份产品头脑风暴，伴着一杯杯茶与咖啡，就这样在石墨文档上诞生了。美好的事物背后总是充满艰辛。在技...