分类目录归档：开源

Near By Guru: 找到你身边的开源上师

发表评论

在上一篇《开源，可能是新手软件工程师的唯一的路了，所以我做了 GoodFirstIssue.org》中，我介绍了 GoodFirstIssue.org ，今天我希望重点介绍一下其中的一个我个人很喜欢的项目 —— Near By Guru。 Near By Guru 可以帮助你找到你所在城市的开源开发者，你可以借此功能找到他们，并与他们取得联系，请他们帮助你，加入到开源社区当中。

有了合适的 Issue ，但贡献依然很难

对于新手来说，做贡献很难。开源和企业内部一个很不一样的点是，开源社区当中，没有人有义务为你提供帮助。大家会秉承着最大善意去帮你参与到社区的贡献当中；但并不意味着大家能像企业同事那样，做到当天甚至即时给你反馈；对于新手来说，这种等待反馈和确认无疑是煎熬的；而对于开源老炮们来说，这不过是他们参与到开源社区的一个又一个日常。

开源社区很好玩，但这些隐形规则的和企业内的不一样，容易让新手一开始就失去信心，使一个人放弃参与开源社区。这个时候，如果身边能够有一个已经在开源社区中浸润已久的人参与其中，给予心理支持，对于新手来说，可能就足以继续坚持下去。

当然，还不止于此，你身边的这些优秀的开源开发者们，他们可能已经成为很多企业的中流砥柱，你可以和他们取得联系，了解业界的最新进展，避免闭门造车，同时也可以对于业界有更多的了解。

Near By Guru 的功能到底是什么？

在设计 Near By Guru 的时候，我核心设计了三个功能：

  1. 读取大家写在 Github 上的 Location，并进行标准化处理；
  2. 以城市级的精度，进行地区排布，从而形成地区级别的开发者地图；
  3. 当用户登录后，获取用户的 Location，并基于 Location 来获取到自己所在地区的开源开发者的地图。

通过这样的方式，方便大家可以快速的找到自己城市的开源开发者们。同时，考虑到像湾区这种跨了好几个城市的地方或者是国内的京津冀、长三角、珠三角地区的情况，我还加了一个 60KM 的约束，一个城市地图上，除了加载本城市的开发者，还可以加载到自己所在城市周边 60KM 内的开发者，方便大家使用。

寻找 Guru 的正确姿势

  1. 作为新手，你不能预期每一位 Guru 都能回应你的联系请求，他们可能很忙，所以你要控制好自己的预期；
  2. 尊重 Guru 的时间：绝大多数时候，如果一个问题，你简单地通过 AI 就能获得答案，就不要拿来问你的 Guru。如果你问了 AI 依然不懂，也不要把问题直接抛给你的 Guru，而是要告诉他，你自己做了哪些研究，有哪些结果，你还有哪里不懂。这样才不至于浪费他的时间，在他心中给你留下不好的印象。
  3. 你们是在尝试建立朋友关系，不是招聘关系，不是师徒管理， Guru 没有义务回答你的任何问题；他的回答是出于善意和热心，而非义务，帮你那是情分，不帮是本分。

怎么使用 Near By Guru？

你可以直接打开 Near By Guru 的功能页面，浏览器会自动向你索要授权，并加载你的所在地，然后你就可以在地图上看到你所在地的开源开发者们。

需要注意的是，因为我们的精度是城市级别，所以固定大家是围绕着城市中心呈圆环状排列的。并不代表每一位开发者的真实位置。

你可以点击他的头像，或在地图或下方列表中查看他的详细信息（比如他的简介、Star 最多的项目）。我们在网站上并不直接提供联系方式，如果你需要和他取得联系，可以点击「前往 Github 联系 Ta」，通过他公开的联系方式，来和他取得联系。

此外，如果你所在城市没有人，但是你所在的省会有，你也可以向下滑动，找到你所在的国家和地区，按照城市级别去查找对应的人。

Near By Guru 的一些已知问题

由于使用的是 Github 的 Location 字段，所以存在多种问题：

  1. 这里的位置不一定是准的，因为大家不一定想起来要去更新，有可能你建立联系后，发现其实他已经离开了你的城市；
  2. 这个信息读取的是 Github 上的 Location ，如果你和你的 Guru 取得联系后，他不希望自己再被打扰，你可以告诉他：可以选择直接更新 Github Location 信息，一周后会自动更新；或者直接通过 GitHub 登录网站，把自己设置为 unlist即可。

以及，如果你受益于这个功能，通过这个功能找到了志同道合的朋友，并加入到开源社区里，希望你也能以对应的善意，在 Github 上写清楚你的 Location，方便帮助更多的新人加入开源社区。

总结

如果可以，我希望看到这篇文章的你，不管是开源新手，还是开源老炮，我们都能抱着善意，帮助我们身边的开发者。

开源，可能是新手软件工程师的唯一的路了，所以我做了 GoodFirstIssue.org

1 条回复

TL;DR
AI 能写代码之后，企业更想招一个熟手配上 AI，而不是一个新手。新手要被看见，开源是唯一的一条不用先被录取的路。我做了 GoodFirstIssue.org，按难度、语言和领域把 issue 筛出，让他们少翻、多改，用更多的时间，去构建自己在开源社区的信誉。

AI 时代的到来，对于我来说，无疑是欣喜的：我早已进入这个行业，虽算不上什么知名人士，但至少在圈子里也有不少好友知道我的能力，因而会给我机会；但对于我刚毕业的堂弟堂妹，甚至今年刚进入大学软件工程相关专业的年轻人来说，这个世界又无比的残酷。因为他们能做的事情， AI 也能做，甚至还能做得更好。相比于招募一个新手配上一个 AI，企业老板更希望招募一个老人，再辅以 AI。

