笔记针对以下问题：

1. 在c语言中，sizeof运算符和strlen()函数有什么区别的？
2. 如果/字符串/字符指针/用来存储汉字，对于这两者的计算结果有影响吗？
3. 在C++中，sizeof运算符和strlen()函数的定位？
4. 在C++中，string的lengt()和size()
5. 在C++中，string用来存储汉字时，……

在 C++ 中怎么去除字符串首尾的空格？怎么去掉字符串中所有的空格？

网上可以查到很多，有用 C 写的，有用纯 C++ 写的，混合的更是大有人在。功能都能实现，但哪个是最佳实践的？有以下几个标准 or 问题？

• 代码足够简洁
• 怎么保证效率？
• 通用性：跨平台
• 要不要考虑 C 调用问题？

2016/9/8 17:07:08

最近对于在类中使用的 static 有几个疑问，逐一列举并给出解惑。

问题一

问题一：我们都知道 C++ 类的静态成员变量在使用前必须要初始化。可是为什么一定要初始化呢？如果不初始化，为什么报 ld 链接错误？

先强调一点，其中的使用包括在类的成员函数中对静态成员变量的访问。

如果对于类的内存模型稍微理解那么一点点，这个问题其实很简单。

1. 类的定义是在 POD 结构体的基础上进行了的升级，定义类本质上是对其普通成员变量（不包括静态成员变量）的封装，就是 C 中普通的结构体。

2. 对于其静态成员变量，可以理解为在此结构体外声明的 C 语言静态变量，并且在结构体与静态此变量之间建立了某种映射关系（绑定）。

在项目开发中，非主体逻辑的部分在整体代码量中占得比重往往更大。比如我们做一个加减乘除计算器，需要处理用户输入非数字怎么办，数字太大溢出怎么办，零作为除数了怎么办等等；比如我们要读取配置文件中的用户名、密码，我们得首先处理配置文件不存在，内容格式不正确，用户名过长等等。

机器（具体说就是一门语言，比如 C++）是一板一眼的，你告诉它了它就能做，你没告诉的它就不知道。对机器来说不存在“常识”这个词。

用 C++ 写代码的时候总是避免不了处理错误，一般来说有两种方式：通过函数的返回值 return code；抛出异常 exceptions。

使用返回值的缺点

从 C 语言过渡过来的开发者可能更习惯使用返回值。就我自己的开发经历（给某个风场使用 Labwindows/CVI 开发自动化采集软件）来说，使用返回值有四点很是不爽的地方：

不打算在 Java 方向上投入精力，但是工作中又免不了涉及有关的开发任务。在此整理、汇总一些链接，希望给日后有关 Java 的工作带来方便。

微软、Visual Studio 和 Visual C++ 那些事……

.NET 框架

.NET 框架（.NET Framework）的 维基百科 中有很详细的阐述，其中的 组件堆栈图 一目了然，对于 .NET vs. Java EE 和 .NET vs. COM 的介绍也言简意赅。以下摘取几句，做笔记。

.NET框架是以一种采用系统虚拟机运行的编程平台，以通用语言运行库（Common Language Runtime）为基础，支持多种语言（C#、F#、VB.NET、C++、Python等）的开发。

通用中间语言被设计来即时编译（JIT），而Java的字节码在最初的时候则是设计成用于解释运行，而非即时编译。

前一版软件组件技术由Microsoft所提出的COM，该技术被用来创建大型（large-scale）的软件系统上，使用COM+ 或MTS对于传统分布式组件有强化的作用。很明显的，Microsoft最终将以.NET全面替换COM成为软件组件的架构。

.NET 的语言

CLI是一套运作环境规范，包括一般系统、基础类库和与机器无关的中间代码，全称为Common Language Infrastructure。如果一种语言实现生成了CLI，它也可以通过使用CLR被调用，这样它就可以与任何其他.NET语言生成的数据相交互。CLR也被设计为操作系统无关性。

CLI被设计成支持任何面向对象的编程语言，分享共同对象模型与大型共同类库。

