冰镇

本文为《系统分析与设计》课程作业，探讨一下软件工程概念与软件工程科学。

并不像大多数人一样，刚接触编程要么是C/C++、Java，要么是Python，我接触的第一门编程语言是Ruby，准确地说应该是Ruby的一种DSL实现——RGSS。因此，可以说我对Ruby有着偏执的感情，对Matz(Ruby之父)也是十分倾佩。

不过，虽然我是学习Ruby入门的，但是由于接触的始终是RGSS，一直没有深入了解Ruby，对Ruby元编程一大特性也从未涉及。本文将根据自己阅读《Ruby元编程(2nd)》一书，从Ruby元编程中认识Ruby这一门魔幻的编程语言。

Alpha-beta剪枝算法是极小极大搜索算法的优化，主要解决博弈问题和对策问题。这类算法被广泛运用于棋类等零和对策问题，比如井字棋(Tic-Tac-Toe)、国际象棋、中国象棋等。

本文通过alpha-beta剪枝算法实现中国象棋人机对战，了解和掌握该算法。

本文为《算法》课程上的作业，研究和实现容量设备选址问题求解的几个解决方案。本文涉及到了贪心法、局部搜索、模拟退火。

本文简单概述一下什么是IPSec以及传输模式下ESP报文的装包和拆包过程。由于作业不要求讲解隧道模式下的ESP报文的装包和拆包，这里就不提及了。

BlogReaper的第一版本的开发基本已经完成了，接下来就是更换数据库的小更新v1.1，在重构代码之前本人也不再想碰这个项目了，换数据库的任务就交给队友了。

在这里呢，总结一下这次开发所学到的东西吧，以及写一些自己心里的感想。(由于这篇文章挂着Diary的分类，所以我会写得很随心)

项目

BlogReaper名为博客收割机，实际上也是BlogReader。其实质上是一个高级的在线RSS、ATOM阅读器，通过添加自己感兴趣的RSS、ATOM源，可以正在这里分类浏览感兴趣的信息，第一时间阅读感兴趣的信息，而不需要到各个网站分别浏览。(抄袭啦！)

博客收割机这个项目主题是由我首先提出的，并同Zhenly大佬共同确认的。其实嘛，我一开始是想做纯粹的收割机，只收割认证的博客，一开始我定下来的项目名叫Blog Machine或者Blog Resource Machine。不过Zhenly大佬誓死不从，于是最后变成了Blog Reaper。(受死吧皮皮真！)

随着Zhenly大佬参考了feedly等网站，我们的博客收割机就慢慢变成了RSS、ATOM中转站了。

这个项目是《服务计算》课程上的作业，要求是做一个前后端分离的项目，比如“极简博客”。为什么不做极简博客呢？【广告】IceCream是一个由Golang实现的(伪)轻量化博客框架，也是我上个学期的《数据库》课程的作业。既然已经实现过类似的东西了，那当然要换个东西玩。不过冰淇淋并不是前后端分离，因为冰淇淋本身就是模仿hexo、gohuge设计的。不过随着冰镇重新回归到hexo大家庭，冰淇淋已经夭折且不会再更新。(其实在等待转型)

技术

本菜秀在收割机的开发中，负责后端的架构搭建、GraphQL API设计。在开发中，使用了以下的库。

• 99designs/gqlgen：GraphQL API代码生成库，Schema First，因此很舒服。
• go-chi/chi：路由库，选择它是因为gqlgen的文档范例用了它，没别的原因。
• kataras/go-session：Session库，非常小众，随便选的，其作者是iris和muxie的作者。
• PuerkitoBio/goquery：本来是搜类似jsoup的Golang库，然后搜到了这个。
• globalsign/mgo：并不是用了MongoDB，而是提供BSON服务。
• boltdb/bolt：BoltDB，键值对数据库。
• XMatrixStudio/Violet.SDK.Go：紫罗兰的Golang版本SDK。

接下来就一一谈一下我对这些库的使用感想和看法吧。

关于GraphQL

