在开源社区中学会如何提问

author(Github) 在提问之前 在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前,请先做到以下事情: 尝试在你准备提问的论坛的旧文章中搜索答案。 尝试上网搜索以找到答案。 尝试阅读手册以找到答案。 尝试阅读常见问题文件(FAQ)以找到答案。 尝试自己检查或试验以找到答案。 向你身边的强者朋友打听以找到答案。 如果你是程序开发者,请尝试阅读源代码以找到答案。 当你提出问题的时候,请先表明你已经做了上述的努力;这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好,因为我们更乐于回答那些表现出能从答案中学习的人的问题。 运用某些策略,比如先用 Google 搜索你所遇到的各种错误信息(搜索 Google 论坛和网页),这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果,在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事,即使它只是表明了搜索引擎不能提供哪些帮助。这么做(加上搜索过的字串)也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。 别着急,不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前,再阅读一下常见问题文件(FAQ)、放轻松、坐得舒服一些,再花点时间思考一下这个问题。相信我们,他们能从你的提问看出你做了多少阅读与思考,如果你是有备而来,将更有可能得到解答。不要将所有问题一股脑拋出,只因你的第一次搜索没有找到答案(或者找到太多答案)。 准备好你的问题,再将问题仔细的思考过一遍,因为草率的发问只能得到草率的回答,或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力,你越有可能得到实质性的帮助。 小心别问错了问题。如果你的问题基于错误的假设,某个普通黑客(J. Random Hacker)多半会一边在心里想着蠢问题…,一边用无意义的字面解释来答复你,希望着你会从问题的回答(而非你想得到的答案)中汲取教训。 绝不要自以为够格得到答案,你没有;你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案,靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题,而不仅仅是被动的从他人处索取知识。 另一方面,表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示?、我的这个例子里缺了什么?以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向,你就有完成它的能力和决心。 当你提问时 慎选提问的论坛 小心选择你要提问的场合。如果你做了下述的事情,你很可能被忽略掉或者被看作失败者: 在与主题不合的论坛上贴出你的问题。 在探讨进阶技术问题的论坛张贴非常初级的问题;反之亦然。 在太多的不同新闻群组上重复转贴同样的问题(cross-post)。 向既非熟人也没有义务解决你问题的人发送私人电邮。 黑客会剔除掉那些搞错场合的问题,以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。 因此,第一步是找到对的论坛。再说一次,Google 和其它搜索引擎还是你的朋友,用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题(FAQ)、邮件列表及相关说明文件的链接。如果你的努力(包括阅读 FAQ)都没有结果,网站上也许还有报告 Bug(Bug-reporting)的流程或链接,如果是这样,链过去看看。 向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说,别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定,那就向别处发送,或者压根别发。 在选择论坛、新闻群组或邮件列表时,别太相信它的名字,先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题,这样可以让你感受一下那里的文化。事实上,事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意,也许这样就找到答案了。即使没有,也能帮助你归纳出更好的问题。 别像机关枪似的一次“扫射”所有的帮助渠道,这就像大喊大叫一样会使人不快。要一个一个地来。 搞清楚你的主题!最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错,最好在搞清楚这之间差异之前什么也别问。 一般来说,在仔细挑选的公共论坛中提问,会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点,一是看潜在的回复者有多少,二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。 可以理解的是,老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样,你的加入也有可能使情况走向极端 —— 已经好几次了,一些热门软件的作者由于涌入其私人邮箱的大量不堪忍受的无用邮件而不再提供支持。 Stack Overflow 搜索,然后在 Stack Exchange 问。...

September 17, 2023 · 4 分钟 · 826 字 · 熊鑫伟, Me

开源社区的规范设计思路