大部分的语言都做了重大改变以搭配.NET框架。厂商通常利用这个机会来同时改变语言的其他特性。

1. C#，一个以C++和Java语法为基础开发的一个全新的面向对象语言，是.NET开发的首选语言。

   我们圈外人以为做 C# 的就是 .NET，其实前者只是后者的官方开发语言。

2. Visual Basic .NET，一个加强了面向对象支持的，支持多线程的Visual Basic版本。

   VB .NET 和 VB 不同。

3. C++/CLI，一个C++的.NET平台版本变种。

   接下来我们就说说这个。

托管 C++ 和 C++/CLI

托管C++并非独立存在的编程语言，而仅仅是微软对C++的一个语法扩展，允许C++程序员在.NET框架和CLR的基础上进行托管编程。

C++ 托管扩展（Managed Extensions for C++，也经常被称为“托管 C++”）自Visual C++ 2005起被正在标准化的C++/CLI所替换。

目前只有托管C++及其后继者C++/CLI可以做到无缝集成托管和非托管代码，在托管代码中调用COM的速度又相当慢（所以用非托管代码调用咯），所以经常被用于其他语言和非托管代码之间的桥梁。

C++/CLI（CLI: Common Language Infrastructure）在计算机语言中是一门由微软设计，用来代替C++托管扩展（Managed C++，下文使用MC++指代）的语言。这门语言在兼容原有的C++标准的同时，重新简化了托管代码扩展的语法，提供了更好的代码可读性。

托管代码和本地代码

在维基百科 托管代码 的词条中提及托管代码的运行：

运行代码时，运行库编译器（runtime-aware compiler）在受控运行环境下，将中间语言（Intermediate Language）编译成本机的机器码。受控运行环境可为代码插入垃圾回收、异常处理、类型安全、数组边界和索引检查等，以保证代码安全的运行。

另有 博客 介绍的很好。

Visual Basic .NET和C#只能产生托管代码。如果你用这类语言写程序，那么所产生的代码就是托管代码。如果你愿意，Visual C++ .NET可以生成托管代码。当你创建一个项目的时候，选择名字是以.Managed开头的项目类型。例如.Managed C++ application。

跟Visual Studio平台的其他编程语言不一样，Visual C++可以创建非托管程序。当你创建一个项目，并且选择名字以M FC，ATL或者Win32开头的项目类型，那么这个项目所产生的就是非托管程序。

托管代码和非托管代码性能的比较：理解这个问题的关键在于对“即时编译器”和“解释器”是否有正确的认识。

.Net程序被加载入内存以后，当某段IL代码被第一次运行的时候，JIT编译器就会将这段IL代码，全部编译成本地代码，然后再执行。这也就是为什么.NET程序第一次运行都启动很慢的原因！ 随.NET库，微软还附带了一个工具，可以事先将.NET程序所有的IL代码都编译成本地代码并保存在缓存区中，这样一来，这个程序就跟c++编译的一模一样了，没有任何区别，运行时也可以脱离JIT了（这里不要混淆了，这里不是说可以脱离.NET库，而是说不需要在进行即时编译这个过程了）。

所以，请不要将.NET和Java混为一谈，两个的运行效率根本不是一个等级的！

打包工具

我们在 VS2010 中更习惯使用 Visual Studio Installer 打包项目，进行安装和部署。但不知什么原因（目前我还不知道，也没有在网上认真找过 资料），微软放弃了自家的这款工具，在 VS2012 中不再有，而只能用 InstallShield Limited Edition，同时更新过 VS2010 的朋友也会发现在“安装和部署”下除了原有的 Visual Studio Installer，也增加了 InstallShield LE 项目，看来微软是铁了心放弃 VS Installer 了，那我们也没有坚守的必要了。除非公司跟不上时代，否则还是早放弃的好。

在 stackoverflow 上 Create MSI or setup project with Visual Studio 2012 说了同一件事情。好在 InstallShield LE 太难用，最关键的是在对 ActiveX 控件、Windows services的支持上有 硬伤，事情出现 转机，Visual Studio Installer 通过扩展的形式重新回到 VS 中，不过貌似只有 VS2013 和 2015 版本，但也足够了，你说呢？你要是死磕 VS2012，何必呢

