人人都是产品经理

@xia0 纯技术的运维我建议不要深入，现在 ai 出来了，技术更新太快，但是人的软实力 ai 目前还替代不了

@coefuqin 没有啊，我看周围同事 40 多 50 多岁的很多，制造业工厂没有互联网那种卷

@NewYear 是的，感觉后面已经干的好同事，要能帮领导，还有各业务部门拿达成他们目标，这样升职加薪也有人给你背书，不能闷头搞技术，人际交往沟通，做事的管理能力很重要

@Gaoti 没有，一开始，干运维收入是不高的

你的这些我也都搞过，感觉你简技能点太多了，感觉会的挺多，但是深度没能很好体现，建议写几个非常熟悉的，最好能体现出量级的，比如你你监控规模怎么样，这个过程中你觉得亮点的地方，cicd 的效果是什么样，还有就是你会不会哪些语言，找工作其实会的多不是好事，你这个岗位其实和基础架构和运维开发相关，你的代码能力怎么样？
楼主还是挺强的，10k 找应该不难，但是我觉得可以针对性的写简历。

其实你这个年龄主要是沟通能力和软技能，阮技能是核心竞争力，我也 94 年，但是工作基本很好找，基本 1 到 2 次面试我就找到工作了，主要是表达好，面试官觉得你在这行业有积累经验，有核心竞争力

去厕所撸一发

我看你是后端，应届生写的太多了，一个项目写精就好了，就比如 12306 吧，可以深入写一下，要有自己的想法和思路，其余两个项目都没啥太大价值

你把你简历发出来我们看看，现在社招主要还是看经验匹配度，大概率是 HR 没把好关

像一楼说的，工作经历丰富，但是看不出具体什么水平，简历像流水账一样，我觉得你可以把不重要的地方去掉，简历重点突出的是自己在上家公司干了什么？解决了什么核心问题，自己有什么成长？然后写几个项目，突出一些项目亮点就行了。

vscode 的插件 https://zh.database-client.com/#/home?source=8828_cweijan.vscode-ssh

database-client 不香吗，数据库，rdp ssh 等都可以

我曾经也在思考这个问题，既然身体是我的，为什么我控制不了我的生老病死，喜怒哀乐？为什么古代那么多修行的人都是修炼意识，儒家修炼自己的浩然之气，道家修炼自己的太上忘情，佛教修炼四大皆空，都是在意识层面发力呢？几千年来，彷佛这些人都是在寻找真我，悟得超脱或者成佛，可见佛还是成圣还是成仙在古人看来应该是一种意识上得觉悟状态，我个人理解是获取了部分身体得 root 权限，达到了一种全新不可知得境界，是一种念头通达，时刻感觉到我，没有疑惑得一种境界。
这些都是个人感悟，现在年纪大了，不再去思考这些东西，现在我每次生活中体会“我”，比如有时候我说话时候，做事时候，会体会自己思想，情绪得变化，去理解每一刻我的运行状态，我无法得到真我，只能监控我的每一个状态，总有一天，我回顾我的过往状态，分析出真正的我

@manasheep 你能获取操作系统的 root 权限吗，有可能你只有一个 geust 的访客权限哈哈，身体本质是虚假的，意识才是核心，借假修真，意识可以说是操作系统，身体是电脑，你有可能是获取了操作系统部分执行权限的用户，随着意识的开发，我觉得未来人有可能获取 root 权限，解锁身体的更多能力

道本无名,强名以为道。神本无相,借假以修真

道本无名，强名以为道。这句话提醒我们，道本身并没有固定的名字，它超越了语言和概念。同样地，真正的你也不仅仅是外在世界的体验或身体的特征。你是一个更深层次的存在，超越了表面的标签和形式。

神本无相，借假以修真。这句话告诉我们，神或灵性的本质也没有固定的形相。它不受身体的限制，而是通过借助假象或象征来修炼和实现真实的境界。类似地，你的真正本质也超越了外在的形象和身体的限制。你可以通过内在的意识和思维来探索和发展自己，超越身体和外在条件的束缚。

因此，可以说真正的你是一种超越了名字、形象和身体的存在。它涵盖了你与外在世界的互动、身体的体验以及内在的意识和思维。在探索"真正的我"的过程中，你可以超越对外在条件的过度关注，通过内在的觉察和自我发现来寻找更深层次的自我认知和理解。

当然，如果你觉得规则引擎过于复杂，那么也有一些简化的解决方案：

1. **模块化设计**：对于公共功能（如 zip 文件解析、基本字段处理），你可以将它们设计为模块化的库或服务，所有项目都可以共享。

2. **配置文件**：对于每个项目的个性化部分，你可以使用配置文件来描述。这个配置文件可以定义需要解析的特定字段，计算方式，存储方式等。

3. **UI 界面**：对于配置文件的管理，你可以开发一个简单的用户界面，让非技术人员也可以配置规则。用户通过 UI 输入的配置信息可以自动转化为配置文件，被各个项目使用。

这种方法的好处是简单易用。任何需要个性化处理的新项目，只需创建一份新的配置文件即可，无需编写新的代码。缺点是这种方法的灵活性较低，如果遇到非常复杂或者特殊的业务规则，可能就需要修改库或服务的代码来满足需求。

值得注意的是，这种方法也需要一定的开发工作，包括开发公共库或服务，开发配置管理的 UI 界面，以及编写和维护配置文件等。因此，你需要根据你的具体需求和资源，来权衡哪种方法最合适。

帮你问了下 gpt4

规则引擎可能确实适用于你描述的这种场景。它可以帮助你管理和应用业务规则，而无需将这些规则硬编码到每个项目的代码中。其中一个好处是，业务规则可以独立于代码进行修改和维护。你可以使用一些开源规则引擎，例如 Drools ，它是一个基于 Java 的业务规则管理系统（ BRMS ）。

将这些项目整合在一起的一个可能的方式是：

1. 创建一个核心服务，它实现你的公共功能，比如解析 zip 文件和处理子文件。这个服务可以暴露 API 供其他服务调用。

2. 对于每个项目的个性化部分，你可以使用规则引擎来管理。你可以为每个项目编写一组规则，这些规则定义了如何处理每个项目的个性化内容。规则可以配置为解析特定的字段，进行特定的计算，以及确定存储方式等。

3. 你可以创建一个配置页面，通过这个页面，你可以为每个项目配置规则。这个页面可以连接到规则引擎，让你能够添加、修改和删除规则。

这种方式的优点是灵活性和可扩展性。如果有新的项目，你只需要为它编写一组新的规则，而不需要改动核心服务的代码。同时，因为规则是在页面上配置的，所以非开发人员也可以参与规则的创建和修改。

然而，这种设计也有一些挑战。例如，你需要确保规则引擎的性能足够好，可以快速处理大量的规则。此外，你可能还需要提供一些工具或文档，来帮助用户理解如何编写和修改规则。

不要远离权力核心，能送礼送礼