Technology

调试Go工程 ::: tip prepare： vscode golang 1.92 ::: demo go mod init test In main.go file package main import ( "fmt" ) // Swap functions func swap(x, y *string) (string, string) { //XOR exchange *x, *y = *y, *x } func main() { fmt.Println("Hello, world!") //Swap functions for i := 0; i < 10; i++ { a := "a" b := "b" swap(&a, &b) fmt.Println(a, b) } } vscode一键生成测试 >gotest for package/function ::: tip 分别是为包生成测试单元，为函数生成测试单元。 :::...

创建 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。 查询参数是 URL 的可选部分，您可以自定义以共享特定网页视图，例如搜索筛选结果、问题模板或 GitHub 上的发布表单页面。要创建自己的查询参数，您必须匹配键值对。...

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.2 (或 3.1、3.3) 最新版：latest main 的最新版：main 4. 版本选择 你可以选择以下版本：...

〉 笔者之前在参与 OpenIM 前，去过一些开源的社区和公司学习协作过，发现了一些好的文化，于是记录在这里，最开始的标题是 “一篇适用远程工作的约定指南： OpenIM 远程工作团队协作协议 v1.3”，后面我从 OpenIM 离职了，去了一家日企，学习到了外企的新的文化精髓，再到毕业后创业，开始组件和打磨团队，有了一些新的思考。团队以及领导人的决策力是最重要的两个因素，所以我把标题改为了：“在AI时代 - 精益团队的企业文化和远程工作指南 v2.0” Principles 0）Ownership & Leadership 如果看到团队或是项目有问题的时候，不要等，也不忍，请马上说出来，并给出相应的方案， 自己跳出来召集开会，及时调整。不要闷在那里，自己憋！ “每个团队成员都承担Owner和Leader的角色。发现问题时，勇于指出并提供解决方案，不要等待或沉默。” 1）Initiative 每人个都必需是主动的，都需要自己发起要做的事，或是自己要认领要做的事，如果发现自己没有事情了， 需要学会主动发现问题，主动找到可以improve的地方，创新来源于此。没有路要学会自己造路！ “为团队创新和改进提供动力。” 2）Objectives Oriented 每个人都是产品经理，也都是项目经理，每个人都必需把自己的工作和我们大的目标连接在一起，知道什么是重点，重点的东西就是两件事：一）从用户的角度出发，二）从产品的角度出发。 这意味着我们要随时观察整个产品的样子，而不只是自己这一块东西 。 “始终保持用户和产品的双重视角，确保工作与总体目标一致。” 3）Insists on High Standard 举法其上，得乎其中，举法其中，得乎其下，举法其下，法不得也。我们要坚持用高的标准要求自己，对于高标准的目标不妥协，但是在实施路径和策略上可以妥协。 “始终坚持高标准，确保质量。在实施过程中可以灵活，但对于高标准的最终目标绝不妥协。” Practices 0）Online 工作的时候必需在线。如果不在线了，需要说一下不在线的时长, 目前我们工作的事宜在通讯工具采用Slack， 如果需要请假的情况，如果不是紧急情况，需要提前一天 在 OpenIM 的Slack #random 频道中提前说明。如果是紧急情况，也需要提前在insider频道中告知大家。 “工作时，请确保在线。若需离线，务必在Slack #insider 频道提前通知。” 1) Documentation Driven 面对面交谈、电话语音、微信、Slack虽然是比较实时的反馈工具，但是只有文档是可以把重要信息给结构化的，而且写文档其实是比起前面的方式来说是更为深度的思考，因为会让你自己审视自己的想法。所以，对于一些重要 “功能”、“流程”、“业务逻辑” 、“设计”、“问题”，以及“想法”，最好都以文档化的方式进行。请使用Github的 wiki、project、issue这些工具或是使用Google Doc. “确保关键信息持久化和可追溯。” 2）Design Review 对于一些重要的问题或是工作（每个人都能够判断什么是关键问题和工作）， 需要先把自己的想法share出来，而不是先实现 。 一个好的 Design 文档需要包括如下项： Background。交待这个事的背景、需求和要解决问题。 Objectives。说明这个事的目标和意义。 Alternative Solutions...

前言 https://github.com/OpenIMSDK/Open-IM-Server/issues/432 现在很多地方都对服务的国产化适配有所要求，一般的国产化平台都提供arm版本的linux云环境供我们进行服务部署，因此需要构建arm版本的镜像。 构建方案 在上面的 issue 中我们描述了大致的构建思路和解决的步骤，我们来看一下构建的方案，我们以最常用的 amd 机器为例，来编译 arm。对于构建镜像的ARM版本，有如下两种方式： 在ARM机器上使用 docker build 进行构建； 在X86/AMD64 的机器上使用 docker buildx 进行交叉构建； ⚠️注意： 交叉构建和交叉运行的方式会有一些无法预知的问题，建议简单的构建步骤（如只是下载解压对应架构的文件）可考虑在x86下交叉构建，复杂的（如需要编译的）则直接在arm机器上进行构建； 实际测试发现，使用qemu方式在x86平台下运行arm版本的镜像时，执行简单的命令可以成功（如arch），执行某些复杂的程序时（如启动java虚拟机），会无响应，所以镜像的验证工作应尽量放置到arm机器上进行； 上面第二点按如下方式测试： docker run --rm --platform=linux/arm64 openjdk:8u212-jre-alpine arch 可正常输出； docker run --rm --platform=linux/arm64 openjdk:8u212-jre-alpine java -version 则会 卡住，且需要使用docker stop停止容器才可以退出容器； 启用试验性功能 💡 注意：buildx 仅支持 docker19.03 及以上docker版本 如需使用 buildx，需要开启docker的实验功能后，才可以使用，开启方式： 编辑 /etc/docker/daemon.json ，添加： { "experimental": true } 编辑 ～/.docker/config.json 添加： "experimental" : "enabled" 重启Docker使生效： sudo systemctl daemon-reload sudo systemctl restart docker 确认是否开启：...