• Microsoft Visual Studio 2013 Installer Projects
• Microsoft Visual Studio 2015 Installer Projects

预编译头

• 理解微软的预编译头技术 - csdn
• stdafx.h - 163
• 预编译头文件的使用 - csdn
• 预编译头 - wikipidea

进阶操作不包含基础，进阶分为两部分：使用分支和修改提交。主要整理自 猴子都能懂的 GIT 入门。关于工作流，罗列了几个链接，值得反复阅读学习。

其实我们在 Git 官网 就能找到最好的学习材料：《Pro Git》。知识点讲得很全，也讲得很好。无论是进行系统的学习，还是作为参考手册都是不二之选！但如果你真的只有 5 分钟时间，还要快速上手使用，拿这么一本书显然是不合适的，所以就推荐了上面的入门贴。实际工作中，碰到什么问题，我都是来翻书的。

使用分支

先确定运用规则才可以有效地利用分支。

Merge 分支

Merge 分支是为了可以随时发布 release 而创建的分支，它还能作为 Topic 分支的源分支使用。保持分支稳定的状态是很重要的。如果要进行更改，通常先创建 Topic 分支，而针对该分支，可以使用Jenkins 之类的 CI 工具进行自动化编译以及测试。

通常，大家会将 master 分支当作 Merge 分支使用。

Topic 分支

Topic 分支是为了开发新功能或修复 Bug 等任务而建立的分支。若要同时进行多个的任务，请创建多个的 Topic 分支。

Topic 分支是从稳定的 Merge 分支创建的。完成作业后，要把 Topic 分支合并回 Merge 分支。

分支的合并

完成作业后的 topic 分支，最后要合并回 merge 分支。合并分支有2种方法：使用 merge 或 rebase。使用这2种方法，合并后分支的历史记录会有很大的差别。

merge

进行 merge 的话，分为两种情况：

1. fast-forward（快进）合并

   合并 bugfix 分支到 master 分支时，如果 master 分支的状态没有被更改过，那么这个合并是非常简单的。 bugfix 分支的历史记录包含 master 分支所有的历史记录，所以只要把 bugfix 移动到 master 分支就可以导入 bugfix 分支的内容了（即将 master 的 HEAD 移动到 bugfix 的 HEAD 这里）。这样的合并被称为 fast-forward（快进）合并。

   这种场景不会产生新的提交。

2. non fast-forward

   但是，master 分支的历史记录有可能在 bugfix 分支分叉出去后有新的更新。这种情况下，要把 master 分支的修改内容和 bugfix 分支的修改内容汇合起来。

   因此，合并两个修改会生成一个提交。这时，master 分支的 HEAD 会移动到该提交上。

Note

执行合并时，如果设定了 non fast-forward （--no-ff）选项，即使在能够 fast-forward 合并的情况下也会生成新的提交并合并。

执行 non fast-forward 后，分支会维持原状。那么要查明在这个分支里的操作就很容易了。

阮一峰老师写到：

使用 --no-ff 参数后，会执行正常合并，在 Master 分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。

rebase

这个没有亲自实践过，要认真学学。

1. 首先，rebase bugfix 分支到 master 分支, bugfix 分支的历史记录会添加在 master 分支的后面。

   这时移动提交 X 和 Y 有可能会发生冲突，所以需要修改各自的提交时发生冲突的部分。

2. rebase 之后，master 的 HEAD 位置不变（此时就是典型的 fast-forward merge 场景了）。因此，要合并 master 分支和 bugfix 分支，即是将 master 的 HEAD 移动到 bugfix 的 HEAD 这里。

rebase 最大的优点是：历史记录成一条线，相当整洁。在《Pro Git》书中提到：

变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的，但它们看上去就像是先后串行的一样，提交历史是一条直线没有分叉。

一般我们这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁——例如向某个别人维护的项目贡献代码时。在这种情况下，你首先在自己的分支里进行开发，当开发完成时你需要先将你的代码变基到 origin/master 上，然后再向主项目提交修改。 这样的话，该项目的维护者就不再需要进行整合工作，只需要快进合并便可。

