Hexo Netlify CMS隔了好久终于迎来了一次大更新（不兼容），主要有以下的更新内容

1. 扩展fields，在原本的Netlify CMS中，fields的设置比较麻烦，这次独立出global_fields方便配置
2. 新增auto_generator用于管理post与page的生成，支持多个post配置
3. 默认配置优化，环境搭好（Netlify启用相应服务）后，不需要额外配置便能使用Netlify CMS
4. 调试优化，--debug一键修改Netlify CMS授权模式为test-repo，可直接调试

详细的文档见GitHub的Readme

不多说废话，介绍一种简单又近乎完美的主题管理方式。文章中使用Cake主题介绍，如果你使用NexT替换对应的链接。

需要提前储备的知识，如果不懂请至百度

• 基本的Git操作（Git Init/Add/Commit/Pust/Fetch/Pull）
• 基本的Node/NPM操作（npm install）或者Yarn（类似于NPM）
• 基本的Hexo命令（hexo init/cl/s/g）

前世因

这要追溯到3月份，Mimi的PR:Adding Submodule，我们讨论了如何管理第三方依赖。LEAFERx提出了使用NPM管理会更好，他进行了实践PR:Extract leancloud-counter to plugins #677 #707。在我看来LEAFERx的方案并不好，因为复杂。所以要做到插件化，有两个必须达到的要求：

1. 灵活与可扩展性，在插件中，我们就要能修改大部分内容。
2. 操作简单，我们通过极少的代码集成我们想要的功能。

除此外，ivan-nginx还关心文档的问题，但如果能完全独立，存放在插件库中也不是什么大问题。在此期间，我也进行过尝试PR:Refactoring comments，毕竟现在的评论系统真的”烂”，一堆if else。这次的重构是挺好的尝试，但我不敢轻易合，因为影响大（几乎所有人），而后来发现了另一个方案，是Hexo的一个插件hexo-inject，通过注入代码的方式实现定制内容，由于hexo本身与主题分离，它仅能提供4个注入点，可扩展性远远不够。但如果能在NexT中实现，就完全不同了，于是我提了PR:Add new filter type theme_inject

众所周知，netflix OSS 2.0 难产了，上一代的zuul网关虽说不错，但其并不是异步的。所以，Spring团队推出了基于Spring Webflux的全新异步的网关–Spring Cloud Gateway。

本文内容基于Spring Cloud Gateway 2.1.0.GA

来跟着我一步步，探索它的魅力坑吧！

展示些样式，逐步修改中~

目前使用的NexT主题，也是NexT成员。但果然还是希望自己的站点能够与众不同点，所以想写个自己的主题。整理下一些资源

参考主题

• NexT：最熟悉的
• Inside：厉害的作者，使用Angular重写了生成器

计划：基于NexT改进，参照Inside的设计风格

Canary Channel：

• 圆润化设计
• 扁平化，去除阴影效果
• banner图支持

Next Plan：多评论系统支持，重构并简化配置（@w@现在好多）

这是一篇介绍Spring Cloud Contract语言定义的文章，也就是该怎么写契约内容。如果您对Spring Cloud Contract不是很了解，不知如何更好的实践的话，可以先看下我之前的文章《Spring Cloud Contract 契约测试》

在这个框架中，我们既可以采用Groovy，也可以yaml。但由于本身属于Java的框架，在支持上Groovy要更好些，推荐且这里只介绍Groovy（事实上，我对Spring官方同时支持两种定义方式并不理解，专注一种或许会更好啊）。

该文章基于Spring Cloud Contract 2.1.0.GA

Nodejs除了赋予前端后端的能力外，还能有各种各样的脚本，极大的简单各种操作。在早期，脚本做的工作大都是生成固定的模版，所以你需要了解的，仅仅生成的项目就够了。然而，随着框架的完善，架构师往往希望通过脚本处理默认的配置或者环境，这样能减少环境差异导致的问题，还能简化升级核心框架的升级，例如Vue CLI做的事。

这时候，我们不得不探一探它的神秘面纱。

这次带来的是Create的原理解析。

Spring Cloud Contract是契约测试的一个实现，最早看到契约测试还是在《微服务设计》书中，不过那时候绝对想不到真的会接触它。

什么是契约测试？

首先，先谈谈思想，什么是契约测试？事实上在很多地方都称为消费者驱动契约(CDC) ，似乎都喜欢加驱动，比如TDD测试驱动等，但我不喜欢在这里加，契约是由提供者与消费者共同制定的，不可能由一方驱动。而契约测试也将同时作用于两方：

• 验证提供方是否履约
• 验证消费方在提供方履约下是否正常工作

由于一般都只考虑提供方的履约验证，所以误解为消费者驱动。事实呢，提供方与消费方是唯一的么？你的契约不会变么？一旦发生改变，那么契约测试也会对消费方进行验证。

在针对性的SEO优化方面

• 百度： 提供sitemap与提供百度蜘蛛自动推送
• 谷歌： 提供sitemap

就这样！