hexo seo 优化

阅读之前#

你需要知道的知识包括#

  • Hexo 基本命令
  • html<meta>标签

对项目进行更改#

为博客添加关键字#

在hexo主题文件夹中(一般路径为themes/your-theme/layout),找到layout.ejs文件,修改如下位置

1
2
<meta name="keywords" content="<%- (page.keywords || config.keywords)%>">
<meta name="description" content="<%- (page.description || config.description)%>">

并且在博客.md文件顶部的描述信息中添加

1
2
3
4
5
6
---
....
keywords: 博客关键字
description: 博客文章的概述
....
---
这样操作之后,会修改的博客网页的<head>标签中的部分<meta>标签,为当前页面添加关键字,增加搜索引擎检索的概率。

减少博客URL长度#

修改根目录下_config.yml

1
2
3
....
permalink: :title.html
....

添加站点地图(sitemap.xml)#

进入hexo项目的根目录下,安装插件

1
2
npm i hexo-generator-baidu-sitemap #用于百度搜索
npm i hexo-generator-sitemap

修改根目录下_config.yml文件

Hexo的一些增强--目录以及RSS订阅

阅读之前#

你需要知道的知识包括#

  • 使用npm/yarn管理项目的依赖
  • Hexo的基本使用

前置的一些环境#

  • Node.js & NPM

使你的Hexo支持目录#

进入Hexo项目的根目录中,使用npm/yarn添加依赖

1
2
3
npm install hexo-toc #当你使用npm时
# or
yarn add hexo-toc #当你使用yarn时

之后在根目录中的_config.yml添加:

1
2
3
4
5
6
7
8
9
10
#目录
toc:
maxDepth: 3 #目录层级
class: toc
slugify: transliteration
decodeEntities: false
anchor:
position: after
symbol: '#'
style: header-anchor #基础样式

为你的博客生成RSS源#

进入Hexo项目的根目录中,使用npm/yarn添加依赖

1
2
3
npm install hexo-generator-feed #当你使用npm时
# or
yarn add hexo-generator-feed #当你使用yarn时

之后在根目录中的_config.yml添加:

1
2
3
4
5
6
7
8
9
10
#目录
toc:
maxDepth: 3 #目录层级
class: toc
slugify: transliteration
decodeEntities: false
anchor:
position: after
symbol: '#'
style: header-anchor #基础样式

如果已经构建过项目,请先进入项目根目录下运行,清除缓存

1
hexo clean

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# RSS support
feed:
enable: true
type:
rss2 # 与path关联
path:
rss2.xml # 与type关联
limit: 140
hub:
content: true
content_limit: 140
content_limit_delim: ' '
order_by: -date
icon: https://avatars.githubusercontent.com/u/23006024?v=4 #RSS 展示的图标
autodiscovery: true

如果已经构建过项目,请先进入项目根目录下运行,清除缓存

1
hexo clean

尝试构建#