同样，在书中也提到了变基的风险，作为新手我们并不需要做过多的学习。

具体练习见 用 rebase 合并。

改写提交

参考自 改写提交。改写提交非常容易出现冲突，需要人工合并。

“改写提交”，我觉得《Pro Git》的表达更好一些——“重写历史”。因为有关的操作大多比较敏感，都有后遗症，操纵不当更会变成灾难，所以建议 认真读书、反复练习之后再在实际项目中操作。

在进入正文之前，我们必须清楚 ^ 和 ~ 的区别：What’s the difference between HEAD^ and HEAD~ in Git?

强调：~ 是对 ^ 的复合运算，而不是 ^n 的复合运算。

修改最近的提交

git commit –amend

取消过去的提交（内容）

git revert 可以取消指定的提交内容。

虽然使用后面要提到的 rebase -i 或 reset 可以直接删除提交，但是有时候并不合适（甚至不能）直接删除提交，比如不能随便删除已经发布的提交。这时就可以通过 revert 创建（否定某一次提交的）提交。

遗弃提交

git reset 除了默认的 mixed 模式，还有 soft 和 hard 模式。

主要使用的场合：

• 复原修改过的索引的状态(mixed)
• 彻底取消最近的提交(hard)
• 只取消提交(soft)

提取提交

cherry 樱桃

git cherry-pick 可以从其他分支复制指定的提交，然后导入到现在的分支。

例如，假设我们有个稳定版本的分支，叫 v2.0，另外还有个开发版本的分支 v3.0，我们不能直接把两个分支合并，这样会导致稳定版本混乱，但是又想增加一个 v3.0 中的功能到 v2.0 中，这里就可以使用 cherry-pick 了。

改写提交的历史记录

git rebase -i

这个命令很强大，在 rebase 指定 -i（interactive，交互式的） 选项，可以改写、替换、删除或合并提交。但也有一些副作用……

请翻书，重写历史

副作用？

场景描述：今天进行 rebase -i 操作后发现 merge –no-ff 的分支合并记录都没了


ps：借着这张图，复习一下 ^ 和 ~ 的知识。

• git reset head~，head 变更为 7c8d8a；
• git reset head~2，head 变更为 6af94；
• git reset head~^2，head 变更为 78663f；
• git reset head4，报错！因为 head4 不存在
• 强调：~ 是对 ^ 的复合运算，而不是 ^n 的复合运算。(7c8d8a)^2~ = 6af94d = (7c8d8a)~

返回来继续说，执行 git rebase -i head~3 后结果如下：


在执行 git rebase -i head~3 时对话框如下：

1
2
3
4
5
6

pick 6af94d1 modify name.txt
pick 78663ff new age.txt            （笔者注：7c8d8a2 透明的）
pick 915b8b1 re modify name.txt

# Rebase d0cd09d..915b8b1 onto d0cd09d (3 command(s))
#

可以看到，是不存在任何合并节点的。这也是 rebase 的目的！

疑问：如果我只是想改写 7c8d8a 之前某个 commit 的备注信息，且不想丢失分支演进，改怎么做呢？

结论：其实这算不得 rebase -i 的副作用，git rebase 默认 ignore merges。我自己以期上述目的，是用错了命令，虽然我至今不知道怎么实现上述目的 查看 --preserve-merges 参数。再往深的追究，其实我至今都不知道该怎么使用 git 去实现一个完善的工作流程，我了解一些命令的用法，但去不知道该怎么组织一个工程，怎么对一个项目进行细致的、完整的版本管理？

参见 git rebase --preserve-merges 手册。此参数的某些使用情景很乱，见 What exactly does git’s “rebase –preserve-merges” do (and why?)

汇合分支上的提交，然后一同合并到分支

git merge –squash

TortoiseGit 的 Show RefLog

