(不愧是水王,一个项目可以水这么多篇文章。)

再把之前的图拿出来用用

这篇文章的写作原因是:木土老师写了篇文章,名为中文博客列表导航项目

你可以打开我们项目的“官网” https://zhblogs.ohyee.cc/,里面有精选博客、数据图表以及我们列表的全部数据。我们目前收集了近一千九百个博客网站的名称、网址、订阅地址、架构等信息。

博客列表凭什么能找到这么多的博客?

你可以在“博客列表”栏通过查看最后的博客的序号(idx)大致获知我们收录的博客,但这不准。你稍微看一下就会知道 idx 是不连续的(这个背后有个故事)。你需要在我们的列表数据接口看我们收录的博客数量。昨天下午 4 时 16 分,我们收录的博客数量突破了 1900。

这个数字相比于其它的博客导航项目已经很多了。我们是怎么做到的呢?其实方法很简单,主要有三个:

  1. **站在巨人的肩膀之上。**我们一直在使用中文独立博客导航、十年之约等上游源。站长只要在上游源提交就会被我们发现。(我们的知名度太低,站长一般不会主动过来我们这里提交)
  2. **通过友链进行裂变式搜寻。**大部分博客都有友情链接这种东西,而且友链的网站一般是其它的博客。这样我们就可以通过友情链接一路“顺”下去。
  3. 穷举。(本方法已被废止,只有个位数的博客是通过本方法找到的)在 GitHub 上搜索 github.io 仓库,就会有一堆仓库,在里面找中文博客。(我记得只找到两三个)

就是用这么简单粗暴的方法,我们人工将博客数量硬生生地提到一千九百。其它项目也可以用类似的方法发现博客(甚至有可能比我们还快),但这样做会耗费大量的时间精力,建议直接用我们的接口就行了。(我都快疯了)

这个项目在找网站时没有用任何的自动化脚本,添加的时候也是用 Ctrl+C/V ,自动化程度非常之低。之前我们地址库维护组已经向技术组提交了一个 issue,希望能在添加网站的页面弄个“一键填写”,恰巧赶上技术组重构,这个 feat 大概也石沉大海了。

博客列表到底是干嘛的?

这个项目因为有我的领导,一开始经历了一个极度混乱的时期,所有人都找不到方向。现在在项目组中,成员对于项目的希望也有很多:

  1. **做中文博客的全集。**这样可以找到冷门且优秀的博客,还能调查统计中文博客的情况。
  2. **做导航网站。**帮助访客发现博客。
  3. **做聚合网站。**博客标签不仅可以聚合博客,还能聚合博主。
  4. **做存档网站。**为中文博客网站进行存档。

这么多的目标使得博客列表没有办法像开往、BlogFinder 那样纯粹,会有各种各样花里胡哨、你可能用不上的功能。这个问题很致命,项目组会因为多个目标而没办法向明确的方向前进。

那列表的数据有什么用呢?我大概想了这么几个方面:

  • 友链申请——站长只要输入网址就可以自动补全其它信息。
  • 随机跳转——可以通过随机网站接口实现链接传递。
  • 博客推荐——根据博客标签可以推荐与某个博客内容话题相近的博客。

博客列表也的确在帮助博主发现博客,我们收到了一位博主的反馈:

博客列表将去向何方?

我们刚刚介绍了博客列表目标很多这个特点,说实话我特别担心这个东西。我们经常需要重新讨论产品的意义,因为“中文博客的全集”一时间看不到头,我们经常迷茫。大部分的博客导航网站只要收录几个优秀的博客,剩下的让博主自己提交就行。像我们这个“立志做全集”的真的少。(我一度不想干了)

我们地址库维护组之后还是分为两条路:添加网站和规范标签。添加网站近期将稍微暂停添加工作,去维护已添加的网站数据。(网站太多,一段时间就要停下来检查)

博客列表的组织架构?

项目组目前分为技术组和地址库维护组,技术组负责开发、维护代码、部署,地址库维护组负责列表数据的添加、修改、删除。地址库维护组的全称是中文博客列表导航地址库维护组,因为太长,所以负责人之一的沐云会有各种各样的叫法。

最后再说一说序号不连续的问题。当初序号是连续的,删掉网站之后序号会自动补全。直到,他出现了。

Okay. 又水了一篇文章。