群青い図書室

觉得还是有必要单独为此记录一篇，这是在近日几天被这个问题折腾之后的决定。
先从这里开始说吧。

ヒラギノ明朝 Pro

是的，本来觉得字体的选择是一个非常简单的问题，也是重构站点之初最先着手的问题之一，由于所需的字体内容不多，网上搜罗一番后尝试了几个选项，就选择了其中一款还算顺眼的字体。现在想来这个最初的方案确实草率了，其实这都不能算上方案，只是一个选择，再加上缺少 frontend 的 sense，后续出现了诸多的问题。

在选择字体之后，然后顺利 demo，丝滑部署，一切看似非常 ok 的情况下，登陆了 Win 试着看下效果，才发现自己忘记了兼容性的问题😱，指定的字体完完全全没有被渲染。尤其在 Edge 下，Sidebar 的字体还因为还原了最初的方案被分段了，orz。

兼容性的问题不仅仅出现在字体方面，在 css 多个选项上也出现了与 Chrome 下的不同效果。好在 css 的问题相对还比较好解决，但如果要实现跨平台跨浏览器的字体统一还是需要走自定义的方式来做，毕竟 hexo 的 external 字体配置虽然可以通过三方字体服务器来做，但在目前默认的 google 库中并没有合适的选择。

17 年一篇，18 年两篇，然后现在是第四篇文章，更新速度堪比富坚义博。

快 3 年了，要不是这个域名，兴许就退了，每年虽然缴的费用不多，但让我一直给供应商白嫖其实也不怎么情愿。正好最近空暇，打理打理这些苟且的栖身之地吧。

这几年发生了一些变化。别的不说，hexo 和 next 理所当然的更新了几个大版本。原先用来编辑的 mbp 也老旧了，闲置在家里。现在操作的 mbp 还是两年派发的，主要还是嫌麻烦的原因，一直没有把 hexo 的编辑目录迁移过来，毕竟只要每次想到要装一堆插件就心生退意。

最近几天，重装了 hexo 和 next 后，升级到了最新版本，同时把展现细节做了更多的改造，说实在的，上次 blog 的搭建，也是弄了很久的源码，发现每逢修改的时候，虽然相隔时间比较长（笑），但总比之前会更加深入一些，这次增加修改了更多的布局，类型以及动态脚本。趁着这几天刚操作过还记得，快点记录下来。

要不是收到关于 <JupyterHub 搭建 > 的咨询邮件，估计要在这个 Blog 再写写画画会是一个未来很久远的事情。

几个月下来，做了不少东西，也进行了很多的尝试，每个点应该都可以 post 一下，不过发现年纪大了，归纳总结的能力也退化了不少，要好好地写一篇路人也能看懂的文似乎也没有以前那么潇洒，虽然自己还是会常常想起几年前一个多月天天就是 PPT 的工作，只为写一个让分析师理解的计算模型出来，但未来，不太可能会发生同样的事情了吧。

言归，正传。今天介绍一下当下一个还算比较稳定的 VPN 的神器，V2Ray。写这种文章实际上有点亏，一来没什么含金量，二来很有可能在不久的未来完全被淘汰的东西。科科。

VPS: Google Cloud Platform(GCP)

我个人早前 VPN 技术还是比较 low 的，从以前的 goagent 到后来的 ss 的鹦鹉学舌，实际上自己对网络都还是一知半解，不够精通。在此说一下，基于 ss 的搭建没有这么难，甚至可以说非常简单，大多数人其实是被云主机这类事给唬住罢了。其实只需要找一个 VPS 供应商，例如 Vultr，申请一个 VS，然后用 python 安装下 ss，配一下 config，service start。除去注册以及等待的时间，也就是 5 分钟的事情。

作为 VPS，GCP 的好处在于，似乎速度还算比较稳定，在日服猖狂的当下，可以支持另外建设湾湾的机房，且目前注册有 300 刀的白嫖。实际上 GCP 上租一个乞丐版的 VPS，一个月大概 3 刀左右，网络传输另算，如果不是大流量的客户端请求，也不会有大多的费用，所以 300 刀基本上也可以维持一个比较长的时间，相对还是比较划算的。