TODO：感觉很有用哎，今天进行 rebase -i 操作后发现 merge –no-ff 的分支合并记录都没了，而且进行了两次 reabse -i，所以也没办法通过 git reset ORIG_HEAD 恢复。幸运的是发现了 RefLog 的存在，不知道这是 Git 本身的功能，还是 TortoiseGit 的功能扩展。抽空查探一下。

是 Git 自身的机制，很强大！官方手册，真心没有探索的欲望，怎么破？

其他

Tips

不同类别的修改 (如：Bug修复和功能添加) 要尽量分开提交，以方便以后从历史记录里查找特定的修改内容。

Tips

查看其他人提交的修改内容或自己的历史记录的时候，提交信息是需要用到的重要资料。所以请用心填写修改内容的提交信息，以方便别人理解。

以下是Git的标准注解：

1
2
3

第1行：提交修改内容的摘要
第2行：空行
第3行以后：修改的理由

请以这种格式填写提交信息。

Get

切换分支使用 checkout，检出文件也使用 checkout……不是因为作者懒得起名字，而是因为两者本质是同一种操作，都是从版本库（或索引）检出文件到工作区。分支本质上是某一个提交（的引用），切换分支就是检出对应的提交。

Get

如果在log命令添加 --decorate 选项执行，可以显示包含标签资料的历史记录。

在 windows 下搭建 git 服务器

2016/12/15 12:49:18 前两天将写的代码误删了，没有用版本管理工具。代码在一台连不上互联网的服务器上，因为系统老旧的原因，使用上有好多限制，负责人担心在新系统上写的代码拿到旧系统（最终必须部署在旧系统上）上用还得再次修改兼容性之类的问题，所以一般都是在旧系统上直接一个字母一个字母的敲代码。误删上周的工作内容后，后悔之余，也得考虑以后怎么避免这种情况。

在旧系统上凑活能装上 git，很原始的版本了。但它只能访问到我的笔记本（局域网），而不能访问互联网，所以就需要在 E431 windows7 的电脑上部署 Git 仓库。

• 在 Windows 上搭建 Git 服务器

依据上一篇搭建完成之后，操作中报错：（看着好像是不能是 --bare Repo 啊）

• git “fatal: no matching remote head”

工作流

工作流 flow，对于大团队和个人肯定是不一样的，不能一概而论。对于个人开发，其重点最终要落在对分支 branch 的利用上，只要合理安排分支基本就可以了。对于人员很多，强调合作开发的团队，在上述基础上还要找准各节点（每个开发人员）的定位，会变得复杂很多。

一个完整的工作流包括对分支的利用、对节点的安排。好在大多时候我们只需关注前面一部分就能达到目的。

分支的安排

在 3.4 Git 分支 - 分支开发工作流 中描述了“长期分支”和“特性分支”两个概念。

在 Git分支管理策略 - 阮一峰 中使用了两个常设分支（长期分支）和三个临时分支（特性分支）。master 用于正式发布，develop 用于日常开发；feature 功能分支，Release 预发布分支，fixbug 修补分支。此策略即 Git flow。

合并分支使用 --no-ff 选项。

Git flow 并不完美，Git 工作流程 - 阮一峰 中又讲解了另外两种分支策略：Github flow、Gitlab flow。推荐 Gitlab flow。在摸索中学习，在学习后实践。

ps：2017/2/23 15:23:53 我现在认为基于“版本发布”的，还是使用 git flow 更好一些，更符合直觉，更何况有那么多的前辈们（非 web 开发）都是如此呢。

gitlab flow

如何使用gitlab的flow以及代码review

GitLab Flow的使用

分布式节点的安排

在 5.1 分布式 Git - 分布式工作流程 中提到三种

集中式工作流、集成管理者工作流、司令官与副官工作流。

个人开发或者小团队开发，使用前者足够了。这种单点协作模型完全符合人们的直觉，好多人虽然不知道“集中式工作流”这个名词，但已经在这么用了。

其他

• how-to-use-github

  对网络上众多资源的一个整理。

• 7.3 Git 工具 - 储藏与清理

  git stash 和 git clean

