光の技术屋

今天整理博客时，恰好瞄到CSDN创作活动里，最近在搞这个主题：如何对待工作中的失误？笔者个人觉得，这个话题是非常有意义的，尤其是在现在经济形势不好，人人都担忧失业的情况下，怎么样对待工作的失误，甚至是工作本身，不论是从心态上，还是从策略（抓手）上，都是值得去深入讨论的。因此，笔者决定为【DIY小记】系列特别撰写一篇文章，来谈一下工作中失误了之后，到底需要如何对待。

那么接下来，就以CSDN创作模板里的几个问题入手，来讨论这个话题吧！

你有想象过用python来写web前端这种操作么？近期在github-trending上就有这样的一个项目reactpy，可以满足你在python上写web前端的欲望。为此，笔者也决定踩踩坑，看看这个项目的形式到底如何，能不能很方便地实际投产。

要用到这个项目，除了reactpy库本身外，还需要一个backend-implementation来部署前端开发环境到本地端口。这里我们采取的操作是pip install reactpy[fastapi]，这样就能直接安装上以fastapi为后端实现的前端开发环境部署。

要开始写一个简单的网页，可以参考reactpy的官方网站。基本代码如下：

大多数的事故来源于变更，这句话并不是妄言，而且确实是具有统计学意义的。在持续集成的过程中，一次发布对应的是一系列的变更，而变更意味着从一个已经稳定的状态切换到一个仅预期稳定的状态，这就导致了线上风险实际是在降低的。为了防止最终的发布的效果与预期不符，造成事故产生，除了对变更内容做业务功能上的测试之外，还需要考虑很多事情，比如分析变更影响到了哪些上下游业务跟服务性能，变更的时间是不是业务的高峰期，变更的行为是不是有更多的相关人员感知。充分考虑了这些因素，每一次变更发布才可以尽可能不产生事故或者事故的影响面被控制住。

对于一个业务而言，发布变更的方式有多种。占大部分的是代码变更，一个新业务的开发，老缺陷的bugfix，或是底层的技术优化，都需要代码变更来直接体现；其次是服务配置的变更，比如遇到特定feature关停或开放的场景，或是调整缓存/DB的容量，抑或是满足业务代码变更的需要，都需要通过配置变更的方式来体现。除这两个大头之外，数据变更也同样是占据一定比例的变更方式。数据变更主要场景有如下几块：

在Golang当中，对于常用数据结构的初始化方式，通常有2种：make跟new。这两种初始化方法用途不同，效果不同。本篇文章就来详细讲一下make和new具体都怎么用，在什么场景下会用上。

首先来看make。比起new，make所用到的场景非常特定，一般没法直接避开。我们看下面的代码例子：

1
2
3
4
5
6
7
8
9

func TestMake(t *testing.T) {
    var m = make([]int, 5, 10)
    t.Logf("[Make] m is %v, len: %v, cap: %v", m, len(m), cap(m))
}

func TestNoMake(t *testing.T) {
    var m [5]int
    t.Logf("[NoMake] m is %v, len: %v, cap: %v", m, len(m), cap(m))
}

两个代码似乎都会初始化长度为5的“列表”m，但其实两个m的内在构造并不相同。实际上会出现如下的效果：

作为一门“网红”语言，rust，已经在区块链、Web前端、游戏开发等领域凸显了作用。相对于golang、python、java、js跟cpp等其余主流语言，rust语言的编写和呈现方面都算是一个更为独立的体系。因此，本着对技术的好奇心，笔者也决定学习下rust语言，一是体验一下新一门编程语言的逻辑艺术，二来也是为未来可能的变化做一做准备。

由于还没有明确要写什么小demo的想法，笔者决定先参照官网rust-by-example给到的代码案例，体验一下rust这门语言是如何做到实现各种基础场景的，心里有个底。官网所有的rust代码案例，笔者一一临摹，记录在了这个repo当中。