Golang的GraphQL库比较著名的有gqlgen、gophers/graphql-go、graphql-go/graphql。第三个是Star数量最多的，但是第三个是runtime types，写起代码很蛋疼，排除掉。剩下两个都是Schema First，也就是所谓的模式优先，代码写起来特别舒服。由于gqlgen文档比较多，看起来这个项目是被组织直接用于他们的产品，于是采用gqlgen。

gqlgen的确很优秀，也让我这个第一次接触GraphQL的菜鸡了解到了面向GraphQL API编程的乐趣，也了解到Resolve到底是个什么概念。不得不说，GraphQL和RESTFUL相比，其优点就在于各种复杂嵌套的Resolver。不过嘛，我觉得gqlgen不能强制生成所有Resolver这一点很蛋疼，除了默认的Query、Mutation、Subscription之外，需要在配置文件中指定强制生成的Resolver。虽然我不知道不强制生成的理由，不过既然都是写出来的约束条件了，那肯定是有用的，那就应该生成相应的Resolver呀。

其次，个人感觉GraphQL适合和关系型数据库结合使用。相比RESTFUL，GraphQL是用来解决一次请求拿到的数据有限的情景的。对于关系型数据库，通常需要使用第三范式来设计数据库，这时候用Resolver来约束相关数据的获取是很舒服的。但是对于非关系型数据库，相关数据通常都存储到同一个Document内，这时候用Resolver感觉会有数据冗余的情景发生。

当然，我个人还是觉得，不规范的RESTFUL最舒服。

关于Chi

Golang的路由库千篇一律，没啥好聊的。前面也说了，选择它纯粹是因为gqlgen文档范例用了它，复制粘贴方便。

关于Go-Session

可能算是第一次手动操作Session？之前都是使用Iris，Session都是web库实现好的，只要按文档引入就可以使用了。

不过，不得不说，往GraphQL的Resolver里面封装Session真的很蛋疼。而且，test关于Session有一个BUG，至今没有修复，完全不知道该怎么修复。

关于GoQuery

项目中用了GoQuery来获取文章的第一张图片，语法也是跟jQuery、jsoup一样，使用了选择器的语法，用起来很舒服。

关于Bolt

第一次接触基于键值对的数据库，看起来很新颖，适合玩玩。如果在实际项目中使用基于键值对的数据库，那恐怕维护起来是个灾难。并且貌似网上对Bolt的评价不是很好呀，都说速度慢。

关于Violet

Zhenly大法好。

闲谈

本次项目开发周期太短了，由于平时各种杂七杂八的事情，导致只有一周的时间开发收割机。为了尽快完成项目，Zhenly大佬砍掉了前端的几个页面，而后端的设计也是比较粗糙的。

在API的设计上，由于前期的设计失误，以及代码耦合度过高，导致我学会使用Resolver的时候，部分API已经不敢且没有办法改动了。因此部分API的效率是极低的，会在后端产生大量冗余数据，即使前端不需要。因此后面实现的API逻辑和前面的API逻辑有蛮明显的区别。

其次，在数据库的设计上也严重失误了。因为一开始不知道需要迁移到MySQL，设计上都是比较偏向NoSQL设计模式设计的，并且数据库采用BSON存储。如果要迁移到MySQL，我不敢想象这个工程量……(于是我开始寄希望于我的队友，你们加油~)

最后嘛，感觉紫罗兰是时候要升级了，不然包括测试、使用都好难受啊。(逃~

Description

There are N children standing in a line. Each child is assigned a rating value.

You are giving candies to these children subjected to the following requirements:

• Each child must have at least one candy.
• Children with a higher rating get more candies than their neighbors.

What is the minimum candies you must give?

Description

Given s1, s2, s3, find whether s3 is formed by the interleaving of s1 and s2.

Description

Given a string s1, we may represent it as a binary tree by partitioning it to two non-empty substrings recursively.

得益于Golang标准库的完善，使用Golang开发Web后端应用非常简单。也因此催生出了诸如httprouter、Mux、Muxie等multiplexer，也有类似于Gin、Echo、Iris、Beego等Web框架。

本文将从Golang标准库net/http、第三方框架Muxie的源码入手，分析一下原生的路由框架，以及如何基于原生网络库构建路由框架。

值得一提，Muxie发布至今仅有一个月。