个人学习笔记，学习的总结，肯定是采用文字的形式记录。是以纸笔墨砚的形式，还是以更现代的码字的形式？上学的时候还固执于前者，写写画画了好几个本子，每个上面都有些文字，却也都不成系统，而且基本上全是个人日记，记录心情，发泄情绪。工作后渐渐放弃了纸笔间的习惯，喜欢在键盘上码字，整理的内容也由日记全部过渡成了技术帖。一开始在印象笔记中零零散散保存，后来同时使用为知笔记并逐渐过渡了日记使用前者，技术帖使用后者。因为基本不再写日记，印象笔记也就变成了存储记忆的空间，还是不翻书的那种。

后来迷上 markdown，有半个月打算放弃为知笔记，后来发现 markdown 只能替代为知笔记默认编辑器的位置，而个人知识管理的体系、框架的建立与维护还是得靠为知笔记。但两者的结合并不完美，核心问题在于技术人员（指我自己）使用 GFM，而为知笔记的 markdown 解释器并不能完全支持 GFM，尤其是语法高亮方面（主要使用 shell、vimL、console 的支持），GFM 不支持 [TOC] 标签。

使用 MarkdownPad 2 编辑文字很爽，但保存的 .md 文档在查阅时并不直接。将其拷贝到为知笔记中在首部添加 [TOC] 标签后发布，阅读时直观，查找时无论是根据多层级文件级树形查找还是直接使用内建的搜索框直接搜索都是很方便的，不足之处在于：

• 一方面即便其支持 markdown 编辑，但并不友好，尤其是在使用 MarkdownPad 2 之后；
• 另一方面，使用 markdown 语法的前提下，无法实现在笔记中插入对另一篇笔记的引用（链接），这在整理系列笔记时尤其不能容忍。

想通过搭建个人的博客网站来解决上述矛盾：保留使用 MarkdownPad 2 编辑文字的习惯，放弃为知笔记，将文字直接发布到外网上就可以解决无法链接、笔记之间相互跳转的问题。此种情况下带来一点点不便，如果帖子中涉及个人隐私、公司商业机密（我笑），需要仔细筛选。

在搭建个人博客的摸索阶段，从为知笔记到博客网站的过渡阶段，依然会使用为知笔记，并不在时间轴上一刀切，一下子将为知笔记中的内容全部拷贝到网站中，然后清空、销户。

使用 GitHub Pages 和 Hexo 搭建个人博客，静态网页会在 Github 中保留有版本记录，但源 .md 文件的存储（乃至版本控制）尚需考虑：

• 对编辑的过程（版本控制）要求高，考虑 在 ~\hexo\source 创建版本库；2020/12/25，折腾一遭还是选择此方案

• 只要求结果（对版本控制要求低），有 .md 文件的备份即可，考虑整体迁移到 Dropbox 中；

  因为 hexo\blog\source\_posts 目录（.md 源）只能在 hexo 树形目录的固定节点，所以想将其备份到 dropbox 中，需要 trick / workaround，Windows下硬链接、软链接和快捷方式的区别

• 图片库的问题，考虑使用图床；2020/12/25，PicGo+GitHub，谁用谁知道

• 对目录有需求，使用哪种实现呢？[TOC] 不解析，使用支持目录的主题。

搭建博客

阮一峰老师说喜欢写 Blog 的人，会经历三个阶段：

第一阶段，刚接触 Blog，觉得很新鲜，试着选择一个免费空间来写。
第二阶段，发现免费空间限制太多，就自己购买域名和空间，搭建独立博客。
第三阶段，觉得独立博客的管理太麻烦，最好在保留控制权的前提下，让别人来管，自己只负责写文章。

在网上查找两篇教程，按部就班的操作就能得到结果。目前对于博客没有任何复杂的要求，对评论、对布局、主题都没有挑选的欲望。博客只是用来将自己的整理的笔记、学习总结放到互联网上存储，查阅时不用再打开为知笔记，不用打开 MarkdownPad2 实时生成，带来查阅时的便利即可。

对于评论，教程中多提及中文用户推荐“多说”，起步阶段没有需求，加上暂时不想再多花时间在这些“边缘”上，所以未开启评论功能。总的来说，博客还是处于自我查阅阶段。