2023年ChatGPT系列的问世，可谓是对整个世界的人类造成了冲击。在此之前，人们最多以为AI能够做的事情，主要是下棋玩游戏，但是对话模型AI的到来，造成的效果，是AI具备了和人交流的能力，能够理解人类语言，通过其它AI工作流，自动整合资料，生成人类想要的内容。也就是说，AI可以从事人类的工作了。

很多程序员同行开始恐慌，自己的工作是否会被这类AI所替代，笔者的答案是——不应该会。对于AI，拥抱它的能力，把关它的成果，才是人类程序员需要做的事情，而不是说强行去杠AI的长处。脑细胞再怎么多，大脑也就这么大，而且人类还要生活，管理情绪，大脑不可能100%专注到一个工作。在工作执行方面，AI必然超越人类，但在工作内容把控方面，一切应该由人类定义。如果说你作为一个程序员，过分沉浸在一些八股文知识里，不去构建自己的思维体系，那么从编程工作本身的角度考虑，可怕的不仅是你很难做出更有质量的程序，更甚的是这些工作都正好能被ChatGPT代替掉。这类八股文程序员，才是ChatGPT真正会给到冲击的对象。

在2022年，阿里出品了一本《阿里测试之道》，讲述在阿里电商、物流、金融、大数据等业务场景下，测试活动业务层面是如何开展，以及技术层面是如何实现的。笔者有幸拜读此书，从其中也有所收获。本次以其中涉及电商的测试场景为例，记录一下“大促质量保障”一章的读书笔记。这一章主要讲述了在大促场景下，全链路压测是如何实施的，以及通过什么方式保证最终大促时的生产环境稳定性。

风险与挑战

全链路压测目标：尽可能真实模拟流量洪峰，进行高可用验证
用例场景需要考虑两个方面：

在Golang的各种用法当中，context可谓是最能够体现Golang语言特性的模块之一。context的本意为情境、上下文，而在Golang程序当中，则可以被用于描述一次调用、会话或者任务的状态信息。关于context网上有很多语法以及源码分析的文档，但是里面很多却不能从实战场景体现context的作用，导致这个概念难以理解。因此这一回，经由踩坑context后，笔者将结合自己的理解，给大家讲述context在Golang怎么用来最为方便，怎么理解最为实用。

首先来了解一下什么是context。我们先走源码：

1
2
3
4
5
6

type Context interface {
    Deadline() (deadline time.Time, ok bool)
    Done() <-chan struct{}
    Err() error
    Value(key any) any
}

在源码定义中可以看到，context模块给开发者定义了一个接口约定Context。在先前关于接口的文章中有提到，接口本身定义的是一个实体可以做的行为，那么我们初步理解context的时候，就可以通过Context的定义，知道一个Context可以干什么。

假设一个Context实例ctx，关联到了一次会话，作为当次会话的情境。根据代码定义，Context可以做以下几种行为：

在很久以前的Easy Python系列中，介绍了通过爬虫手段爬取豆瓣电影信息的一种技术套路。今天故技重施，为了迎合先前做SQL语句分析的需要，决定爬取w3schools网站上面所有SQL案例，用作测试用例。

本文就来详细讲述，爬取w3schools网站的实现方式，以及里面需要注意的一些点。代码统一放在这里。

在Golang的实战中，总会遇到一些场景，比如抓包分析sql指纹，或者是输入sql时检查sql的风险，这类操作都需要解析sql的工具才能够生效。今天，就来介绍一些Golang当中解析sql的工具包和使用方法。

本文介绍的工具是vitess-sqlparser，主要结合了两个sql解析工具：

• xwb1989/sqlparser
• tidbparser

其中，xwb1989/sqlparser项目支持的功能有限，尤其对于DDL没有很好的支持，而tidbparser则功能比较全面。下面以tidbparser为例，讲述一下解析以及分析sql里DDL语句的一种方式。

代码相关写法可以查看这篇文章。首先，我们先自定义一个要验证的DDL语句：