故事的开端：一场“奇葩”的争论 # 最近，我和一位可爱的同事，因为一个项目的 go.mod 文件，产生了一点小小的“学术分歧”。文件长这样： // go.mod go 1.21.1 toolchain go1.22.9 同事认为这种配置“非常奇葩”，并抛出了一个灵魂拷问：“你本地用 go1.22.9 的工具链编译，线上服务器（CI/CD 环境）用的却是 go1.21 的基础镜像来构建，这能不出问题吗？这不就是经典的‘我电脑上好好的’吗？” 说实话，我一开始还没 get 到他说的“线上版本”是啥，后来才明白他指的是我们项目构建镜像所基于的 golang:1.21。他的核心论点是：开发环境和生产环境的 Go 版本不一致，是危险的。 为了说服我，他甚至搬出了“AI 军师”，进行了一场“人机对话”。 AI 的“第一次接触”：危言耸听 # 同事提问： go.mod 中 Go 版本与 Toolchain 版本不一致会带来什么问题？ AI 回答（摘要版）： 哇，这可不得了！当 go 版本和 toolchain 版本不一致时，会引发一系列灾难性后果： 语言语义和编译行为不一致：编译器优化策略不同，二进制文件体积和性能会有差异。 API 可用性错配：旧工具链编译不了新代码，新工具链用了新 API 在旧环境也跑不起来。 依赖解析差异：go mod tidy 的结果可能不一样，go.sum 文件会在不同开发者之间反复横跳。 构建标志和行为变化：CI/CD 和本地产物的可复现性降低。 安全与合规隐患：你可能会错过新工具链里的重要安全修复。 团队协作噩梦：开发者 A 和 B 构建出的二进制文件性能、大小、告警都不同，定位问题难于上青天。 AI 总结： 为了天下太平，请务必保持版本统一！CI 用什么，你就用什么！ 好家伙，这说得头头是道，一套组合拳下来，差点就把我打懵了。如果真如 AI 所说，toolchain 这玩意儿不就成了“潘多拉魔盒”？ 我冷静下来，心中升起一个巨大的问号：如果版本不一致是原罪，那 Go 团队费那么大劲引入 toolchain 指令，难道是为了好玩吗？

今天闲来没事看到一篇文章，感觉质量挺好的，就想翻译一下。之前写过一个将文档导出成 markdown 的插件，因为这个插件一开始是为了翻译 Medium 文章开发的，但是后来因为 Medium 的 json 接口启用了，所以这个插件后面也不怎么维护了。不搜不知道，一搜吓一跳，居然发现一个和插件差不多的插件，不会吧，这么烂的插件也有人抄？后来仔细看了一看，这个大佬应该是在借鉴我的插件，辛苦地改了几个中文。 两款插件名名字几乎一模一样，只是这个借鉴者加了一个后缀：掘金翻译计划版。不确定和掘金有没有关系，我知道掘金是有一个翻译项目的，以前我也参与过。 对比 # 插件介绍 # 我的插件 # 李鬼插件 # 代码对比 # 上面的简洁基本上已经展现了浓重的李鬼味道，本着客观严谨的态度，我还是去看了一下代码。 我的插件 # 李鬼插件 # 除了一个 js 文件的引用，几乎可以说是一模一样了。核心的文件是 widget.js 这个文件，这个属于插件自身的 js 文件。 从这代码对比，可以看得出这个借鉴者巨大的工作量。 总结 # 鄙人的这款插件是在 GitHub 上开源的，当时也是出于个人需求搞得这么个小玩意，但是没想到居然还有李鬼借鉴，还真是离谱他妈给离谱开门。大家如果有空的话，还是动一下发财的小手点一下 Report，这个李鬼插件还是下架比较好。我也联系了这个开发同学，希望他能及时下架。