Perface

叨叨几分钟。

写这篇文章，其实仅标题就琢磨了许久，无法找到确切和顺畅的词语来描述这个事情，撇开信达雅，似乎能勉强表述为：一种结合机器学习和数学模型的方法进行平台流程开发优化的例子。然后最终还是选择了现在这个标题，不过有点意思，其中两个 Machine 的意义其实是不同的，后续我们会再展开。

说来这个 case 其实已经存在许久，5 年前还在 O 记的时候，在一次数据开发并行化的任务中发现的方法。起初刚开始采用的方法比较稚嫩，有点惭愧就在此不表，直到后续闲暇下来之后再重新考虑这个问题时候，想到了还在学校惨遭延毕的博士同窗，徐徐聊起来，才发现原来是一个可以结合离散优化和机器学习的典型应用。离开 O 记之后，或多或少有时还是会联想到这个问题，但总会得到一些新的感悟，也有幸有时间进行了更深度的研究和探索。不过最近再看这个问题时，发现当初解决的思路和逻辑有些竟已忘却，就觉得很有必要把这些记录下来，除了对自己，也对这个问题能有个比较好的交代吧。

Parallelism

上面提到的数据开发并行化其实是一个单机程序进行多机并行化的任务，依稀还记得当初接手这个程序的无语，也是第一次接触如此复杂的 Python 程序，正是由于这个经历，后面看到 “怕他” 这样程序并没有受到更多的震撼。这段程序的原始作者是自己的老板和另外一个高高瘦瘦的犹太人，还记得他的名字 Ian langmore，男神，初次见的分离式键盘就是他安利的。他是自己在 O 记这段时间中为数不多合作比较深入的 geeker，记得最后他离开 O 记的时候，farewell 中给每个人留了一句话，也是一个温暖且又细腻的人。

这个程序本身是一个集合了 multinomial logistic regression 以及 markov chain 的 scoring program（也可能是 monte carlo simulation，对 stochastic process 并不熟，忘了是哪个 mc，请原谅这个数学系学渣的笔者😑）。程序中计算部分逻辑复杂晦涩，又是 probabality 又是 matrix，而如果对其进行逻辑的拆分硬套 MR 框架，实现难度不小，且本身程序的效率问题更多是处理量和处理单元数量悬殊的问题，所以解决这个问题的思路还是想通过分而治之的方式进行分流，直观上难度似乎很低：工程师只需要利用 map 和 shuffle 的特性进行任务分发即可完成。

Jupyter 是什么

Jupyter 是一款基于 python 的 web notebook 服务，目前有大多 python 数据挖掘与机器学习爱好者使用这款服务，其特性其实与 Ipytohn Notebook 差不多，准确说 Ipython Notebook 是一款提供增强型交互的功能的 shell，而 Jupyter 除了 Ipython 的功能，还加入了普通编辑器的通用功能，是一款带代码交互的动态文档 web 编辑器。

Jupyterhub

由于 Jupyter 只支持单用户的使用场景，作为一个可交互的 web 服务，只支持单用户模式实在让人难以理解。估计开发者也觉得这个问题太过鸡肋，于是 Jupyterhub 因有而生。

安装

1. 安装依赖包：

   1 2	$ yum install sqlite-devel npm nodejs-legacy zlib-devel openssl-devel $ npm install -g configurable-http-proxy

2. 安装 py3：

   1 2 3 4

   $ wget https://www.python.org/ftp/python/3.6.1/Python-3.6.1.tgz $ tar zxvf Python-3.6.1.tgz $ ./configure --prefix=/usr/local/python36 --enable-loadable-sqlite-extensions $ make -j 20 && make altinstall

3. Reset 环境变量（可选，如果有 py2 环境需要操作）：

   1	$ export PYTHONPATH=''

4. pip 安装 Jupyterhub：

   1	$ pip3.6 install jupyterhub notebook -i https://pypi.douban.com/simple/

启动 Jupyterhub

1

$ export PYTHONPATH='' && ./jupyterhub --ip 0.0.0.0 --port 8888