社区不规范怎么办 作为 OpenIM 社区首席运营官,对整个社区的 communtiy 以及 GitHub 配置仓库 进行了全面的配置。并且对整个 OpenIM 的 Makefile 和 CICD 流,以及整个 OpenIM 使用的日志包 、错误码、协同流、贡献者文档以及 社区文档 进行架构和设计。 在这个时候总会有一些问题,即使你觉得自己的 贡献者文档 写的很牛逼了,很全面了,但是依旧很少有人愿意花心思去按照你写的规范去学习。这对我打造顶级的开源社区是一个非常大的阻碍,于是就有了今天的这个文档,我会将它记录在 GitHub Gists 上,提供拉取和使用的说明、链接,并且定期的维护它。 首先,我提供克隆的链接: git clone https://gist.github.com/cubxxw/126b72104ac0b0ca484c9db09c3e5694 如何设计 首先是针对基础的功能,那就是我们熟知的 commit 信息和 push 信息。 我们可以对 commit 信息的格式进行设置 我们可以对 push 的大小进行设置 我们提供了 actions 的功能 我们提供了 Makefile 标记和清除 Hook 的能力 我之前在学习 git 的时候写了一篇很全的笔记,并且分享在 GitHub 上面,在这个 🤖 链接 上可以学习到 git 很多高级用法。 这篇文章讲解了 git 有哪些规范,寻找合适的 CICD 流: 统一格式: 统一格式:git commit -m 'type(scope): 描述(#issue)' 我们在提交的时候带上邮箱信息 -s 来签证,这是一个很好的习惯。...

September 16, 2023 · 7 分钟 · 1334 字 · 熊鑫伟, Me

我的第一个博客

你好,我是熊鑫伟 在光阴的长河中,我如此荣幸地踏入大四的这个重要时刻。不仅仅是一位学生,我热衷于编写那些跳动的代码,于是,我成为了开源的狂热追随者。欢迎您探索我的数字天地——我的GitHub。这里,您将看到我对技术的热爱,我的第三代博客,我期待它能成为我与这个世界对话的终极纽带。 在无数社区中,OpenIM 如同闪耀的北极星,引领我前行,灌溉我的技术之心,让我真实地行动起来。 然而,我的生命并非仅停留在屏幕前。从此,世界不再是书本,而是展开在我脚下的广阔天地。 户外的召唤使我欣喜,无论是我独自的冒险还是与朋友的欢聚,每一个步伐都是对自然的敬意和生命的探索。 我寻找开源的深意,并在阅读中不断地得到启示: 《开源的成功之路》:它让我明白,每一个成功都不是偶然,而是走过的那些布满荆棘的道路的回报。 《大教堂与集市》:开源并不仅仅是代码的分享,它更是心与心的交流,是一种对自由与创新的追求。 《黑客与画家》:这部作品是我至今的最爱,它提醒我,真正的价值不在于你拥有了什么,而在于你创造了什么。 > “你的价值取决于你创造了什么,而不是你拥有什么。" 这句话是我每日的座右铭,激励我持续前行,创造属于自己的美好。 开源,于我,是一个旅程,充满了未知与挑战。但我渴望在这条路上遇到更多的同路人,与您共同分享,共同创造。 我真心邀请您,与我一起,探索这个充满可能的世界。

September 14, 2023 · 1 分钟 · 15 字 · 熊鑫伟, Me

DevOps OpenIM 的标准设计