然后进行正常的hexo的生成和测试 ``` shell hexo g & hexo s

Hexo的一些增强--渲染Latex公式

阅读之前#

你需要知道的知识包括#

  • Hexo基本命令
  • Shell的使用
  • laTex的使用

前置的一些环境#

  • Node.js
  • Linux shell/ macOS shell

对Hexo项目进行修改#

依赖安装#

首先进入到Hexo项目的根目录中,运行

1
2
3
npm install hexo-math hexo-renderer-pandoc #当你使用npm时
# or
yarn add hexo-math hexo-renderer-pandoc #当你使用yarn时

配置文件的修改#

1
2
3
4
5
6
7
8
9
10
11
#插件
markdown:
plugins:
....
- hexo-math #增加
.....
# 增加这一配置MathJax
math:
engine: 'mathjax'
mathjax:
src: https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.4/MathJax.js?config=TeX-MML-AM_CHTML

系统命令安装#

需要安装pandoc命令,用以支持LaTex的解析

1
2
3
brew install pandoc #当你使用macOS时
# or
sudo apt-get install pandoc #当你使用ubuntu时

尝试构建#

如果已经构建过项目,请先进入项目根目录下运行,清除缓存

1
hexo clean

然后进行正常的hexo的生成和测试

1
hexo g & hexo s

测试LaTex,应能得到图1.1
$$
\begin{align*}
len = \sqrt{(X_{Split_{m}}-X_{SP})^{2}+(Y_{Split_{m}}-Y_{SP})^{2}}\\
\\
\theta = \arctan \frac{X_{Split_{m}}}{Y_{Slit_{m}}}\\
\\
Y_{offset} = len·\cos \theta \\
\\
C1=(X_{Split_{m}},Y_{Split_{m}}-len)\\
C2=(X_{Split_{m}},Y_{Split_{m}}+len)
\end{align*}
$$
  

图1.1

工程师遇到的一些问题

The lesson I have learned in decades of dealing with software related companies of all sizes is that you have a personality and financial problem.

That is, few companies are run by actual engineers. They are run by bean counters, lawyers, CFOs, marketing, etc. These people don't "get" programmers, engineers, etc. They don't like them, understand them, get along with them, or even have many overlapping interests. The reverse is also largely true.

For example if you go to a large financial institution you will find the C-Suite on the 28th floor with a view over the water while the IT people who build the algos that run the company are in a windowless part of some dungeon. Or if you go to a engineering company the engineers will be open plan with crap lights, chairs, desks, and dividers while the executives all have their own individual offices.

Thus, the executives start hiring people kind of like themselves to "interface" with the "weirdo" engineers. Thus was born things like the PM with a PMP, the product managers, etc.

These people are under pressure from the executive to do things one way, while the creators really should do things a different way. But this is a hierarchy. This isn't a negotiation, this isn't a system that is keen on feedback. The executives decide and the engineers are supposed to execute. They really don't like the engineers when they say things like, "That deadline is impossible. You can pick quick or you can good, but you don't get both." That is the sort of thing that drives an executive to a rage. They put in their quarterly plan that they were going to deliver good and cheap, how dare the engineer be so defeatist. The worst executives whine endlessly about how engineers will never give a proper answer to when something that involves lots of R&D done. They start droning on about boring things like all the unknowns. Again, that executive made a presentation to the board about how the next version of the product would have twice the battery life at half the cost. Is the entire engineering department conspiring to make him a liar?

Then you have internal politics. This sort of thing happens even at the level of a lemonade stand, but once you have a company with 100 or 100,000 people politics is going to rule the executive level. A critical part of office politics is to control information. Thus you get an absolute rule that the engineering types are to be kept as far away from the customer as possible. Information such as the project is going to be late is not something that almost anyone at any management or higher level wants anyone anyone at any other management or higher level to know.

This sort of secrecy then allows grasping managers and executives to whip, threaten, make empty promises, etc to the engineers to get them to work evenings, weekends, etc all to meet some BS targets, except those targets will get various executives bonuses that are multiples of an engineer's salary, where they then magnanimously take the engineers out for a big pile of pizza or an all you can eat buffet. "on the company's dime" that might work out to $20 engineer while that manager gets a 50k bonus that quarter alone largely because of the foolish engineers who were preached at about company loyalty and dedication.

But where this all breaks down is that you have a number of typically very very smart engineers, developers, researchers, etc, who find themselves micromanaged by people who are given a higher level of authority but who drop the responsibility to the engineers. Yet the engineers aren't allowed to communicate with the customers so they don't really know the problem, they get arbitrary deadlines handed to them. They don't get to prioritize. And worst of all the people who are typically higher up from managers tend to be morons as this is often a BS job that most people with two brain cells to rub together would reject. Sometimes the managers are former engineers but this is where the whole peter principle/fail up thing exists.

Even in huge "respected" organizations like NASA and Boeing you hear stories where engineers are saying. If you do X then Y will blow up and kill lots of people. Then some manager overrides them as they are afraid to say no to their higher ups and so on to meet some arbitrary deadline for building something that the engineers who will build it had no input on the top down design which is basically crap.

The pattern that I see and suspect even exists at places like NASA is that what happens is that very very smart engineers succeed despite all the terrible obstacles put in their way. Instead of good solid planning (not paperwork, but actual planning) they probably are fighting one fire after another while slipping some good engineering into the projects when the managers aren't looking.

Then just as any engineers are achieving something resembling success they get a copy of the payroll and realize the project manager who has less business experience or education than your average dishwasher but did get their PMP is paid twice what they are paid. Moral just went to zero and now your engineers come in at 9am and leave exactly at 5pm and don't answer calls on weekends anymore. Don't tell them that the CEO of the 50 person engineering firm's has a travel and entertainment budget that is 3 to 6 times their annual salary, the COO has one that is 3 times, and that the CFO just got his 50k MBA paid for by the company while they can no longer expense a weekend course in town attended on their own time to get certified on a key technology the company is using in their next project.

Why this last set of disparities? The executives are where the money decisions are made and the engineering department is not.

One of the interesting bits is that what I see on a very regular basis is where those extraordinary developers engineers etc go is into business for themselves. They usually develop some product on their own that would have made the company millions but they do it on their own and usually without hiring any managers at all. Their old companies don't even realize what they lost as the lying and cheating of the managers and executives will never acknowledge their mistake but will just blame the defenseless and work the remaining engineers even harder.

If I had to boil it down to a pair of lines:

Management usually hates engineering because they are significantly smarter and less disposable than the management themselves; thus in their insecurity they use their control of the finances to be right bullies.

中文

在几十年与各种规模的软件相关公司打交道的过程中,我学到的经验是,你们有一个人格和财务问题。

也就是说,很少有公司是由真正的工程师管理的。他们都是由数学家、律师、首席财务官、营销人员等管理。这些人并不 "了解 "程序员、工程师等。他们不喜欢他们,不理解他们,不与他们相处,甚至没有许多重叠的利益。反过来说也是大体如此。

例如,如果你去一家大型金融机构,你会发现C-Suite在28楼,可以看到水面上的风景,而构建运行公司的算法的IT人员则在某个地牢的无窗部分。或者,如果你去一家工程公司,工程师们将是开放式的,有垃圾灯、椅子、桌子和隔板,而高管们都有自己的独立办公室。

因此,高管们开始雇用与自己相似的人与 "怪异 "的工程师们 "沟通"。因此,像拥有PMP的PM、产品经理等就诞生了。

这些人在高管的压力下,以一种方式做事,而创造者确实应该以另一种方式做事。但这是一个等级制度。这不是一个谈判,这不是一个热衷于反馈的系统。高管们决定,工程师们应该执行。他们真的不喜欢工程师说这样的话:"这个期限是不可能的。你可以选择快,也可以选择好,但你不可能两者兼得。" 这就是那种会让高管发怒的事情。他们在季度计划中说他们要提供好的和便宜的,工程师怎么敢这么失败。最糟糕的高管们没完没了地抱怨,工程师们永远不会对涉及大量研发工作的事情给出一个合适的答案。他们开始喋喋不休地谈论无聊的事情,比如所有的未知数。同样,这位高管向董事会做了一个关于下一版本的产品如何以一半的成本拥有两倍的电池寿命的报告。难道整个工程部门都在密谋让他成为一个骗子?

然后你有内部政治。这种事情甚至发生在一个柠檬水摊的层面上,但是一旦你有一个拥有100或100,000人的公司,政治就会统治行政层面。办公室政治的一个关键部分是控制信息。因此,你会得到一个绝对的规则,即工程类人员要尽可能远离客户。诸如项目要迟到这样的信息,几乎是任何管理层或更高层次的人都不愿意让任何其他管理层或更高层次的人知道的。

这种保密性使得那些抓狂的经理和高管们可以对工程师进行鞭打、威胁、做出空洞的承诺等,让他们在晚上、周末等时间工作,以达到一些虚假的目标,只是这些目标会让不同的高管获得数倍于工程师工资的奖金,然后他们会宽宏大量地带工程师去吃一大堆比萨饼或所有你能吃的自助餐。"用公司的钱",这可能是20美元的工程师,而该经理在那个季度获得了5万奖金,主要是因为那些被宣扬为对公司忠诚和奉献的愚蠢的工程师。

但是,这一切的破绽在于,你有一些通常非常聪明的工程师、开发人员、研究人员等,他们发现自己被那些被赋予更高权力的人微观管理,但他们把责任丢给工程师。然而,工程师们不被允许与客户沟通,所以他们并不真正了解问题,他们得到了任意的最后期限。他们不能确定优先次序。最糟糕的是,那些通常是经理以上级别的人往往是白痴,因为这往往是一个BS工作,大多数有两个脑细胞的人都会拒绝。有时经理是前工程师,但这是整个彼得原则/失败的事情存在的地方。

即使在像NASA和波音这样巨大的 "受人尊敬的 "组织中,你也会听到工程师说的故事。如果你做了X,那么Y将被炸毁,并杀死很多人。然后一些经理推翻了他们,因为他们害怕对他们的上级说 "不",等等,以满足一些任意的最后期限来建造一些东西,而建造这些东西的工程师对自上而下的设计没有任何意见,这些设计基本上是垃圾。

我所看到的,甚至怀疑存在于像美国国家航空航天局这样的地方的模式是,尽管有所有可怕的障碍,非常聪明的工程师还是成功了。他们没有良好的坚实的规划(不是纸上谈兵,而是实际的规划),他们可能是在一个又一个的火灾中战斗,同时在经理们不注意的时候把一些好的工程塞进项目中。

然后,就在任何工程师取得类似成功的时候,他们得到了一份工资单,并意识到项目经理的商业经验或教育程度比你的普通洗碗工要低,但确实得到了PMP,他的工资是他们的两倍。士气降到了零,现在你的工程师早上9点上班,下午5点下班,周末也不接电话了。不要告诉他们,50人的工程公司的首席执行官的旅行和娱乐预算是他们年薪的3到6倍,首席运营官的预算是3倍,首席财务官刚刚拿到公司支付的5万块钱的MBA,而他们却不能再花钱在城里用自己的时间参加周末课程,以获得公司在下一个项目中使用的关键技术的认证。

为什么会出现这样的差异?高管们是做出金钱决定的地方,而工程部门则不是。

有趣的一点是,我经常看到的是,那些非凡的开发人员、工程师等人的去处是为自己做生意。他们通常自己开发一些产品,而这些产品本来可以为公司带来数百万的收入,但他们自己做,而且通常根本没有雇用任何经理。他们的老公司甚至没有意识到他们失去了什么,因为那些撒谎和欺骗的经理和高管永远不会承认他们的错误,而只是责怪那些毫无防备的人,让剩下的工程师更加努力工作。

如果我不得不把它归结为一对线。

管理层通常讨厌工程人员,因为他们明显比管理层自己更聪明,更不容易支配;因此在他们的不安全感中,他们利用对财务的控制权来做正确的欺凌者。