就说这光模块吧，大部分的时候都时候好好的。 但用了个把月，就开始出现下面的问题。 大部分的时候数据访问都比较正常，但会不确定性的出现超时的现象。 总感觉上面的问题是光模块自己因为什么原因重启了？ 温度原因？感觉不像是这个原因，因为已经用了多一个多月了，而且好像是每次 1 个多月后多会发生下。 我感觉更多的像是模块本身的质量问题。   https://www.isharkfly.com/t/topic/2953

我觉得 AI 域名本身它不是顶级域名，是一个国家域名。 这就有点和我们国家的 CN 域名以及一段时间炒的比较火的 IO 域名是一个意思。 一个国家域名在管理中一个最大的问题，就是很多域名的注册修改以及使用都跟国家政策相关。 .ai域名自1995年就已存在，最初是作为加勒比海岛国安圭拉的[国家代码顶级域名（ccTLD）而创建的。 由于“AI”是人工智能（Artificial Intelligence）的缩写，这一域名逐渐受到科技和IT公司的青睐，被视为通用顶级域名（gTLD），如今已成为最受欢迎的域名后缀之一。 部分国家代码域名要求注册者在该国拥有实体存在，过去.ai域名也曾有此限制。 但自2009年起，无论身处何地，任何人都可以注册 .ai 域名。 还记得以前我们国家 cn 域名出过一个限制的时候，把一夜之间把 cn 域名全部干翻了。 我觉得这类域名的最大风险就是在于域名持有国家的政策。 且这类域名的总体持有价格并不便宜，通常一年都会要好几十美元以上。     我记得 IO 域名价格上也不便宜。 我个人更倾向于还是使用国际顶级域名下到 com 和 net 这种的，通常这类域名会很稳定，而且不会怎么会被回收。 除非有特别好的 AI 域名，否则我不觉得这一类域名的投资价值有多高，可能当这个风口过了以后，这个域名就变得不再那么重要了。 就网站和应用来讲，更多的还应该是内容。 和 com 域名一年10美元左右的持有价格相比，这一类域名的持有成本更高，可能再砸了一些钱进去以后，也没有人追捧了。   https://www.isharkfly.com/t/ai/18751/2

在开源软件领域，并行版本系统（CVS）一直使版本控制的选择。 恰如其分的是，CVS本身是一个自由软件，它的非限制性的技法和对网络操作的支持（允许大量的不同地域分散的程序员可以共享他们工作的特性）非常符合开源软件领域合作的精神，CVS和它半混乱状态的开发模型成为了开源文化的基石。 但是像许多其他工具一样，CVS开始显露出衰老的迹象。 Subversion是一个被设计成为CVS继任者的新版本控制系统。设计者通过两个办法来争取现有的CVS用户：使用它构建一个开源软件系统的版本控制过程，从感觉和体验上与CVS类似，同时Subversion努力弥补CVS许多明显的缺陷。 Subversion 可以在多种不同的操作系统上运行，它的主要用户操作界面是基于命令行的，但现在已经开发出很多可以运行在不同操作系统上的客户端以及多种开发工具的集成套件。 CollabNet 这个公司早在 2020 年和 XebiaLabs 进行了合并。 CVS 这个软件版本控制一直在 2010 的一个项目中还在使用。 后来好不容易让那个项目把版本控制从 CVS 转换到 SVN，谁知道没有过多久又需要从 SVN 转换到了 GIT。 不管怎么样，在大学毕业后的那几年，软件版本的控制一直用的是 CVS，也算是代表了青春的一段回忆。     还记得 CVS 那时候使用的logo是这条小鱼，不过很多年已经没有看到过这条小鱼了。 客户端那个时候使用的是这只小乌龟，现在软件开发的时候还是会安装这个小乌龟，只是这个小乌龟从 CVS 变成 SVN，然后变成了git。     不管软件行业的开发怎么变，当一个产品被市场慢慢淘汰的时候，可能连一个招呼都不会打。   https://www.isharkfly.com/t/cvs-subversion/10626/2

警告的信息为： error (ERR_INVALID_THIS). Will retry in 10 seconds. 2 retries left.     原因和解决 这主要发生在 pnpm 版本与 Node.js 版本不兼容 时（特别是 Node.js 20+），常见于运行 pnpm install 或构建项目时。 解决方法也很简单，运行下 pnpm 的更新命令。 npm install -g pnpm@latest 然后检查下版本。 PS D:\WorkDir\Repository\Stonex\Stonex-Isharkfly-Ui> pnpm -v 7.29.1 PS D:\WorkDir\Repository\Stonex\Stonex-Isharkfly-Ui> npm install -g pnpm@latest changed 1 package in 9s 1 package is looking for funding run `npm fund` for details PS D:\WorkDir\Repository\Stonex\Stonex-Isharkfly-Ui> pnpm -v 10.33.0 可以看到 pnpm 的版本升级到了 10.33.0   再次运行安装程序，使用升级后的版本，通常问题都可以完全解决。   https://www.isharkfly.com/t/npmp-error-err-invalid-this/9801

构建 VUE 项目时，提示错误信息： Build VUE ... [Pipeline] sh (hide) + pnpm install --frozen-lockfile This project is configured to use yarn because /var/lib/jenkins/workspace/Stonex/Stonex-Mdm-Ui/package.json has a "packageManager" field     但实际上源代码的包文件中没有packageManager 这个配置。 登录 DeveOps 服务器，发现确实添加有：packageManager 这个参数。     有点奇怪这个参数是从哪里来的。 原因和解决 因为源代码中没有这个配置，但在构建的时候添加上去了。 猜测有可能是 Jenkinsfile 配置文件的问题。 因为在配置文件中，我们添加了： sh 'yarn set version berry' 猜测是这个配置导致的问题。     删掉这句话后再次尝试构建。   https://www.isharkfly.com/t/jenkins-pipeline-packagemanager/10623

+ yarn add -D wrangler@latest This project is configured to use pnpm because /var/lib/jenkins/workspace/Stonex/Stonex-Mdm- Ui/package.json has a "packageManager" field     上面的错误原因非常明确，是因为使用的包不同。 原因和解决 修改使用 pnmp 来进行部署。 原来的配置为： stage('Deploy to Cloudflare') { steps { // Install Wrangler locally for the project sh 'yarn add -D wrangler@latest' // Deploy sh "yarn wrangler pages deploy ./dist --project-name=${PRJ_NAME} --branch=main" } } 修改为： stage('Deploy to Cloudflare') { steps { // Install Wrangler locally for the project sh 'pnpm add -D wrangler@latest' // Deploy sh "pnpm wrangler pages deploy ./dist --project-name=${PRJ_NAME} --branch=main" } } 再次尝试部署。   https://www.isharkfly.com/t/jenkins-cloudflare/9316

在 NodeJS 的安装中，可以在全局包中安装所需要的包。 如果需要安装多个包的话，使用空格作为分隔符。     开始的时候，一般可能会考虑使用逗号作为分隔符。 实际上使用的是空格作为分隔符，对需要安装的组件，直接使用空格即可。   https://www.isharkfly.com/t/jenkins-nodejs/9315

错误日志为： + npx browserslist@latest --update-db npm warn exec The following package was not found and will be installed: browserslist@4.28.2 The --update-db command is deprecated. Please use npx update-browserslist-db@latest instead. Browserslist DB update will still be made. /bin/sh: 1: pnpm: not found node:child_process:957 throw err; ^ Error: Command failed: pnpm info caniuse-lite --json /bin/sh: 1: pnpm: not found at genericNodeError (node:internal/errors:983:15) at wrappedFn (node:internal/errors:537:14) at checkExecSyncError (node:child_process:882:11) at execSync (node:child_process:954:15) at getLatestInfo (/var/lib/jenkins/.npm/_npx/072487b38308305a/node_modules/update-browserslist-db/index.js:80:23) at updateDB (/var/lib/jenkins/.npm/_npx/072487b38308305a/node_modules/update-browserslist-db/index.js:282:16) at Object.<anonymous> (/var/lib/jenkins/.npm/_npx/072487b38308305a/node_modules/browserslist/cli.js:47:3) at Module._compile (node:internal/modules/cjs/loader:1554:14) at Object..js (node:internal/modules/cjs/loader:1706:10) at Module.load (node:internal/modules/cjs/loader:1289:32) { status: 127, signal: null, output: [ null, Buffer(0) [Uint8Array] [], Buffer(28) [Uint8Array] [ 47, 98, 105, 110, 47, 115, 104, 58, 32, 49, 58, 32, 112, 110, 112, 109, 58, 32, 110, 111, 116, 32, 102, 111, 117, 110, 100, 10 ] ], pid: 2279551,     原因和解决 上面问题的原因是 Jenkins 虽然配置了 Node 构建环境，但是没有安装 pnpm 构建工具。 找到 Jenkins 中的工具。     在 NodeJS 的安装配置中，添加 pnpm。     重新触发构建后，pnpm 工具就会找到对应的命令让构建继续。   https://www.isharkfly.com/t/jenkins-vue-pnpm/9314

美国司法部 2025年8月21号 发布的消息。     从司法部发布的消息来看，该名软件工程师试图在公司代码中植入了一个 Java 的无限循环。 无限循环的启动，基于的判断条件是该名程序员的用登录信息从 AD 中删除。 这个循环将导致使用软件系统的公司无法登录账户。当这个逻辑被触发后，导致了数千用户无法登录系统，给公司造成了数十万美元的损失。 为了掩盖自己的行为，该名程序员还删除了所有加密数据，相关的搜索记录等。 最终被判入狱 4 年。 逻辑炸弹 逻辑炸弹 （logic bomb）是一些嵌入在正常软件中并在特定情况下执行的恶意程式码。 这些特定情况包括更改档案、特别的程式输入序列、特定的时间或日期等。 虽然程序员对公司的很多操作可能会有不满，但是真正在代码中使用逻辑炸弹的并不常见，也没有必要。 更多的可能就是删库走人，公司的数据库系统通常会有多层的备份和冗余设计，实际上删库走人的影响没有逻辑炸弹大。 删库走人这个表现实在是太明显，只要数据库连不上，在几秒钟之内就会被发现。 逻辑炸弹的问题更难被发现，因逻辑炸弹的触发通常不会马上被触发，可能是在几个月后。 但代码的历史记录还是会保留，所以当你提交了逻辑炸弹的时候，通常是会被代码的历史查看发现，也是一个非常愚蠢的选择。 代码控制 现在的公司不管是大公司还是小公司，只要涉及到有代码，通常都会使用代码管理工具来对代码进行管理。 每一次代码的提交，分支的合并，都会有明确的记录，同时在合并到代码主分支的时候，会有多个同事对代码进行校验和检查。 从这个事件上可以看到，该程序员服务的公司在代码的管理和控制上，并没有做到完全的流程规范化，以至于这段代码都没有被发现。 当时没有被发现不代表你做的事情是对的，或者以后不能被发现，只是该名程序员利用管理上的漏洞。 采取合理的途径 虽然资本主义国家的公司对员工的裁员通常没有抱有太多的同理心，但是也不代表作为公司员工的你可以随意的向公司进行报复。 任何人都应该采取合适和合理的方法去向公司申请自己正常的利益。 就几天前，加州的一个仓库管理员点燃了仓库中的货物引起大火，从工资和收入的水平角度来说，其实大家也都差不多，为什么别人没有选择这么极端的方式。 但这方法太极端了，而且非常错误，因纵火可能会剥夺其他无辜人的生命。 事情是 2 个方面的，这些年资本对普通人的压榨确实有愈演愈烈的趋势，也希望资本能够通过这些事件能够明白，过度的压榨和剥削最终会损害所有人的利益。 但哪怕是这样，普通人承受的也远远多于资本。   https://www.isharkfly.com/t/if-4/2602

不要觉得 IT 行业中的大厂病和你无关，在 IT 大厂中工作过的人是会把很多的这些习惯下沉到其他企业中，无形给自己的公司带来很多的伤害。 其实每个公司都会有其自己的企业文化。     在 IT 企业中的大厂病和其他生产领域的大厂病是完全不同的。 在制造领域的生产线上，企业在招聘你之前就非常明确的告诉你，你的工作是可以被替代的，而且你只需要做好你自己该做的事情就可以了。 对这种市场和用工需求，企业员工通常对企业不会抱有太大的幻想，他们要求的就是日结。 IT 领域又是另外一种景象，能够在 IT 大企业中一份职位的员工通常都受过比较良好的教育，你的未来职业规划和生活需求有明确的要求。 这种情况下 IT 企业大厂就会采取更加隐蔽的方式。 IT 大厂企业将会创建更多的部门，更加复杂的管理流程，严格和更加复杂可怕的 KPI 绩效，甚至提出了很多人都不太喜欢的末位淘汰制。 在这些年，大厂通常会通过项目组织架构重组的方式来进行裁员和内部人员调配，更多的是通过一些对人员的流动性管控，来让内部的人有危机感。 因为 IT 大厂这些年的经济营收通常都比较稳定，比传统的制造业要好得多，所以在薪资上面，他们还是相对比较慷慨，让能够在IT大厂内工作的员工自我感觉良好。 也在社会上形成一个 IT 白领精英人士的这种表象， IT 大厂本质上的工作还是去削弱人的创造力，让你能够在一个岗位内混吃等死，让最终被优化，给人的感觉就是温水煮蛙，等到最后的一天，突然发现自己好像什么都不会。 对其他公司下沉影响 因为在大厂工作过的 IT 人员，通常都会有一些多多少少的大厂病。 如果中小公司过分依赖或者过分迷信大厂工作过的员工，这个时候通常会给自己的 IT项目和 IT 运营带来不少的困惑和麻烦。 比如说大厂要求的安全性，其实在很多初创型中小公司的具体IT业务中并不是非常重要。 目前就那么几十个用户，在这个情况下，很多公司甚至都可以用 Excel来解决，但是不少中小公司相信从大厂工作过来的人的工作经验，给予他们很多项目和人员调配上的权力，新来的领导通常会说我们需要在现有的基础上为后续的开发做准备，为后续的项目做准备。 其实对于一些中小公司来说，哪怕是企业几年后倒闭了，都没有这么多的用户量。 投入在 IT 结构和架构上的成本远远超出了公司需要的量，这就是典型的与需求不符。 无独有偶，所有从大厂过来的管理层，只要有大厂工作经验，进入一个新的工作岗位，前三个月的情况大部分都是在裁员和组织架构重组。 大厂内有几万的员工，随便调整一下，进行有一定比例的裁员也通常不会有有大的影响。 但对于一共就只有那么二三十个人管着开发和一大摊子事的公司来讲，一口气裁掉了 30% 其实对整个业务也会有很大的影响，而且对留下来的员工会产生非常大的心理冲击，也会造成一定的士气低落。 我的看法 对于中小企业来说，不要迷信有大厂工作经验的人是我的看法。 如果更多相信这个人有大厂工作经验，或者相信我的公司只要使用他的能力，就能够给我现在的公司的 IT 状况带来很大改变，通常是会让你感到失望。 他可能不一定能够带来他可能不一定能够带来正面的改变，相反可能把现有的 IT 架构和 IT 开发带入一个长期的内耗状态。   https://www.isharkfly.com/t/it/10977