为什么 2022 年是漏洞赏金奖破纪录的一年 # 原文：Why 2022 was a record-breaking year in bug bounty awards 译者：madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 每年，GitLab 的应用安全团队 都会回顾 GitLab 漏洞赏金计划的亮点。 对于整个行业的安全团队来说，2022 年是忙碌的一年，我们很幸运收到了大量出色的报告，帮助我们确保 GitLab 及其客户的安全。 随着我们在 2021 年 11 月 增加我们的漏洞赏金奖励金额和研究人员参与度的提高，我们在 2022 年期间奖励超过 100 万美元，打破了新纪录！ 如果没有我们的漏洞赏金社区的合作，我们就不会取得今天的成就，我们认为这些奖励非常有益，而且钱花得值。 2022 年的数字 # 在 221 份有效报告中获得总计 1,055,770 美元的奖金，高于去年的 337,780 美元！ 三名研究人员在他们的多份报告中获得了 10 万美元以上的收入，另外七名研究人员的收入超过了 2 万美元。 2022年共收到424名研究人员的920份报告。 解决了 158 份有效报告并公开了 94 份 - 今年，我们收到了一些信息泄漏报告，与漏洞不同，这些报告不需要公开 GitLab 问题。 今年有 138 名安全研究人员提交了一份以上的报告，表明他们对我们的计划做出了积极的贡献。 向提交三份或更多有效报告的研究人员授予八份 GitLab Ultimate 许可证。 注：数据为截至 2022 年 12 月 16 日。

CircleCI 20230104 安全事件报告 # 原文：CircleCI incident report for January 4, 2023 security incident 译者：madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 2023 年 1 月 4 日，我们提醒客户 一起安全事件。 今天，我们想与您分享发生的事情、我们学到的知识以及我们未来不断改善安全态势的计划。 我们要感谢我们的客户对于重置密钥的关注，并对此次事件可能对您的工作造成的任何干扰表示歉意。我们鼓励尚未采取行动的客户采取行动，以防止未经授权访问第三方系统和存储。此外，我们要感谢我们的客户和社区在我们进行彻底调查期间的耐心等待。为了实现负责任的披露，我们已尽最大努力在共享信息的速度与保持调查的完整性之间取得平衡。 本报告包含: 发生了什么？ 我们怎么知道这个攻击向量已经关闭并且可以安全构建？ 与客户的沟通和支持 如何判断我是否受影响？ 可能有助于您的团队进行内部调查的详细信息 我们从这次事件中学到了什么以及我们下一步将做什么 关于员工责任与系统保障措施的说明 安全最佳实践 结语 发生了什么？ # 除非另有说明，否则所有日期和时间均以 UTC 报告。 2022 年 12 月 29 日，我们的一位客户提醒我们注意可疑的 GitHub OAuth 活动。此通知启动了 CircleCI 的安全团队与 GitHub 的更深入审查。 2022 年 12 月 30 日，我们了解到该客户的 GitHub OAuth 令牌已被未经授权的第三方泄露。尽管该客户能够迅速解决问题，但出于谨慎考虑，我们在 2022 年 12 月 31 日代表客户主动启动了更换所有 GitHub OAuth 令牌的流程。尽管与 GitHub 合作提高 API 速率限制，但轮换过程需要时间 虽然目前尚不清楚其他客户是否受到影响，但我们继续扩大分析范围。

