【博客】个人独立博客站点在写博客的时候应该注意什么?
个人独立博客站点在写博客的时候应该注意什么?
这个问题是我对技术类个人博客写作时的纯主观见解,各位就图一乐看看,谢谢。
1.把读者当作第一次看相关技术文章
这一点其实很难做到,包括我在本站写的很多博客都并没有做到这一点。
所谓把读者当作第一次看相关技术文章,就是要在文章中写明问题引入和背景说明的内容。
举个例子:你写了一篇部署某某docker容器的教程,那么理应在博客中涉及如何在Linux主机上安装docker的教程部分。这个安装docker的教程部分可以直接添加至文章内,或者单独写一篇文章,把链接放在该文开头。
这样做有什么好处?除了让别人能点击链接看你的站点里面的另外一篇文章,更重要的是保证读者在看你这篇文章的时候,不需要去额外搜索其他的东西。
之前在WSL安装CENTOS8的博客中我就吐槽过这个问题。我找到的参考博客图文不对应,博文里面的截图代表这位博主用着win11的电脑,但他却写着win10的步骤(步骤在win11上是错的),整个设置和开启wsl功能的过程也没有贴截图,很让人无语。
对于使用windows系统比较熟练,知道怎么找设置选项的读者来说,这并不是神马大问题。但是对于很多刚入门编程学习的小白来说,图文不对只会让人感到困惑,只会让小白不知道这个设置选项到底在哪里。最终还是得去搜其他资料,找怎么在win11里面开启wsl的方法。
而原博主只需要多花30秒把win10开启wsl的步骤改成win11的,就能节省读者去搜索另外一篇博客的大量时间。如果你这篇wsl的配置教程博客连怎么开启wsl都没写清楚的话,请问这篇博客的意义何在呢?
同理,如果我作为读者,想部署一个minio开源S3存储服务器的项目,发现最好的部署方式是docker部署,但我的主机上没有docker,此时我就得搜索两篇博客:
- 如何在linux上安装docker;
- 如何在docker里面安装minio;
但实际查询资料的时候,以我个人为例,我都是先搜到第二个问题,再回过头去搜第一个问题的。如果我搜到的第二个问题的博客里面,作者引用或者介绍了如何安装docker的方式,那么我就不需要去额外搜索第一个问题了,这便是给读者节省了时间。
不过,我能理解为什么绝大部分docker相关的博客都不会引用如何安装docker教程,因为当你想部署某一个docker镜像的时候,绝大部分作者都默认你已经对docker有一定了解且安装过docker。如果你连docker是什么,怎么安装都不太清楚的话,那我也不太推荐你使用docker部署这种和个人数据高度相关的服务,因为后续配置失败或配置变动的时候,操作不当极其容易导致已有数据丢失。
但是这不是本文所讨论问题的核心。
2.减少博客里面的图片数量
这个是根据不同类型的博客而言的, 对于很多教程类博客而言,比如软件使用、软件配置等博客,图片/步骤截图是不可或缺的。
但是对于Linux类、代码编程类的博客而言,完全可以用代码块来替代图片。比如简单测试程序的运行结果、Linux命令的运行结果,就完全没必要截图,而可以将程序结果或命令行输出直接复制到笔记中,用代码块展示结果。在一些情况下,甚至可以做到整篇博客完全不包含截图。
下面就是一个示例,我希望给读者展示docker -v
命令的结果。这个结果是linux下的命令行输出,完全可以直接拷贝过来以代码块的形式展示,而不是以截图的形式。不过以截图的方式展示总好过不展示
1 | ❯ docker -v |
减少图片数量的好处:
- 用户加载博客的时间缩短,因为不需要去加载多余的图片;
- 图床冗余图片减少,维护压力减轻;
- 博客“失效”概率降低;
所谓博客“失效”,就是有些教程博客中的图片不见或者加载不出来了,直接导致这篇博客废掉了。如果博客中图片数量较少,一些设置的步骤有文字的描述,这样对博客有效性的影响就更低,博客内容失效的概率也就降低了。
而如果一篇教程类博客强依赖于截图,但后续又因为其他的一些原因导致图片无法加载,而文章中又没有对设置选项做出正确的文字说明,读者就会犯难,最终只能通过博主描述的上下文去猜测这张不见的图片里面到底是什么内容,阅读体验大大降低,最终浪费了时间。
3.避免豆腐块
这其实是从学生阶段学到的东西,即写任何长段文字的时候都应该分点分段。
有些文章一上去整个豆腐块扒在那里,没有分段,看的巨难受。更有甚者连标点都没几个,实在是无语。
4.拒绝半途而废
有些博文非常奇怪啊,写到一半戛然而止,非常怀疑是爬虫没有把后半部分爬出来……
这里必须要吐槽一下国内几乎所有的公共博客平台,都没有做任何反爬虫上传的机制,一篇文章百度一下能在n个平台上看到一模一样的,而且都不是同一个作者上传的(这篇博客的原作者是谁已经是个未解之谜了),有时候还会出现最早的那篇博客里面图片失效了,爬虫爬出来的图片还在的离谱情况。
5.说清楚版本号
环境部署、程序安装等等教程的时候,一定要在博客里面写清楚你当前使用的系统的版本号,很多时候一些不兼容问题就是版本号对不上导致的。
有版本号,至少能给对方提供一个解题的思路,可以去确认一下自己使用的版本号和博主的是否一致,是否会有兼容问题。
解决这个问题更好的方式是提供完整的结果输出,详见下一点。
6.写明结果、注明来源
写明结果
最简单的一个例子,leetcode的一篇题解博客,你应该给出leetcode通过的截图。我就遇到过题解博客里面,思路啪啪啪一顿输出,结果最终的代码复制粘贴到leetcode都没办法通过的。
代码没办法通过,可能是leetcode更改了测试用例,也有可能是题目要求有变化。如果你在文章里面贴了leetcode通过截图,读者就不会把问题怀疑到你身上。但如果没有,我就得吐槽一下:“怎么有人代码都没办法通过,还好意思发题解的啊?”
命令运行结果、程序安装预期结果、程序运行预期结果、OJ题解的leetcode通过截图等等,都是结果的一部分。
写明结果,避免误会,有头有尾才能令人信服。
注明来源
依旧是以leetcode题解为例,总有人写题解的时候,不告诉你这是leetcode的第几题,也没有leetcode链接,整篇题解只有leetcode的题目描述或者题目名字(有的甚至连这两个都没有)。
这就会导致读者想去练习一下这道题目的时候,还得去搜一下这道题在leetcode上有没有;有的话,究竟是第几题?leetcode的题目描述和你这篇题解里面写的是不是一样的?等等问题,突出一个恼火。
博客作者只用几秒种从地址栏复制一下题号、题目链接到博客里面,就能节省读者的大量时间。可总有那么多博主忽略了这一点,让我在搜资料的时候总是想把他们都从我的搜索引擎里面排除掉。
虽然现在搜索引擎有AI辅助搜索功能了,但该功能尚在不太可用的阶段,希望后续人工智能技术的发展能帮助大家更好、更快、正确的检索我们想要的内容吧。
7.尽量使用规范的markdown语法
网页链接
并不是所有的博客主题都支持自动解析markdown中贴出来的连接,所以,如果你的博客中包含其他http链接,请一定按照规范的md语法,使用[]()
将这个链接括起来,而不是直接贴一个链接。特别是链接中有空格的情况,如果直接贴出来,即便是带自动解析功能的平台,也有可能无法解析出这个链接。
如果链接解析失败,博客里的链接就无法直接点击,用户需要手动选中才能跳转到链接网页,会带来麻烦。
错误做法
1 | https://musnow.blog.csdn.net/ |
正确做法
1 | [https://musnow.blog.csdn.net/](https://musnow.blog.csdn.net/) |
加粗符号
在我使用过的绝大部分markdown编辑器中都会出现一个问题,即加粗符号的加粗内容最后一位是个标点符号的时候,加粗会直接失效。所以要避免加粗的最后一个内容是标点。
除了加粗会有这个问题,删除线、斜体都会遇到这个问题,都建议避免最后一个符号是标点。
错误做法
1 | **这是一个示例:** |
正确做法
1 | **这是一个示例**: |
特殊字符
很多时候我们复制的文件目录等等内容都容易出现markdown的特殊符号波浪线~
、下划线_
、*
星号或[]
方框。这些特殊符号都可以在前面加一个\
实现转义成普通字符,如\~
。
但我不推荐使用转义字符,更推荐使用行内代码块
。当你的文本中出现这种markdown特殊符号的时候,请一定一定要使用代码块将其框起来,而不要直接贴到markdown正文中还不做任何转义!因为如果你不做转义,很有可能会导致你的文字被识别成markdown语法造成格式错乱甚至部分内容被隐藏!
错误做法
1 | 请在sub_dir目录中找到这个文件 |
正确做法
1 | 请在`sub_dir`目录中找到这个文件 |
The end
暂时就想到这么多,后续能想到其他的再来补充。
如果你发现本站的某些教程类博客没有满足本文我自己描述的内容,可以直接贴在评论区打我的脸,我会在看到后及时优化博客内容。PS:本文内容仅对本站2023年以后的博客生效,2023年之前我写的博客也是很烂的😭。