参考 hexo 官方站点 的介绍，在 下载安装 Node.js 之后，执行以下命令即可完成搭建。

• 下载 Node.js 时，不使用代理时下载飞快；
• 安装 Node.js 的过程会自动配置 Path，安装完毕使用 powershell 输入 node 验证
• 使用 NexT 主题

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$ npm install hexo-cli -g
# 初始化 Hexo 框架
$ hexo init blog 
$ cd blog
# 安装相关依赖包
$ npm install
$ hexo server
# 使用 NexT 主题
$ npm install hexo-theme-next
# set `theme` variable to `next`
$ vim _config.yml

# 通过 github 发布需要
$ npm install hexo-deployer-git
# 使用本地搜索需要
$ npm install hexo-generator-searchdb 

拉取笔记仓库，并替换 source 目录：

1. 进入 blog\ 目录，
2. 执行 git clone git@github.com:tnie/notes.git，
3. 然后 rm source -rf && mv notes source
4. 安装 Next 主题 npm install hexo-theme-next
5. 使用仓库中的配置文件，更新 blog 的配置项目。

注意：绑定本地 hexo 和个人的 Github Pages 后（修改全局配置文件），执行 hexo deploy 命令部署时需要先 npm install hexo-deployer-git -S

发布博客

整理完笔记之后，怎么发布到 github.io 上？在这里针对具体的步骤做一份备忘录，防止因为懒惰或其他原因较长时间不发博客，“回归”时还要再次花费时间查阅 Hexo + GitHub Pages 技术帖子。而且，技术相通，但每个人都会培养出属于自己的习惯，不想“回归”时再摸索。

1. 在 Git Shell 中打开至 hexo 目录。 cd hexo

2. 敲入 hexo new "filename" 命令。此命令会在 source/_posts 目录下创建 filename.md 文件

   • filename 建议使用英文，且不要存在空白字符。可以使用下划线 _ 连接两个单词。
   • 用翻译工具查一查，起个好名字。

3. 打开 source/_posts 目录，使用 MarkdownPad2 编辑文字，修改 title tags categories 属性，保存。

   • 一般来说，都是将写好的笔记全文粘贴过来。记得删除源文件，在过一段时间之后维护多个相似文件是很痛苦的。
   • title 使用中文；tags categories 原则上一律小写。
   • tags 属性存在多个时，可以这样写 tags: [make,makefile]，但注意每一个 tag 中不能有空格，比如 tags: design pattern 这是错的

4. 敲入 hexo generate 生成静态网页。

5. 敲入 hexo server 启动本地服务器，查看效果。

6. 敲入 hexo deploy 发布到互联网。

7. 迁移为知笔记中的内容。“迁移”顾名思义，要从为知笔记中删除。

参考链接

有讲述整体流程的，有着眼于模块的——描述主题的、强调分类和标签的、添加站内搜索、添加评论的……

3. 其中，在 Debian8 上安装 Node.js 使用 其官方 的 Linux Binaries (.tar.xz) 版本。解压之后直接配置系统 PATH 路径即可。tar xJvf node-v4.4.7-linux-x64.tar.xz
4. 如果有更换域名的需求，可以参考 简明Github Pages与Hexo教程，而且作者是在 win7 环境下搭建的，同时文末给出了大量的参考资料。

主题

官方是有 辣么多的主题 让我们选，挑花了眼。

2017/4/13，使用新的主题 NexT。原因有二：

• Jacman 的搜索不能用。网上有很多其搭配 swiftype，但其他的第三方（比如谷歌）却怎么都调试不成功。
• Jacman 作者自己貌似都放弃了，作者自己的博客 使用 NexT 主题是其一，不再维护 Jacman 是关键。

使用 NexT 主题，碰到的问题 —— 其 404 页面的配置在使用 https 协议时有问题：

Hexo NexT 主题给出的腾讯 404 公益页面的教程仅适用于非 HTTPS 站点，对于严格限制混合内容的 HTTPS 站点来说，腾讯 404 公益页面使用的 JS 文件是无法引入的。