GShark has beem maintained for alomost two years as an open source sensitive infomation detection tool. This tool is utilized in my own company and sparetime, multi information sensi GShark 作为一款开源的敏感信息监测工具其实差不多维护也有两年多的时间。这款产品其实笔者在自己的公司或者平常都在使用，也通过这个工具发现多多起内部的信息泄露事件以及外部的一些的信息泄露事件。其实这种类似的开源工具数不胜数，大家的核心功能其实就是监控 Github 上面的信息，但是笔者要想把这种产品做得更好一点，就要从功能性、易用性角度来做进一步拓展。最近，对 GShark 做了较大的重构，前后端都完成了比较大的重构，之前老的版本也有写过文章介绍，所以关于这个工具的起源就不多介绍了，主要对这次重构和新的架构做介绍。 架构 # 目前 GShark 已经是一个前后端分离的项目，之前因为前端通过后端模板直接渲染的，所以在前端的功能性以及美观性都会差很多。新的重构是基于 gin-vue-admin，技术栈是后端通过 gin 实现，前端通过 vue-elemment 来实现。 所以架构主要就分为前端和后端两个部分，而后端则分为 web 服务以及敏感信息的扫描服务。新的架构具有以下特点： 细粒度的权限控制，更好的安全性，包括菜单的权限设置以及 API 的权限设置 丰富的前端功能，CRUD 更简单 搜索源和之前保持一致，支持 github, gitlab 以及 searchcode 部署 # 之前就有想使用 GShark 的同学来和我反映，其实之前的编译就已经很简单了。但是因为有些人不太熟悉 go，所以觉得编译还是有一些问题。这一次，笔者专门写了一个脚本来发布三个操作系统下的工具包，所以直接使用即可，开箱即用，即使你不安装 go 也无所谓。 rm -rf ./releases/* cd web npm run build cd ../ # build for mac cd server GOOS=darwin GOARCH=amd64 go build cd ../releases mkdir gshark_darwin_amd64 cd gshark_darwin_amd64 mv ../../server/gshark . cp -rf ../../server/resource . cp ../../server/config-temp.yaml config.yaml cd ../../ cp -rf ./web/dist ./releases/gshark_darwin_amd64 7z a -r ./releases/gshark_darwin_amd64.zip ./releases/gshark_darwin_amd64/ # build for windows cd server GOOS=windows GOARCH=amd64 go build cd ../releases mkdir gshark_windows_amd64 cd gshark_windows_amd64 mv ../../server/gshark.exe . cp -rf ../../server/resource . cp ../../server/config-temp.yaml config.yaml cd ../../ cp -rf ./web/dist ./releases/gshark_windows_amd64 7z a -r ./releases/gshark_windows_amd64.zip ./releases/gshark_windows_amd64/ # build for linux cd server GOOS=linux GOARCH=amd64 go build -o gshark cd ../releases mkdir gshark_linux_amd64 cd gshark_linux_amd64 mv ../../server/gshark . cp -rf ../../server/resource . cp ../../server/config-temp.yaml config.yaml cd ../../ cp -rf ./web/dist ./releases/gshark_linux_amd64 7z a -r ./releases/gshark_linux_amd64.zip ./releases/gshark_linux_amd64 rm -rf ./releases/gshark*/ 这个是 build 的脚本，主要是实现跨平台的编译并且将前端文件夹打包进去，然后拿到这个安装包解压即可使用。目前 GShark 的发布应该只需要两个前提条件：

Chrome 插件对于 Chrome 浏览器用户来说是必不可少的利器之一。之前我有开发过一款七牛云图床的 Chrome 插件 image-host。后来由于我自己没有自己的域名，所以不太好使用这个插件了。后面，有其他的同学来提交 PR 来维护这一个插件。这样就有一个问题，一旦新的代码发布，就需要自己再重新发布一下插件。虽然发布插件不算特别麻烦，打包成压缩包，上传就可以了，但是对于程序员来说，可以自动做的绝对不要手动做。以下就是通过 CircleCI 来持续发布 Chrome 插件，参考了官方的文章，自己也才了一些坑。 介绍 # CircleCI 是一款持续集成产品，和 Travis 非常类似，都属于 Github 上非常流行的持续集成产品。产品有商业和普通版本，开源项目是可以免费使用的。关于持续集成产品的不同，可以参考这篇文章。使用这个工具持续发布 Chrome 插件的原理就是：通过 CircleCI 来使用 Chrome 插件的 API 来持续发布插件，通过 CirecleCI 和 github 的集成可以在特定的时机就可以发布插件。那么下面具体介绍如何使用 CircleCI 来进行 Chrome 插件的发布，主要包括 Google API 的配置以及 CirecleCI 的配置。 Google API # 首先，创建一个 Google API 项目，可以直接点击这个链接创建。 在创建项目之后，我们需要开启 “Chrome Web Store API”。在 Library 中搜索这个 API， 并且将其 ENABLE。 在 ENABLE 这个 API 之后，就可以点击 “CREATE CREDENTIALS” 创建口令了。确保你已经选择了对应创建的 project。值得注意的一点是，你创建的应该是 OAuth client ID 类型的，确保你选择了正确的类型。

