最近cs2更新了之后，因为总是解决fps过高的问题，导致游戏性能降的非常明显。笔者组的老土机子先前一直没有搞超频，现在也不得不睿一下保证游戏能够稍微流畅的运作，最终比以前稍微提升了50fps左右，cs2的dust2-benchmark地图能勉强达到平均400fps。本文就分享一下笔者在这块的粗浅经验，有什么技术概念性问题也麻烦大家指正。
配置方面，笔者主板是微星z690刀锋ti，cpu是i9-12900kf，散热用的追风者冰灵m25-360，gpu是3070ti，内存是一个比较简陋的ddr4，当然ddr5主板也没法支持，可以说整体是非常乞丐了。
最近在重玩pyside/pyqt桌面开发的内容，计划做一些日常工具来自用，顺带练练手。正好刚遇到一个问题是画时钟（表盘+数字），查了很多资料都稍微调试了下才最终解决，本文即分享一下解决方法。
首先是数字时钟。由于pyside6本身有QLCDNumber控件的支持，所以绘制起来比较容易，官网也给了一个例子。笔者自己则在这个基础上做了下修改，代码如下：
研发测试不分家，在AI时代，LLM/GPT技术的冲击之下，不论是研发还是测试人员都可能会担忧，AI是否会取代自己的工作。从笔者的角度看来，这根本不是一个需要担心的问题，就和围棋一样，在AlphaGo之后，大家都会利用AI来学习围棋，超越以前时代的人。而作为研发或者测试人员的你，也可以利用AI技术的产物，实现进一步的自我提升。
今天，笔者决定简单聊一下，AI时代下，研发测试人员实现自我成长的一些方法。
对于一个程序员而言，拥有一套合理的编程工具集，便可以让编程工作事半功倍。本篇文章就分享下笔者当前使用的一些实用提效的编程周边工具。
首先需要声明的是，DIY一套编程工具，一定需要贴合自己的工作或者生活需求。好比说，你是前端，你是后端，或者你是搞安卓iOS客户端的，搞图形学渲染的，那肯定用到的工具都不一样。笔者主要工作是互联网后端方向，也兼顾一些前端开发、桌面工具之类的全栈开发内容，一般用Macbook做开发，而不是像游戏程序员一样用Windows比较多。所以本文分享的一些工具，虽然看起来比较普罗大众，但也有一定的倾向性。
日常工作总是琐碎的，尤其是技术岗，沉浸在日常的需求开发、需求测试和bugfix里，很容易对工作环境形成依赖，导致没有成长空间。那么这种情况下，怎么样去平衡日常工作和自我的学习提升呢？今天，笔者就通过这篇文章，分享下自己的观点。
核心的思想是：工作只是生活的一部分，要自己掌控自己的生活，不要让工作掌控自己的生活。要相信自己的直觉，不要过分消耗自己，坚持去做自我提升的事情，无论是不是通过工作去实现。
低代码这个名词说起来已经有些年头了，广义上来讲可以说是达到这么一种效果，即尽量减少通过编写代码的方式来完成研发任务，甚至部署交付整个技术产品。那么低代码模式到底值不值得弄，有什么优势和缺陷，本篇文章笔者就来聊一聊自己对于低代码的一些思考跟想法。
做技术的都知道，实际工作场合上，不能为了技术而技术。低代码也是一样，这门技术最重点解决的问题是，让不懂代码的人可以通过一套工具来完成自己开发的作品，所以从产品角度，低代码工具应当更加倾向于提升易用性，而非提升功能性。假设我要开发一个服务，我手写代码+手动部署需要3天，而学习低代码工具+完成服务搭建只需要1天，那么这种情境下，低代码工具就能够兑现自己的价值。
最近因为自研日常开发工具的需求，决定重新拾起PyQt5之类的桌面工具开发技术栈，为啥选用PyQt，一是因为笔者比较精通python，二是因为不需要在外观上做什么特别的东西。经过一番调研，发现当前的PyQt5版本已经过时，用pyside6会更加贴合现在的需求。因此笔者也简单部署了下pyside6的开发环境，通过这篇文章分享一下如何操作。
先强调一点是，所有的资料都可以在官网查到。如果有特别疑问的地方，参考官网，实在不行就stackoverflow或者gpt，也许可以更快解决问题。
在后端开发领域，Golang已经成为非常流行的编程语言之一，并且生态也非常成熟。虽然在应用规模上离Java还有一段距离，但其中很多编程技巧跟思路还是值得学习的，一是没有什么太多的coding约束，二是实际工作中也有可能用的上。
在近一两年，笔者的工作也逐渐从主python转为主go语言，对于Golang也有一些简单的学习心得。借助今天这个机会，也将《从零单排Golang》系列做了精编，整合成电子书对外发布。这个系列其实拖了比较久的时间才搞定，一开始因为做运维平台开发的需要，前几篇文章主要举了docker、k8s相关的一些实战案例，没有对Golang的基础原理做太多的深挖，然后也因为个人原因搁置了一段时间。但几年后因为转行，需要主Golang，于是也抽空把Golang的一些基本机制给深入探索了些。
总的来说，这个系列沉淀的都是自己的想法，没什么形而上学的东西，更多是从一个coding经验者转Golang的视角来撰写内容。不论你是初学Golang，还是从其他语言转过来，都可以参考这个系列，帮助你在学习Golang的过程中找到一些思路和灵感。
以下是相关资料：
上周某天下班前，接到同事转来一个bug要排查，症状是代码重构之后某些业务效果不符合预期，由于代码重构人是笔者，于是blame到笔者这边。经过10min左右的排查和尝试后，解决了这个问题：既往逻辑没有改动，重构时候出笔误了。
简单来讲，重构之前的代码大概是这个样子：
对于一个成熟的工程项目而言，因为项目未来发展或是和企业内部更深度融合的需要，我们可能需要对既有业务逻辑做很大规模的改动，涉及到多方面的逻辑迁移和代码重构，才能够达到下一代产品所需要的效果。
今天这篇文章，就来剖析一下如何做好这件事情，尤其是在历史积淀非常厚重的场景，需要通过怎么样的手段，把这个问题解决好。