解决方案：关于 Hexo 上传 404 页面的问题

目录和标签

Hexo使用攻略：（四）Hexo的分类和标签设置

目录和标签有什么区别？关键词：一个目录，多个标签；树状结构，网状结构；

1. 怎么给文章添加合适的标签呢？
2. 在目录上尽可能的粗放，再用标签进行管理
3. 使用树状目录尽量不要超过3级。
4. 树状目录应该是和标签系统互补的；
5. 标签起一种聚合作用，将相关性很强的东西联系到一起；分类目录则是相当于存放同类文章的容器，里面的文章虽属同类，相关性却可能不太强。
6. 多参考大牛们的网站

不建议你“未雨绸缪”的打上标签。而是在有一定数量的笔记有大量相同性时，再打上标签，目录也是如此。

遵循这么一个原则：想一下读者看了这篇文章后，还会对哪些其他的文章感兴趣，然后这些文章就都添加上同一个标签。这样标签就可以实现目录交叉

其他

利用swiftype为hexo添加站内搜索v2.0

swiftype 试用结束后，只能付费。免费试用期到期后，官网登录之后无论点击哪里都是“Your Swiftype free trial has come to an end” 页面，猜测 swiftype 不再提供免费版本，佐证。需要寻找备案了……

使用本地搜索，安装插件（需要相应的配置项）。

1

npm install hexo-generator-searchdb --save

过程也是结果

在整理笔记的时候肯定会从网上查找资料，每个知识点肯定都会碰到一篇帖子让自己感慨“哇，总结得好好，娓娓道来，该讲的都讲到了，却也不多一句废话”，每每到此刻都觉得自己整理的笔记就是一坨垃圾，用词不当，表述不清晰，上下文转接不流畅，有的重点落下没讲，废话说太多……可这就是成长必经的过程，如果不是整理这个知识点，就不会一板一眼、较真地去查阅好多资料，线上的博客、线下的书，随手 google 来的终究只是编码过程中的 code demo，而非知识，只有当你读了很多篇笔记，看过了很多风景，才能有足够的理解，才能通过已经掌握的，通过对比，认识到某一篇是够精彩的。

如果因为总结的笔记太烂而气馁，放弃整理，那么就不会查阅足够的资料，就不会见到那篇“哇，精彩”的帖子！整理出来的笔记是结果，整理过程中见到的风景也是结果！

ps：在 2017/4/28 10:13:43 之前的文章大多是从 为知笔记 中手动迁移出来的。

• 源于为知笔记不支持账号销户，所以也就没有清空其中的内容，暂时保留一段时间还可以校正迁移过程中的失误；
• 但在文章全部迁移完毕之后也就不再使用为知笔记了，因为它 变更服务策略 太激进了。

我们从 GoF 说起，书中写到单例模式（Singleton）的意图是：

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

在什么时候会用到单例模式呢？开发过程中常见的应用举例：

• 日志类，一个应用往往只对应一个日志实例：丑陋的写法是在每个场景都实例化一个日志对象使用。
• 配置类，应用的配置集中管理，并提供全局访问：丑陋的写法是在每次使用配置时都实例化一个配置对象，然后访问配置文件读取其中的配置项。
• 管理器，比如我们写了一个 windows 服务，然后我们要封装一个启停此服务的管理器。
• 共享资源类，加载资源需要较长时间，使用单例可以避免重复加载资源，并被多个地方共享访问。比如文件连接，数据库连接等

原来的笔记写于 2015年11月23日，当时使用的是为知笔记默认编辑器。十个月过去了，对于 make & Makefile 也有了更多的认识。今天重新整理一下，不过仍然定位在入门的帖子，所以不会添加新的内容，只是修改表述不当的地方，对原有内容作出删减，并用 markdown 格式重写。

这篇本来是打算写成阅读笔记的。但是所知不多，刚开始学习应该博览，求入门，求上手使用。再加上看的东西越来愈多，单纯的记录一篇帖子中的重点、难点，较真于一处在实践中基本不会碰到的细节，格局太小，意义也不大。