原文：Elasticsearch Team Development Constitution 译者：neal1991 welcome to star my articles-translator , providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 前言 # 我们作为 Elasticsearch 核心开发人员团队希望尽可能快地向可靠，健壮，安全，可扩展且易于使用的系统迁移。我们希望为创新而努力，取代传统的构造和功能，删除脆弱的代码，并致力于改善用户体验，同时在我们快速变化的同时保持用户增长。 对于我们来说，拥有一个团队的前进方向的共识是非常重要的，甚至更重要的是团队为什么要走上一条特定的路。当 Elasticsearch 创立之初时，它具有无尽的灵活性，易用性和丰富的 API。我们这帮年轻的团队成立了一家公司，并且突然用户数井喷式发展。支持组织几乎无法满足越来越多的客户，这是幸福的烦恼。然而，随着用户数量的增长，事情发生的可能性也越来越大，不幸的是，这比我们聘用支持工程师的速度要快得多。我们了解到，大多数灵活性来自宽松处理，从大多数情况下可行的功能，但不是全部。例如，用户可以使用请求发送的脚本基本上是一个远程代码执行引擎，如果出错，它是致命的。即使最基本的功能，比如设置，也非常灵活，但非常脆弱。在没有单位的情况下指定一个数字是很好的，除非许多用户不知道默认单位是什么。我们只是试图做正确的事情，结果证明并不是总是对的。 现在我们处于不同的位置。我们的用户基数比 2013 年的用户基数大得多，但我们的支持机构并没有以同样的速度增长。是的，我们处理比 2013 年更多的支持案例，但这在我们当时的系统中是不可能的。现在我们已经从一个脆弱而灵活的系统转向了范围较窄的软件。我们定义了更多的边界：更严格的输入验证，允许我们对权限进行细粒度控制的安全模型，甚至还有一个插件模型，可以以极大的灵活性来添加风险更高的功能。 但等等，我们还差得远呢！仍然有无穷无尽的问题会造成致命的后果。聚合可以通过一个请求来撑爆服务器。用户感觉需要运行 30+GB 堆的 Elasticsearch。我们仍然提供了 27 种指定布尔值的不同方式。这份清单还有其它内容… 我们对我们的用户，支持组织，云托管团队和第三方提供商负有巨大责任，提供可靠，稳健，安全且易于使用的系统。出于这个原因，我们都应该努力创新，取代传统的构造和功能，删除脆弱的代码，并改善用户体验。我们与其他公司相比的优势是我们的创新，创新需要速度。我们必须在留住用户的同时下采取行动并接受变革创新。 以下章节是用于设计，重构或从 Elasticsearch 代码库中删除代码的原则和指导原则的集合。这些点是无序的，大部分是未分类的，应该被看作是 Elasticsearch 团队内软件开发的一个组成部分。 设计特性 # 过程优于结果。 我们多年来一直遵循这种方法，这使我们能够随着时间的推移做出巨大的变化，而不会因大量的请求而产生巨大的响应。例如，补齐建议程序在 Elasticsearch 的早期版本中添加，而不支持实时更新和特定的删除。这意味着删除 Elasticsearch 中的文档不会立即反映在建议中。这是一个很难的问题，大约三年后，我们增加了对 Lucene 建议器和 Elasticsearch 的 bitset 过滤器的支持。与此同时，对于许多用户来说，这是一个可以接受的解决方案，修复了许多错误，并朝着基于文档的建议器发展。这就是过程优于结果。 为今天设计！谨慎使用抽象。 计算机科学教授教育学生以灵活性和信息隐藏的名义广泛使用抽象层。当然 Elasticsearch 广泛使用抽象; 没有任何涉及数百万行代码的项目可以以其他方式进行工作并生存。但经验表明，过度或过早的抽象可能与过早优化一样有害。抽象应该用于所需的级别，不要再进一步。 作为一个简单的练习，假设一个函数，它的参数总是被所有调用者传递为零。人们可以保留这个参数，以防万一有人最终需要使用它提供的额外的灵活性。但是那个时候，代码从来没有注意到的机会是好的 - 因为它从未被使用过。或者当需要额外的灵活性时，它不会以符合程序员早期预期的方式进行。我们应该定期提交补丁以删除未使用的参数; 一般而言，他们不应该添加在首位。（来源于 https://www.kernel.org/doc/Documentation/development-process/4.Coding）