DevOps DevOps 🔥 DevOps是一种软件开发和运营的文化和方法论,旨在通过自动化和协作来缩短软件开发周期和提高软件质量。 DevOps(Development和Operations的混成词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 为什么 OpenIM 需要 DevOps? 我想用一句话来概括,DevOps 能解决 OpenIM 当前的团队管理,能高效组织团队,并且能通过 自动化 工具协作于沟通。 从而实现用更少的浪费、更频繁的交付更稳定的产品。 最开始的 OpenIM 是什么样子的? 找到了之前的一个很古老的版本,链接是:https://github.com/OpenIMSDK/Open-IM-Server/tree/test-tuoyun 几乎存在 commit 信息丢失,因为信息不全导致代码无法跟踪问题,导致文档缺失,代码不规范等一系列的问题。 我们跨越了从原始社会到传统的协作方式,再到后面的 devops 为什么说及时到现在,我依旧没有将 OpenIM 转变为 devops,一个很明显的判断标准,每一次运维和交互工作依旧需要我手动去做,无疑是区分了 dev 和 ops 的职责。不仅仅让成本变高,效率变低,更重要的是团队没有了更清晰的定位。 那么我后面的计划如何? 不管是 prow, actions, 等等 CI 工具,以及各种 ops(gitops, aiops, chatops,) 也不管是各种设计的 自动化 以及 自动化管理工具,自动化交互工具。 无疑他们是一套体系: 提供无感知的开发环境,无论交付是否频繁,每一个 feature 的 PR 都能快速的,规范并且经过大量自动化测试,更加快速上线,也能更快地响应客户需求。每一次发布的变更变少,所以风险,以及合并的冲突,工作量就变少。而且代码 code review 更方便,代码质量和团队水平提升很高的档次。 🔥 OpenIM 当时我的设计理念是 main 分支作为一个类似于传统的 dev 分支,保证代码的最新以及基本可靠,release-v* 分支作为稳定的分支。 DevOps 最重要的就是自动化,和自动化运维。非常鼓励自动化,甚至可以让开发者即使不会任何运维也能去走整套自动化的流程。 OpenIM 的团队约束制定:https://traveling-thistle-a0c.notion.site/OpenIM-standardization-ebd0c1529ab54e4fb92840e67a73aac1?pvs=4...

September 2, 2023 · 3 分钟 · 458 字 · 熊鑫伟, Me

OpenIM 多进程管理

111: OpenIM 多进程管理策略 主要模块 这篇文章将会从 OpenIM 最基本的单进程前台运行开始,到 nohup 后台运行,到 system 系统进程,然后再到 Supervisord,容器化管理,kubernetes 健康检测。 目前问题 阅读:https://github.com/cubxxw/Open-IM-Server/blob/refactor/feat-enhance/scripts/install/openim-crontask.sh 源码 目前 OpenIM 之前的进程管理策略是通过 nohup 在后台启动的。 整个项目由多个进程共同运行,现在需要一个可靠的保活机制,以便能够在进程崩溃的时候能够快速把它拉起来。openim 的解决方案无非就是写个保活脚本,在后台一直运行,如果发现某进程被关闭了,那么由脚本拉起来,或者是通过 docker compose 健康检测机制: healthcheck: test: ["CMD-SHELL", "./scripts/check-all.sh"] interval: 30s timeout: 10s retries: 5 但是脚本它自己挂掉怎么办?(总不能使用脚本继续保活保活脚本套娃吧)。此外,另一个办法就是配置出来一个服务,让Linux操作系统帮你守护进程,显然,这种办法完全不需要担心守护进程自己挂掉,毕竟是systemd帮你守护,如果它挂掉了,操作系统应该也没了。 我们适配通用的 Ubuntu 和 CentOS 即可,因为 其他 的操作系统比如说 alpine , Alpine Linux 并不使用 systemd 作为其默认的初始化系统。相反,Alpine Linux 使用 OpenRC 作为其默认的初始化系统。这也是许多人选择 Alpine Linux 的原因,因为它是轻量级的,并且没有引入 systemd。 现在新版的 Ubuntu 和 CentOS 都支持的,旧版的linux使用service httpd start启动服务,新版的linux使用systemctl start httpd来启动服务,此外使用initd作为初始化系统的操作系统添加服务是在/etc/init.d/中添加脚本,而使用systemd作为初始化系统的操作系统只需要在/etc/systemd/system/文件夹中添加配置文件就好了。 前台进程 前台进程:是在终端中运行的命令,那么该终端就为进程的控制终端,一旦这个终端关闭,这个进程也随之消失,这时就把Shell给占据了,我们无法进行其他操作。对于那些没有交互的进程,我们希望将其在后台启动,可以在启动参数的时候加一个’&’实现这个目的。...

August 16, 2023 · 7 分钟 · 1480 字 · 熊鑫伟, Me

如何安装和使用自主人工智能工具Auto-GPT

前言 🔮 在我的 Slack 工作区中,集成了多个 AI,分别有 ChatGPT 4、ChatGPT 3.5、Claude …… 我们可以通过 Slack 免费并且无限制的和 AI 交互,欢迎大家加入到 Slack,这里是 链接: https://join.slack.com/t/kubecub/shared_invite/zt-1se0k2bae-lkYzz0_T~BYh3rjkvlcUqQ 介绍 很早之前就了解到了 Auto-GPT,作为 GitHub 上近期增长速度最快的项目(没有之一),Auto-GPT 在开源社区可谓是人尽皆知,甚至 star 已经很快就超过 Kubernetes,目前有 125k star。 得益于 Auto-GPT 的出色技术,可以高精度和高效率地自动执行许多任务。 它利用了 GPT-4 强大的自然语言处理功能。 我们甚至可以通过它来实现更多的自动化的工作,比如说前一节 在 Sealos 上开发一款 AI 自动云原生化项目自动上线工具 什么是 AutoGPT 它的 GitHub 地址: GitHub 从本质上讲,Auto-GPT 利用 OpenAI 最新人工智能模型的多功能性与软件和服务进行在线互动,使其能够 “自主 “执行X和Y等任务。但正如我们在大型语言模型方面的学习,这种能力似乎像海洋一样宽广,但却像水坑一样深。 AutoGPT 是一个由人工智能驱动的应用程序,利用 GPT-4 等 LLM 的强大功能自主创建和处理各种工作。通过使用 Auto GPT,组织和个人可以简化报告创作、内容创建和数据分析等流程,以节省时间并减少错误。 AutoGPT 改变了任务自动化的游戏规则,使组织和个人能够专注于其他关键任务,同时将重复和琐碎的工作留给程序。 随着 LLM 的不断发展,我们可以期待看到像 Auto GPT 这样功能越来越强大的软件能够执行越来越复杂的任务。...

July 16, 2023 · 2 分钟 · 411 字 · 熊鑫伟, Me

Github Actions 的高级使用技巧

创建 actions actions 是可以联合收割机以创建作业和自定义工作流的单个任务。您可以创建自己的操作,或使用和自定义GitHub社区共享的操作。 可以通过编写自定义代码来创建操作,这些代码可以以您喜欢的任何方式与您的存储库进行交互,包括与GitHub的API和任何公开可用的第三方API集成。 可以编写自己的操作以在工作流中使用,或与GitHub社区共享您构建的操作。要与所有人共享您构建的操作,您的存储库必须是公共的。 操作可以直接在机器上或Docker容器中运行。您可以定义操作的输入、输出和环境变量。 可以构建Docker容器、JavaScript和复合操作。操作需要一个元数据文件来定义操作的输入、输出和主入口点。元数据文件名必须为 action.yml 或 action.yaml 。有关更多信息,请参阅“GitHub操作的元数据语法。“ docker 容器操作 Docker容器用GitHub Actions代码打包环境。这创建了一个更加一致和可靠的工作单元,因为操作的使用者不需要担心工具或依赖项。 Docker容器允许您使用特定版本的操作系统、依赖项、工具和代码。对于必须在特定环境配置中运行的操作,Docker是理想的选择,因为您可以自定义操作系统和工具。 对操作进行发布管理 如果您正在开发供其他人使用的操作,我们建议使用发布管理来控制分发更新的方式。 用户可以期望操作的修补程序版本包括必要的关键修复程序和安全修补程序,同时仍与其现有工作流保持兼容。每当您的更改影响兼容性时,您应该考虑发布新的主版本。 在这种发布管理方法下,用户不应该引用操作的默认分支,因为它可能包含最新的代码,因此可能不稳定。 相反,您可以建议用户在使用您的操作时指定一个主要版本,并且仅在遇到问题时才将他们引导到更具体的版本。 要使用特定的操作版本,用户可以配置他们的GitHub操作工作流,以针对标签,提交的SHA或以发布命名的分支。 使用标签进行发布管理 我们建议使用标签进行操作发布管理。使用此方法,您的用户可以轻松区分主版本和次版本: 在创建发布标签(例如 v1.0.2 )之前,在发布分支(例如 release/v1 )上创建并验证发布。 使用语义版本控制创建发布 文件列表的右侧,单击Releases 页面顶部,单击草拟新版本。 要为发布选择标签,请选择选择标签下拉菜单。 如果您创建了一个新标签,请选择目标下拉菜单,然后单击包含您要发布的项目的分支。 在“描述此版本”字段中,为您的版本键入描述。如果您在描述中 @mention 任何人,发布的版本将包含一个贡献者部分,其中包含所有提及用户的头像列表。或者,您可以通过单击生成发行说明自动生成发行说明。 或者,要在您的版本中包含二进制文件(例如已编译的程序),请在二进制文件框中拖放或手动选择文件 或者,选择设置为最新版本。如果不选择此选项,将根据语义版本控制自动分配最新版本标签。 如果您准备好发布您的版本,请单击发布版本。要稍后处理该版本,请单击保存草稿。然后,您可以在存储库的发布提要中查看已发布或草稿的发布。有关详细信息,请参阅“查看存储库的版本和标签”。 移动major version标签(例如 v1 、 v2 ),指向当前版本的Git ref。例如: git tag -a v1.4 -m "my version 1.4" 引入新的主要版本标记( v2 ),用于将破坏现有工作流的更改。例如,更改操作的输入将是一个突破性的更改。 主要版本最初可以使用 beta 标签发布,以指示其状态,例如 v2-beta 。 -beta 标签可以在准备好时移除。 带有查询参数的发布表单自动化 要通过使用自定义信息自动填充新发布表单来快速创建发布,您可以将查询参数添加到发布表单页面的 URL。...

June 14, 2023 · 10 分钟 · 2030 字 · 熊鑫伟, Me

Openkf 多架构镜像的构建策略设计

自动化构建openkf的多架构镜像并推送到多个镜像仓库 https://github.com/openimsdk/openkf 描述: 为了满足各种用户的需求,我们的目标是自动化构建用于各种架构的openkf Docker镜像,并无缝地将它们推送到多个镜像仓库。 目标: 自动构建openkf的linux/amd64和linux/arm64架构的Docker镜像。 将镜像推送到Docker Hub、阿里云Docker Hub和GitHub容器仓库。 任务: 设置多架构构建系统 使用GitHub Actions,配合QEMU和Docker Buildx,支持linux/amd64和linux/arm64的多架构构建。 在每次新版本发布、提交到main分支或定期事件时,触发构建过程。 支持多个镜像仓库 Docker Hub:推送到openim/openkf-server。 阿里云Docker Hub:推送到registry.cn-hangzhou.aliyuncs.com/openimsdk/openkf-server。 GitHub容器仓库:推送到ghcr.io/openimsdk/openkf-server。 动态镜像标记 使用Docker Metadata Action,基于事件(如定期触发器、分支提交、拉取请求、语义版本控制和提交SHA)生成动态标签。 确保在拉取请求事件中不推送已构建的镜像。 身份验证和安全性 使用秘密配置Docker Hub、阿里云和GitHub容器仓库的身份验证。 确保每个仓库的推送操作都是安全且无缝的。 通知和日志 通过GitHub Actions,如果有任何构建或推送失败,向开发团队发送通知。 保留每次构建和推送操作的日志以供追踪。 验收标准: openkf镜像应该成功地为linux/amd64和linux/arm64架构构建。 在成功构建后,镜像应该在Docker Hub、阿里云Docker Hub和GitHub容器仓库上可用。 根据定义的事件和属性正确标记镜像。 整个过程中不需要人工干预。 附加说明: 自动化过程在GitHub Actions工作流中定义。确保根据需要查看和更新工作流。 确保在单独的分支或环境中测试此过程,以避免中断。

April 23, 2023 · 1 分钟 · 46 字 · Me

Openim离线部署设计

1. 基础镜像 以下是您需要的基础镜像及其版本: wurstmeister/kafka redis:7.0.0 mongo:6.0.2 mysql:5.7 wurstmeister/zookeeper minio/minio 使用以下命令拉取这些基础镜像: docker pull wurstmeister/kafka docker pull redis:7.0.0 docker pull mongo:6.0.2 docker pull mysql:5.7 docker pull wurstmeister/zookeeper docker pull minio/minio 2. OpenIM 与 Chat 镜像 详细了解 OpenIM 和 Chat 的版本管理及存储: version.md OpenIM 镜像 获取镜像版本信息: images.md 根据所需版本,执行以下命令: docker pull ghcr.io/openimsdk/openim-server:<version-name> Chat 镜像 执行以下命令来拉取镜像: docker pull ghcr.io/openimsdk/openim-server:<version-name> 3. 镜像存储选择 存储库: 阿里云:registry.cn-hangzhou.aliyuncs.com/openimsdk/openim-server Docker Hub:openim/openim-server 版本选择: 稳定版:如 release-v3....

1 分钟 · 140 字 · 熊鑫伟, Me