正片开始~ Kubernetes 是 Google 团队发起的一个开源项目，它的目标是管理跨多个主机的容器，用于自动部署、扩展和管理容器化的应用程序，主要实现语言为 Go 语言。Kubernetes 的组件和架构还是相对较复杂的。要慢慢学习~ 我们急需编排一个容器~ 为什么 kubernetes 弃用了 docker ::: tip 很意外 听到 Kubernetes 从 Kubernetes 版本 1.20 开始弃用对 Docker 作为容器运行时的支持，这似乎有点令人震惊。 Kubernetes 正在删除对 Docker 作为容器运行时的支持。Kubernetes 实际上并不处理在机器上运行容器的过程。相反，它依赖于另一个称为容器运行时的软件。. ::: docker 比 kubernetes 发行的早 docker本身不兼容 CRI 接口。Kubernetes 适用于所有实现称为容器运行时接口 （CRI） 标准的容器运行时。这本质上是 Kubernetes 和容器运行时之间通信的标准方式，任何支持此标准的运行时都会自动与 Kubernetes 配合使用。 Docker 不实现容器运行时接口 （CRI）。过去，容器运行时没有那么多好的选择，Kubernetes 实现了 Docker shim，这是一个额外的层，用作 Kubernetes 和 Docker 之间的接口。然而，现在有很多运行时可以实现 CRI，Kubernetes 维护对 Docker 的特殊支持不再有意义。 ::: warning 弃用的意义 虽然移除了 docker ，但是还是保留了以前的 dockershim，如果你愿意，你依旧可以使用 docker 容器化引擎提供容器化支持。 除了docker，还有 containerd、CRI-O...

参与本项目 ⚡ 前言 欢迎来到我们的项目！本项目旨在建立一个基于区块链的全民学习平台，通过集体的智慧和努力，推动技术和知识的普及。无论你是初学者还是经验丰富的开发者，你的贡献都将对项目产生积极影响。 💡 关于本项目（先看❗） 本项目由一个热衷于区块链和软件开发的团队发起。我们致力于创建一个开源、去中心化的学习环境，让每个人都能够访问和分享知识。 🌐 联系方式 Website Blog Telegram 🔍 项目背景 我们相信，通过集体智慧和技术的力量，可以打造一个更加开放和包容的学习环境。这个项目不仅是一个技术挑战，也是社区合作的成果。 🌟 如何参与 不论你的技能水平如何，都有多种方式可以参与本项目： 提交问题和功能建议。 参与代码编写和文档撰写。 在社区中提供帮助和支持。 我们都是这个仓库未来很有潜力的客户，或者是贡献者，谢谢你选择了加入C-UB社区，我们将会一起合作，未来我们将会考虑以区块链为底层搭建一个全民学习平台，我们每一个人都将会是这个社区的构建着，将会推动c-universal blockchain（链学） 社区的发展和进步~ 如果你对本项目有任何建议或发现文中内容有误的，欢迎提交 issues 进行指正。 对于文中我没有涉及到知识点，欢迎提交 PR。 或许我们会很疑惑？ 在我们参与贡献的时候，如果克隆了**🧷 cs-awesome-Block_Chain项目，但是每次获取上游代码很麻烦怎么办？如何提交有意思的代码？这篇文章将会解决这个问题~⬇️ ** ⚡提前需要你… 你需要学会使用markdown🖱️ 你需要学会使用git 你的代码符合Google代码规范 排版 笔记内容按照 中文文案排版指北 进行排版，以保证内容的可读性。 不使用 ![]() 这种方式来引用图片，而是用 <img> 标签。一方面是为了能够控制图片以合适的大小显示，另一方面是因为 GFM 不支持 <center> ![]() </center> 这种方法让图片居中显示，只能使用 <div align="center"> <img src=""/> </div> 达到居中的效果。 在线排版工具：Text-Typesetting。 在线的公式：LaTex 在线表格转换工具：tableconvert 谷歌代码规范 🧷 谷歌代码规范可以说是公认的规范，也是目前大多数企业都以为标准~ 对于大型程序，我们需要对 🔥软件工程有一定的了解 协议许可 所有内容遵循CC-BY-SA 3.0协议（署名-相同方式共享）© ⚡贡献步骤 我们的fork，如何保证实时的同步上游？🧷这篇教会你 保持自己github的forks自动和上游仓库同步并推送到 gitee...