Medium（需要翻墙访问）是国外非常知名的一个博客平台。上面经常有很多知名的技术大牛在上面发布博客，现在一般国内的搬运的技术文章大多数都是来自于这个平台。 Medium 文章格式显示地非常优雅，但是存在一个问题。众所周知，markdown已经是最受程序猿欢迎的文本编辑格式之一。但是Medium仅仅支持markdown格式导入，不支持markdown格式的导出。这也正是我当初开发这个插件export-medium的原因，现在这个项目是放在github上面的，欢迎大家多多star,或者pr。自己也花了5美金，注册了开发者账号，因为现在chrome对于不是商店的插件限制很严格，如果没上商店，一直有提醒，很麻烦。商店访问地址在这,需要翻墙访问。不过你可以手动安装: 将 export-medium clone 或者下载到本地。 在 Chrome 浏览中打开chrome://extensions,加载已解压的拓展程序，选择项目文件夹 这两种方法都是可以支持安装的。目前这个插件的功能主要是把Medium上面的文章解析成 markdown 格式的文本，用了一个简单的库去渲染（事实上我觉得挺鸡肋的），然后你只要点击一个按钮就可以把文本复制到剪切板，就可以复制到编辑器了，是不是很方便。 目前可能很多页面做的不是特别好看，欢迎大家感兴趣的可以试用或者向我提建议。 仓库地址: https://github.com/neal1991/export-medium （喜欢的还请多多star!!!)