更残酷的是，我自己作为小微企业的老板，我也会选择找一个老人，来辅以 AI。

所以，路在何方？

作为一个从开源社区成长起来的人，我自然是相信开源的，而且我也确实觉得 —— 在今天，开源已经成为这些新手们唯一的路：他们需要一个场合，能够让他们锻炼自己的各项软件工程技能，他们需要犯错，改正，记住教训；他们需要让自己走上舞台的机会。对于他们来说，开源是唯一的机会

你想要在企业中走上舞台，你需要先有机会进去，才能走上舞台；而开源不需要，它的代码是开源的，它的场景是开放的，它的用户反馈可能也是公开的。对于你来说，只要你有一个热忱的心，你就可以加入到这个社区当中，参与社区贡献。在开源社区，走上舞台不需要你先成为，只需要你真的有心。

开源贡献，也没那么容易

当你有了一个热忱的心，你就可以开始走上开源的贡献之路了。开源的贡献可大可小，如果你无所求（像我一样），那对于你来说，开源贡献很多时候就是 —— I Can Fix It。在 Github 上激情 Coding，也完全 OK，你依然在为开源社区做贡献，很好。

但对于这些新人们来说，他们显然是有所求的，那么如何以最低的 effort 获得自己想要的，就成为问题。

什么样的项目会是好的？适合新人的项目：

  1. 项目本身具有一定的关注度和领域价值：大多数时候表现为 Star 多 / Fork 多 / Download 多
  2. 项目本身拥有完善的项目贡献机制和 Mentor 体系：大多表现为有标准的 Contributing 路径且有人在对项目的 issue 、问题进行归档、分类、安排。
  3. 要解决的问题本身复杂度可控：对于新手来说，改一个几千行的 Kernel 的 Bug 不是一个特别可控的方案，但如果只是调试某一个函数，倒也未尝不可；

Github 上有那么多开源项目，又有多少项目能满足我们的需求呢？新手们如何找到这些 issue 呢？理想情况是本身这些新手们已经在用一些开源项目了，那么直接为自己在用的开源项目做贡献，显然是更好的。但，更多的人需要一个工具，帮助他们找到值得他们花时间精力去参与的项目，同时，在「找 issue 」这件事上，让新手在找 issue 上少花时间，把更多时间花在提交代码和参与社区贡献上。

所以，你应该如何使用 GoodFirstIssue.org？

简单来说，如果你没有目标，那么直接用筛选，按照可量化的指标来筛选即可；如果有目标领域，不如直接进提前筛选好的领域分类里快速看要贡献的 Issue 。

如果你不知道自己要做什么，但有一些模糊的目标，那么最简单的方法是，打开高级筛选，根据你的喜好，选择适合你的 Issue；比如筛选已标记 Good First Issue 的 Issue，难度为 2/5 或者 3/5 （越高越难），然后选择你想要的 Star 的范围（虽然越高影响力越大，但意味着竞争越强）。然后点击应用筛选，就可以选择出你喜欢的想要的 issue 。

如果你已经有明确的发展的领域，那么提前分好的类别，可能更适合你。你可以选择语言、框架、领域，点击进去后，你可以找到这个领域内的各种问题，然后，参与到其中，让别人看见你在这个领域交过的 PR。

甚至是，如果你已经在参加一些社区活动，那么基于活动的分类，也可以帮助你快速找到属于 Hacktoberfest 或者是 Google Summer Of Code 的 Issue；对了，现在刚好就在 Hacktoberfest 的时间范围内，为什么不参与一下呢？（快速查看符合预期的 issue）

总结

开源不是唯一能写代码的地方。但它是少数不需要先被录取、就能把代码、场景和反馈都摊开的地方。我做 GoodFirstIssue.org，不是为了让新手少焦虑，是为了让他们把时间从翻 issue 挪到改代码上，从而更好的在开源社区中，去构建自己的信誉。

So，要不要来试试看 https://www.goodfirstissue.org/zh ?

black and yellow printed paper

warehouse — 一个简单易用的 JSON 数据库

发表评论

在 Hexo 的 Github 组织下，有一个不明显，但却很有用的仓库 —— warehouse。

warehouse 是一个 JSON 数据库，基于 JSON 实现了各种类似于 SQL 的查询，可以帮助我们基于一个 JSON 文件来进行查询。在 Hexo 的静态生成过程中，warehouse 帮了大忙。

用官方的话来说，warehouse 就是 A JSON database with Models, Schemas, and a flexible querying interface.

在实际使用上，warehouse 确实如他所说的那边方便（虽然某些方法没有，但依然不影响他的使用很方便）。

Example

比如，如下代码就定义了 一个 Post 模型和对应的表。并实现了在这个表中插入一个新的数据。

var Database = require('warehouse');
var db = new Database();

var Post = db.model('posts', {
  title: String,
  created: {type: Date, default: Date.now}
});

Post.insert({
  title: 'Hello world'
}).then(function(post){
  console.log(post);
});
Code language: JavaScript (javascript)

如果你需要将这些数据保存为一个单独的文件，只需要修改初始化的参数，并执行 save 方法，就可以将 JSON 导出到指定的文件中

var db = new Database({
  path: "./test.json", // 将数据存储在 test.json 当中
});
db.save();
Code language: JavaScript (javascript)

类似的，如果数据已经构建好了，也只需要执行 load 方法，就可以加载数据。

var db = new Database({
  path: "./test.json", // 将数据存储在 test.json 当中
});
db.load();
Code language: JavaScript (javascript)

场景

如果你希望在内存当中对于 JSON 有一个更好的操作方式，那么 warehouse 是个不错的选择，不需要另外单独安装数据库，就可以实现类似于数据库的查询方式，体验还是非常好的。

如果你想了解更多，可以查看