其实一直以来想写一篇文章总结这几年的技术学习，刚好趁着自己的第一次 github contribution 达到1000+，写篇文章总结以下。本文篇幅较长，我会分为几个章节来分别阐述。 博客篇 # 为什么我要把博客放在第一位呢？因为我认为博客是developer学习技术的平台，也是developer分享知识的平台，博客差不多也就相当于是developer的名片。现如今，博客平台形形色色，有老牌的博客园，CSDN，也有现在比较新潮的SegmentFault，掘金，开发者头条，知乎等等。现在博客的形式已经发展得多种多样，现如今新潮的犹如各种各样的专栏等等。当然，在这么多博文中，有很多质量很高的文章，也有很多滥竽充数的垃圾文章。下面，我就就我个人的了解探探我接触的这些博客平台，仅是个人观点。 Github # 哈哈。我为什么把Github列到博客篇呢？其实现在Github几乎已经成为了我生命中不可或缺的一部分，每天打开电脑的一件事，基本就是打开Github看看。作为世界上最大的同性交友网站，Github对于程序猿来说绝对是生命中不可或缺的部分。在此，我主要说说Github作为博客方面的内容。 很多人认为Github只不过是一个代码托管的地方，为什么会和博客有关系呢？其实，现在很多人都是在Github的issue里面开博客，因为issue里面方便作者和读者的沟通，而且支持markdown格式，各种功能也是很丰富。对于比较关注的博客，你可以设置watch，这样你就可以了解issue里面的每一次变化，并且还会有相应的邮件通知。在此，给出几个我关注的几个人的Github博客： iCSS：讲解CSS的，有的还是蛮有趣的。 梁少峰的个人博客：讲解vue讲解的很透彻，百度大牛，我觉得有些博文挺值得看，而且值得多看几遍，不过我好像都没看完。他的博文还是需要深度挖掘的。 ccforward/cc：应该是当初关注他的一个知乎爬虫，他的博客内容我没有看太多，但是内容貌似还不错。 underscore-analysis：解析underscroe源代码的，挺不错的，我看过一两篇，值得多读几篇，我自己也该去读了。 Front-end-tutorial：内容很多，我没有过多了解，可以了解一下。 以上就是我了解的一些在Github上面的博客，因为在Github我没有特别关注这方面，所以还不是特别多，当然Github也不是我主要逛博客的地方。 CSDN # CSDN是我开启个人技术博客的地方，感兴趣的地方去我的博客逛逛http://blog.csdn.net/neal1991 。我应该是从2015年4月份开始写博客的，博客的内容主要有我研究生期间一开始做的道路识别的一些研究的论文，虽然这个方向没搞下去，这个方向的确很有前景，只能说老板很有眼光，但我没能力，没能搞下去。其它的也包括一些开发过程遇到的坑之内的，面试经历，技术文章翻译。老实说，CSDN现在的确不是一个很好的平台，因为本身它就偏老，在markdown的显示不是很完美，在移动端显示不是很好，还有一点很重要，广告特别多，还是莫名其妙的，看起来很讨厌。其实我一直都想弃坑，奈何就是github国内访问速度不稳定，还有毕竟在这边维护这么久了，所以还是一直维护着。在CSDN上，我基本上都是去写博客，基本不会在它上面浏览技术博客，因为它的浏览界面实在是太杂乱了，没有重点。这可能也是老牌博客的一个缺点，可能一时半会也没办法改过来。下面我主要讲一些我自己的一些比较稍微有用的博客内容： combox系列问题集：当初做winform开发遇到的问题，记得当初最坑爹的是调试combox的时候，visual studio老是崩溃，后来发觉居然是有道翻译的锅，也是醉了。。。 独立成分分析：这个应该是当初一个讨论班里面要做的一个presentation，我把内容整理出来写了这篇博文，阅读量快2000了，好像是我博客里面阅读次数最多的了。 如何查找django安装路径：非常简单的一个问题，但是当初搜遍了，没找到解决方法。 mongoose对象无法新增删除属性：当初在处理mongo遇到的一个问题，是个坑。 第一个chrome extension：第一次写chrome extension，没有想象中的那么复杂，不过还是有一些方法的，貌似360有翻译过谷歌相关的文档。老实说，谷歌真的很良心，现在很多开发者文档都已经是中文的了。 第一个pwa：第一次写progressive web application，其实写pwa和写其它单页面应用没有特别大的区别。pwa也是我非常看到的技术栈，我觉得这个比小程序好上一百倍，只不过现在在国内还是不温不火，但是我觉得很肯能哪一天就星星之火，可以燎原了。 鉴于CSDN平台的种种，我的确越来越不太愿意在这上面写文章。而且我最近的文章一向是以翻译国外技术文章为主，毕竟还是菜，所以只能靠英语吃饭啦。 掘金 # 老实说，掘金应该是同类这种网站访问量比较大的。的确，里面有不少的精品内容，当然也会参杂很多乱七八糟的东西。其实，现在一般的原创博主都不会只在一个平台发文章，所以基本上你这个平台看得到的，在其它平台也差不多都能看到。只不过我现在基本不看掘金了，因为他们的编辑对新人极度不友善，极度不友好。 众成翻译 # 360的一个专门翻译技术博客为主的平台，目前应该还是比较小众。360的前端其实还是蛮不错的，尤其是他们的齐舞团队，里面也有很多大牛。这个平台里面的文章一半质量还是比较高的，而且这个平台翻译操作也是蛮舒适的，感兴趣的非常值得试一试。而且他们的群沟通都很流畅，不像掘金那帮人。。。无力吐槽。 知乎 # 我本身一向是很排斥知乎的。讲心里话，知乎里面百分之八十的人都是在写故事，骗关注的，我也不明白知乎为什么充斥了这么多天天无事可做的人。当然，不可否认的是，知乎里面还是存在百分之二十的精品内容的，这也是让我能够忍受那剩余的百分之八十垃圾的原因。知乎里面那些回答我觉得没有太大的意义，看了也就是笑一笑，一般都是用来刷新三观用的，在此，我仅说一些技术专栏： 饿了么前端：饿了么现在前端的确搞得风生水起，尤其是pwa，感觉他们是这方面搞得国内最为成熟的一家。可能并不是，但他们肯定是分享这方面内容最多的公司。感觉饿了么前端蛮多大牛，不过感觉他们都喜欢混国外圈，黄玄基本都是在medium发文章的。。。 某熊的全栈之路：这个应该是infoq的专栏，这个编辑每个礼拜会发一个国内外最新技术的文章集合，基本是前端为主。内容比较新颖，基本上最时髦的都在这里面。 Think In Vue：意如其名，现在vue在国内真的很火。火到我觉得用react的撕逼应该撕不过vue，vue的作者尤雨溪在知乎也是很活跃的，经常手撕任何喷vue的人，还有看他阮一峰每日一喷很有意思。阮老师也是个很有意思的人，感觉天天都有人喷他，但是阮老师的心态丝毫不受影响，剖有大师风范。不过值得一提的是，阮老师博客的广告位可价值不菲哦~~ 美团点评技术博客：算得上是大厂，值得一看。 知乎乱，前端乱，如何乱中取胜，就是要保持一颗平常心。 开发者头条 # 不温不火的平台，文章质量还行。我一般发文章这个里面也会发一份。感觉里面的内容偏机器学习以及架构方面，而且这发文章可以攒IO币，可以换书哟。 Medium # 国外的一个博客平台，访问需要翻墙。这是国外一个专门写story的地方，样式很好看，应该算得上是国外非常知名的一个博客平台了。当然了，里面的内容也是多姿多彩的，同时里面的技术文章质量也有很多很高的文章。现在国内技术圈翻译的大多数文章基本都是来自于这个平台。 Quora # 国外一个和知乎一样的网站。不过知乎由于国内人数优势，火爆异常。Quora则是不温不火，而且上面还有不少华人。我关注过一段时间，但貌似都没什么特别的内容。 以上基本就是我所有的对于一些博客平台的了解，可能不包含所有，但基本都是我自己的个人的亲身经历。可能部分言辞颇为激烈，但也都是我的肺腑之言。 微信公众号 # 微信公众号作为一种特殊的平台，现在也成为一种传播渠道，有点类似于报看订阅的形式。但这不一定是一种非常有效的传播方式，感觉深度还是不够的，我比较喜欢在电脑上看文章，因为在手机上看文章难以持续地专注于一篇有内容的文章，一般就只能浅尝则止。所以我一般都是把链接转到我的微信PC版，然后再用浏览器打开，下面介绍一些我关注的一些技术类公众号： 前端之巅：我之前提过的，应该是infoQ的平台，其实和之前的知乎专栏应该是重叠的。 奇舞周刊：360奇舞团队，前面也介绍过了，国内的知名的前端团队，会有一些比较有价值的文章。 前端早读课：每天早上都会发送推文，但是文章质量嘛，参差不齐，基本上都是别人的文章。 FEX：百度FEX团队，收集最新技术文章，但是排版比较差，比较原始。 神秘的程序员们：里面会有一些脑洞大开的漫画，而且会有程序猿和产品经理以及架构师撕逼的故事，很有趣。 Github # 为什么我要把Github单独作为一章节来讲呢？因为它实在太重要了！！！以至于我除了它，根本不想去尝试其它类似的平台。关于Github可以讲的东西太多太多，它带给程序员的则是无穷的魅力。在此，我也仅就几个方面谈谈我的个人理解：