曾经在迎接 2020 的那个跨年夜里，给自己定下了今年的目标：努力找到一份满意的工作。而找工作确实也成为了我 2020 年的主旋律，从最初不知道自己几斤几两地海投，再到暑期去阿里实习，最后经过几家 Offer 的角逐选择了腾讯。中间确实是经历了不少事情。

非常不错的实习经历

我的实习部门是阿里云的块存储部门，经过 6 轮面试拿到实习机会，再与研究生导师争取，成为了我们导师手下多年以来唯一一个放出去实习的人。4 个月的实习经历算是我第一次走入职场，说实话，体验是相当不错，相当愉快的。

其实从这张不正经的工牌也可以看出，互联网企业的性格就是开放、年轻。面对领导完全没有所谓的压力，非常平易近人，同事都是年轻人，相互讨论的都是有趣的话题，食堂里面遇到陌生人大家也都以 “同学” 相称。给人的感觉就还是在学校，只不过身边的人变成了志同道合的人，手中做的事是更有价值的事。

学生毕业之后的去向很多，除了互联网还有体制内。对于不同的人各有各的好处，而通过这次实习我是深刻的感受到，我太适合于互联网企业这种没有官场文化、靠自己实力驱动的平台了。

互联网公司还有一个热门的话题，那就是加班了。作为“福报厂”，我原本已经做好了 996 的打算，不过进去了之后发现大约是 985 的状态，再加上工作期间也不会安排得特别满，吃完饭也有散步时间和午休时间，所以远比预期的要轻松。不过这也得因人而异，同组的实习生就认为挺累的，这大概和之前的在校经历有关，我研究生实验室的工作强度是比这更强的。

工作方面的感悟

实习期间我共完成了 2 个项目（重设计的事件中心、和基于事件中心的自动告警机器人），与我平时的开发工作差异不大，所以完成的都不错。在这期间还提出了好几个让同事们眼前一亮的 idea，以此在转正答辩中顺利通过，项目细节就不在这展开介绍了。

实习的工作是后端研发岗，其实如果看我的博客或 Github，就能发现我对前端其实是颇为了解的，从传统的 JS 刀耕火种，再到 16 年前后 React 等前端工程化的兴起，再到基于 Node 的后端、中间件这些，我都是一路走过来的。当时也一直认为前端是一个有趣的领域，开发的东西能直观地被用户看到，美观易用的前端更是一种优雅的设计。

之所以找了后端岗位的原因却正是把前端领域了解地差不多了，虽说新的框架、工具库层出不穷，但前端的本质也看得比较透了 —— 按照要求给房子完成装修。资深的前端能熟练的运用现成的工具，更快的完成装修工作。而相比之下，后端负责根据地势设计地基、根据用途设计房屋结构，这会更有难度一些，也就是技术的天花板会更高一些。

实习之后更加确认了这种观点。就算技术不分深浅，那重要程度必定是有差异的。公司里前后端分离，不需要全栈，而一个产品必然是以后端为起点展开的，后端是前端的甲方。再例如我工作时对接的前端能力挺强，但却是公司招的外包，这也能说明一些问题。当然，上述内容只是我个人的见解。

Offer 抉择

除了阿里云的实习转正外，还有美团支付、腾讯文档、字节教育线、华为云，薪资都是 SP 或以上。当然，还有挂了的 pdd（一点也不可惜），以及简历把我拒掉之后还发邮件告诉我简历挂了的滴滴

去年秋招经过一些抉择，最终还是签的阿里云，期间纠结的点无非就是地点、薪资、平台、部门这些。

拿到阿里的 Offer 确实不是一件容易的事，不仅周围人羡慕，我也挺满意的了。不过其实我私底下也明白，对我来说离 “完美的 Offer” 还是有一点点距离的：

主要是工作地点方面，虽说杭州是一个挺不错的城市，但作为一个在西安读书的四川人，我还是更希望去西安或者成都。

如果能在平台部门、薪资等其他方面不比阿里云 Offer 差，同时能得到满意的工作地点与工作岗位，对我来说那就是 “完美的 Offer” 了。抱着这样的期待，参与了春招~

在西安、成都的能与阿里云相提并论的大厂岗位其实屈指可数，抱着随缘的心态，相当幸运地在毕业前的 2 个月拿到了成都腾讯 WXG 企业微信的 Offer。这确实令人满意。✌

近 20 年的学生时代将告一段落，紧接着而来的是几十年的工作生涯。未来我将去向何方，到达怎样的高度，我不清楚。不过对我来说这将是一段全新的旅程，也是我做自己喜欢做的事、将自己能力变现的时刻。我会尽我所能，卷起来。努力干好~

一些经验介绍

最后分享一些找工作过程中的经验，供后面的学弟学妹们参考，应该会对大家有帮助的。

• 所有的招聘流程都要参加。除了秋招之外，那一年的春招、春招提前批都要参加，多参加一次流程就是多一次机会，身边有的同学在纠结暑期实习能不能去，事实上就算不去，拿到实习 Offer 也肯定可以为秋招开绿灯的。再次也可以积累面试经验，所以所有的招聘流程都不要错过。
• 不要局限于一次实习。我只实习了一次，所以也只能初窥门径，缺乏对比。不过暑期实习由于工作比较忙可能会耽误秋招这也是真的。
• 简历。或者说是项目经历一定要丰富地体现在简历中，把简历做得好看很重要。
• 刷题。无数的经验介绍都强调刷题，事实上这确实很重要。再厉害的人与面试官手撕代码那也是必经之路。
• 题库。互联网面试被戏称为八股文面试，确实如此，去找找牛客网上大家整理的操作系统、网络、数据库、数据结构的题库，可以押中 90% 面试时面试官的问题。

祝愿大家也找到满意的工作~

我们曾经以为互联网能够忠诚地记录世间每时每刻发生的信息，并且永久地保存。然而事实上，不仅互联网的记忆比较短，记录在网络服务器上的信息根本不可能永久保存，曾经火爆的网络服务，今天或许就因为服务器关停，所有数据灰飞烟灭。不是危言耸听，百度贴吧、QQ 空间、新浪微博，这些承载了很多人回忆的站点都有可能成为互联网的历史。

就像之前将自己腾讯微博的历史数据归档存储起来，这次我赶在百度空间彻底关站之前，使用爬虫将小时候写的文章给迁移到了本站永久保存。其中最早的一篇博文发布于 2006-12-22，当年我 10 岁，毫无疑问是我在互联网上最早留下的足迹，现在读起来别有一番风味。^O^

目前所有小时候的文章均已转载到本站，来自我的小学和初中的稚嫩文字：https://hzy.pw/p/tag/hibaidu/page/23

---

爬虫的相关技术在这里也没啥特别值得说的，而令人感叹的是 13 年前的互联网，时间似乎不长，变化却极大。那些年写博客便是潮流，淘宝也刚刚进入人们视野。图片都不多的年代，在线视频被认为是奢侈的体验。

互联网的出现让我们的生活变得不一般的多彩，也不知道下一个互联网的 10 年、20 年会造就怎样的景象？我的网站应该会开通到那个时候，而回过头来看现在的这些文字，可能就像是现在回看小学时代那般稚嫩。

但甚是有趣！^O^

耳机毁一生，单反穷三代。我竟然又开始研究 HiFi 了！？

我的第一款 “HiFi” 耳机是高中的时候买的苹果 Earpods，有线的那款。当时见那造型实在新颖，为了外观于是下血本下单了，竟没想到和我之前听过的 20 元天桥耳机有一耳朵差异，同一首歌听到了好多之前没听到的声音 -.- 从此，我的发烧之路就开始了，高中到大学从 20 元烧到了 2000 元。前几年退烧了，半生归来仍是苹果，Airpods 本身声音素质不差，同时真无线用了只能大呼真香，相比 HiFi 高保真，可能便捷才是更重要的，毕竟耳机还是用来听的~

最近又回去研究了一下 HiFi，发现自己读研之后确实变了 -。- 曾经在贴吧微博看的津津有味的测评文，什么结象感、空间感、密度、动态。。。现在看起来拉倒吧，这些名词要有多玄有多玄，没有任何明确的定义。。。

于是我花了一个周补了补声学方面的各种知识，从发声原理到传输协议，收获还是挺大的。为了让大家科学地发烧，远离风电火电的脑残文。这篇文章主要讲讲以下几个方面：（所有内容均非玄学）

1. 什么是频响曲线，什么是目标曲线。
2. 耳机调音非常影响听感，但并非购买时主要考虑的。
3. 因为我们可以通过 EQ 来调整频响曲线。

啥，要我调 EQ？可能很多烧友已经坐不住了，认为 EQ 作曲人和耳机厂商早就为我们调好了，我再调那就是画蛇添足了。我以前也是这么想的，而这种观点可能并不太正确。

---

在声音素质都过关的今天（天桥耳机除外），调音对于一款耳机可以说是最重要的一部分。即在不同频率下的声压级，有的耳机低频突出，有的偏高频，有的则三频均衡，这些文字上的描述其实都可以通过频响曲线衡量。而不同的听者也有不同的喜好。

为什么耳机在不同频率下音量不同呢？主要原因是人耳本身对不同频率的声音敏感度就有不同，参见 ISO226-2003 等响曲线。当然，有少部分人认为频响曲线应当是一条直线，这也就是监听耳机的目标曲线，我不赞同他们的观点，事实也是听感普遍较差。除非你确认音乐制作人也使用的是监听耳机。

目标曲线

所以，怎样的频响曲线才是好听的？正确的？这便可以用目标曲线来衡量。

常见的目标曲线有哈曼曲线、Vsonic、音特美等，其中哈曼曲线用的最多。这是哈曼通过主观测试，得到的所有人都喜欢的平均曲线。但对个人来说，哈曼曲线并不一定是最好听的。更不能说这是“正确的调音”，只能说哈曼作为第三方，所提出的这条调音曲线具有一定的参考意义。

如上图所示，哈曼曲线在不断地更新（低频越来越多了 23333），其中 OE 为头戴式耳机（Over-ear），IE 为入耳式耳机（In-ear）。需要了解的是，作为中频的人声一般在 600-3kHz，某些处理过的女声也能达到 6k，这便是通常说的高频区域。此外，15k 及更高的超高频部分在音乐中几乎没有有效内容，频响曲线中一般不考虑。相关内容参见：常见声音频率范围

• 

• 

传统 HiFi 火拼的战场

我把传统 HiFi 耳机定义为使用 3.5mm 等模拟电路的耳机。而非现在内置 DAC 的耳机，即使用蓝牙或部分 Type-C 以接收数字音频信号的耳机。

如上图所示，传统耳机工作在最后一层，所以需要搭配前端（前三层）或耳放（第三层）食用。而内置 DAC 的耳机直接工作在后三层，不存在推不动、推不好的情况。

很多人说，成本价 300 的传统耳机为啥要卖 2000 呢？有人回答是物料成本确实很低，但因为调音的研发过程费时耗力，定价就高了。

是的没错，传统耳机由于接收到的是模拟信号，需要通过耳机呈现出目标曲线，这里的调音则是声学上的设计与实验：在合适的地方开孔、改变振膜位置、改变耳机线的材质甚至长度。较为复杂，难以轻易得到好音质，而这正是传统 HiFi 火拼的战场。

而内置 DAC 的耳机，则可以通过内置的 DAC，直接将调音后的数字信号输出（可以理解为 EQ），直接得到目标曲线！调音的难度大幅降低，事实上内置 DAC 的耳机确实调音都相当优秀！（包括蓝牙耳机(天桥蓝牙耳机除外)）。这里比较好的例子就是索尼的头戴式耳机 1A 和内置 DAC 的 1ADAC，苹果的有线 Earpods 和蓝牙 Airpods，大家均普遍表明后者要更优秀一耳朵。

这里特别说明一下蓝牙耳机：以前的蓝牙耳机有音质差的刻板印象，原因全在于 SBC 传输协议。关于蓝牙传输协议近期我也研究了不少，在下一篇文章会提到。而对于蓝牙耳机的调音，由于有内置 DAC，能实现更加优秀的声音。

通过 EQ 得到好声音

了解完上面的知识，那么 EQ 作为耳机调音的补偿手段，其意义便不容置疑了。甚至相比于烧友们为了提升低频换海绵套、为了提升高频而换镀银线，调 EQ 是更精准，也是很合理的做法。

有的烧友认为，EQ 作曲人和耳机厂商早就为我们调好了，我再调那就是画蛇添足了。我以前也是这么想的，关于这种观点，我的看法如下：

1. 针对某首歌或某类歌的 EQ 是无意义的。例如流行 EQ、摇滚 EQ 等。

2. 调混响强度更是无意义，例如浴室、演唱会啥的。当然，和上述的 EQ 一样，如果想把听腻的原曲换个曲风听听，那是 ok 的。

3. 针对听者的 EQ 是有意义的。用于满足听者对某个频段声音的偏爱。

4. 针对设备的 EQ 也是有意义的。用于中和某个设备本身的三频不均衡，将其调整至目标曲线。

调 EQ 的方法

具体怎么调，最好的方式当然是听者耳朵收货，手动拨 10 段均衡器啦，但这可能有点难，所以也有更简易的调整方法，以网易云音乐 App 为例：

通过高频和低频两个旋钮，很容易就能找到适合自己的声音。而如果需要提升中频，那么把高频低频都拉低就好了。之后，可以再使用 10 段均衡器进行微调。

同时对于某个听音设备来说，我们也需要调 EQ 以中和耳机本身的三频不均衡：

一般来说，是通过耳机型号 + 频响曲线（或 frequency response）作为关键字，在网上找到音频爱好者们对该耳机的客观测试数据，再与目标曲线对比，得到 EQ 增益。

而现在音乐 App 均推出了 “设备适配” 功能，小米也有米音功能。这其实是将耳机厂商在硬件上没有完美实现的调音，通过软件让手机 DAC 代为完成，非常好！

• 

• 

除此之外，Github 上 jaakkopasanen 的 AutoEq 项目 很棒，他收集了市面上众多耳机的频响曲线，通过 Python 计算了与目标曲线的差异值，并给出了在 10 段均衡器上的参考设置。

拿上面提到的反面教材 Beats urbeats3 为例，在使用了其提供的 EQ 后，频响曲线从黑色线调整到了蓝色线（理论结果）：

• 

• 

这个开源项目另外还能看到各款耳机的频响曲线，还有 Q 值可变的 EQ 设置，都挺有意思的。

总结

这篇文章简述了频响曲线和目标曲线的意义，同时也说明了通过 EQ 来调节频响曲线的意义所在。通过 EQ 我们能得到任何想要的频响曲线。

那么是否可以认为耳机的调音不再需要特别考虑了呢？非也，因为 EQ 调整必然会导致音质的损失，这和用 PS 调整图像曲线有异曲同工之妙：降低亮度不会损失画质，但提升亮度是无法带来更多信息的。

所以，如果能直接买到适合自己调音的耳机，或者使用物理的方式调音（腔体声学设计、耳棉、耳机线等），肯定是优于 EQ 的。但同时我们也需要明白，由于有 EQ 的存在，调音的差异远没有某些水文中说的那么大。那些主观测评硬是可以把 “白开水” 吹成 “三频突出”，把 “人声贴耳” 贬成 “低频下潜不足，高频毫无空间感”

我们得拒绝无脑的耳机主观测评，以科学的方式发烧~

于是对于我们消费者而言，选择一款调音没有大问题的耳机即可，更重要的还是耳机的素质和附加功能。至于 “素质” 到底是什么，经过我这段时间的研究这其实也是可以量化的一批指标的，我将在下一篇文章展开介绍对耳机素质和附加功能的介绍。

Cygwin 是一个 Windows 下的 Linux POSIX 模拟器，通过它我们可以直接运行一个 Linux 终端，非常好用。

网络上关于如何添加一个 “在当前目录打开 Cygwin” 的右键菜单的教程有很多，但是这些方法都有一个问题，那就是不能在中文目录下正常工作，于是研究了一番，修复了这个问题。

探索

既然英文路径可以但中文不行，我最先想到的是使用 Cygwin 自带的 base64 命令，将 encode(path) 后的非中文字符串传给 Cygwin 之后，再 decode 得到包含中文的路径。然而不行，正确的 base64 传递到 Cygwin 之后 decode 却是乱码。

问题的原因很容易想到，那就是编码的问题。经过几次输出中间变量后验证了这个猜想：Windows 采用的是 GB2312 编码，而 Cygwin 采用的是 UTF-8. Windows 将当前路径作为参数传递给 Cygwin 主程序时，Cygwin 不能正确读取路径。

解决

修改 Windows 或者 Cygwin 的默认编码肯定是下下之策。解决该问题最终还是绕不开编码转换。我最终的思路为：

1. 右键点击后，Windows 将当前路径作为参数 1 传递给 run_by_right_click.bat 入口程序
2. run_by_right_click.bat 将路径写入 chere.path 文件（GB2312 编码），并运行 Cygwin
3. Cygwin 运行后，将 chere.path 转换为 UTF-8 编码，读取后 cd

我的 Cygwin 安装目录为 C:\cygwin64，Shell 为 ZSH，如果你使用的是 Bash，有的地方与我的不同。具体步骤如下：

step1. 创建右键按钮

导入注册表文件 cygwin.reg：

Windows Registry Editor Version 5.00
 [HKEY_CLASSES_ROOT\Directory\Background\shell\cygwin64_bash]
 @="打开 Cygwin 终端"
 "icon"="C:\cygwin64\Cygwin.ico"
 [HKEY_CLASSES_ROOT\Directory\Background\shell\cygwin64_bash\command]
 @="C:\cygwin64\run_by_right_click.bat \"%V\""

step2. 编写入口程序

我们的入口程序 C:\cygwin64\run_by_right_click.bat

@echo off
 SET dir=%1
 REM 双引号删除
 SET dir=%dir:"=%

 C:
 chdir C:\cygwin64
 rem del /Q chere.path
 set /p="%dir%">chere.path
 bin\zsh.exe -li

bat 代码是真的难写。。。写这段代码我便踩了无数的坑。

step3. 完成目录跳转

在 Cygwin 内编写 ~/.zshrc，在末尾添加目录跳转命令：

if [ -e /chere.path ];then
     /usr/bin/enca -L zh_CN -x utf-8 /chere.path
     CPWD=/usr/bin/cat /chere.path
     rm /chere.path
     cd /bin/cygpath "$CPWD"
 fi

这里用到了 enca 用于自动编码转换，所以需要在 Cygwin 包管理器中安装这个软件。

over！ 现在便可以在中文文件夹中右键打开 Cygwin 了。

为啥我要用 Cygwin

最后最后。你可能会说，为啥都新世纪了，你还在用 Cygwin 这种… 模拟器？原生 Linux/ 虚拟机 不好用嘛？WSL 不香吗？甚至 Powershell 不也不错？

那我还真觉得 Cygwin 秒杀上述所有的方案。首先，我只是想在 Windows 上安装一个代替 cmd 的 Shell 环境用于日常操作，并不需要高性能什么的，所以原生 Linux 系统、虚拟机、Docker 就不是解决同一个问题的东西。

至于 Powershell，虽说是比 cmd 好多了，但毕竟是另一套语法和体系，我不想学它也对它不感兴趣。Bash+GNU tools 那才是世界通用法则。ZSH 作为日常使用的终端也确实美观好用！

而 WSL 这东西确实很吸引人，性能比 Cygwin 强太多，几乎就是原生系统。然而！WSL 运行于内核态，与 Windows 平级，就算有文件系统的映射，WSL 也并不能直接当作 Windows 的 Shell 来使用的。看下面的图你就知道我在说啥了。

图中，npm 和 git 是我在 Windows 中安装的 exe 包，而 ssh、tail、md5sum 是 Cygwin 中提供的 Linux 命令，直接相互调用无压力，这才是 Windows 中我想要的 Shell 的样子。可是 WSL 是不能这么做的，两个系统是隔开的。

好久不见啦，上一次更新博文还是 18 年底，算起来竟然有足足一年半都没有写东西了。

写博文就是一个习惯，而环境一发生改变，往往就会让人改变一些习惯，同时也会产生一些新的习惯或者是爱好。对我来说，说着也奇怪，自从研究生以来就突然没有写博客的冲动了，当然，这并不是一件坏事，不过是改变了的习惯而已。这一年来我写写论文，做做工程，闲时用 Python 还做了好几个颇为得意的小开发，Github 和豆瓣都有在活跃，只是期间的一些心得体会（屁，其实就是展示成果）没有发布在我的中原驿站~

之前见到的一些特别优秀的博客却没了更新，现在都能理解了，不过如此~

碎碎念结束！而今天，一种巨想写博客的冲动又涌向心头，因为我 以云存储的成本价搭建了一个全功能的私有云：

• 上传下载不限速，数据中心多地任选
• 能实现文件分享功能，同样不限速
• 能自动创建文件历史备份，方便回溯办公文件
• 支持各平台用客户端管理文件，电脑端甚至还可直接将网盘挂载为一个虚拟磁盘
• 价格按用量计费（存储量、下行流量），我一个月大约花费 6 元，属于是云存储的成本价

相比百度网盘等公有云，本方案在实现同等功能的前提下，每月开销更低，并且数据可靠性更高（不会被百度替换成你懂的，同时数据中心用的也是冗余存储，不会丢数据）

为什么我们需要私有云？

首先从为什么我们需要云存储讲起

当人们步入互联网时代以来，便早已不在是 1 人 1PC 了，每个人都有不止一台智能设备（工作电脑、笔记本、手机、平板等等）。可贵的并不是这些设备，而是我们的数据，毕竟在云时代，我们依赖的都是云服务，智能设备只是云服务的展示终端而已。

而这时，各个终端上数据的共享就是一个难题。大概谁都有在自己的电脑和手机之间互传文件的经历，或是将工作台式机中的办公文件复制到笔记本上继续办公（之后可能又需要拷回去）。而如果我们的数据在云端统一存放，那上述的一切问题都将很自然地解决。

你可以在手机上一键将 10 分钟前电脑上编辑完的文档发送给老板，再打开平板，惬意地回顾一下 2 年前的今天用手机拍摄的照片。每个人都有不少的私有数据需要整齐地存储，并且随时方便地查阅，这便是云存储带给我们的好处。

如果网盘提供额外的功能，那再好不过，那便是额外的福利：

如果网盘支持挂载到电脑磁盘，那网盘就像是电脑的一个本地磁盘一般，可以直接双击打开某个文件，修改后保存，或者拖拽复制新文件进去。非常方便。

除了本方案外，据我所知坚果云和 OneDrive 支持这种玩法。

同步盘和挂载盘不同，同步盘支持选择本地一个文件夹，与网盘中的一个文件夹保持双向同步的关系。这要求电脑本地有一份云文件的备份，但有的场景下这比挂载盘更好用。

大部分网盘都有此功能，百度云同步盘功能需要开通会员（使用 bypy 工具可以免会员实现）

文件历史版本功能可以在你的文件修改或删除后，自动创建历史备份，在需要的时候查看，并恢复至任意历史版本。办公神器。

离线下载功能可以让帮你挂机下载文件至网盘。一般情况下，要么秒传下载成功，要么便无法离线下载。

视频在线播放功能可以直接在线播放网盘中的视频文件，配合离线下载还是很方便实用的。

这些功能各大网盘基本都是需要付费才能用的。

云存储解决方案

安利完了云存储的好处，再来说说云存储的实现方法。首先百度云这种公有云就算是免费版，其实对大多数人是够用的，对于我来说，至少需要付费的百度云才能满足需求，但一方面除了不想花那笔钱外，用着也不够满意。

简单罗列一下现有网盘的优缺点：

	优点	缺点
百度云等国内网盘	容量大	害怕丢数据；免费用户限速且功能缺失
OneDrive 等国外网盘	数据安全相对更可靠，功能齐全	容量小，扩容费用很贵；不限速但速度一般
自建 NAS	可满足一切要求	电费设备费花钱也不少；需要公共 IP，否则外网体验很差

上表仅仅是简单罗列优缺点，想表达的意思是，云存储想要在 功能、稳定性、成本 上三者平衡，是一个不可能三角。本文基于对象存储的方案，则是在满足功能和稳定性上，最大地压缩了成本。

对象存储能干啥

所以，啥是对象存储？现在最著名最早的对象存储服务 Amazon S3 已经承载了很多很多全球知名的服务，S3 主要用户是应用程序开发商而非终端用户。网上大多数关于对象存储的用法都是给站长用作静态资源分发，而没有人把它当作云盘使用。

S3 的功能：S3 就是一个无限大的存储桶，通过 API 让用户上传和下载文件。下载文件时也可以无需 API，通过 CDN 以 https 的方式在各类终端中进行读取文件。同时，存储桶内的数据可以进行一些自动化处理，比如图片视频转码，以及我们需要的 自动版本控制 功能。

由于提供了 API 用于上传下载，便有开发者开发出了 S3FS，能将 Amazon S3 作为虚拟磁盘挂载在电脑中。最难能可贵的是，由于 S3 已成为事实标准，各家的对象存储基本都兼容 S3 API，也能使用这一套工具。

价格怎样

价格方面，以七牛对象存储为例（应该是国内最便宜的一家），每月 60GB 存储空间的预估费用为￥4.73， 相比花费￥15 充值百度云会员，仅花这 5 块钱我的使用体验甚至还更好。

各家都提供了三种对象的存储级别：标准存储、低频存储、归档存储。数据的安全性都一样高，但存储空间费用依次递减，数据访问费用依次递增。其中低频存储的建议使用场景即为网盘。

推荐腾讯云 COS

提供对象存储的服务商很多，并且都兼容 S3 API，但我强烈推荐大家使用腾讯云 COS： https://cloud.tencent.com/product/cos

当时我选择时，为了网速快，主要考虑中国境内的提供商，七牛云基本是最便宜的提供商。但如果需要支持 文件版本控制 功能，则仅剩下四家：AWS 国内版、阿里云、华为云、腾讯云。我选择了相对最便宜的腾讯云，后来证明这是个正确的选择。

因为腾讯云除了提供 API 外，还为各平台都提供了对应的客户端（Win、iOS、安卓、Mac），完成度相当可以，非常方便，开箱即用！

购买时可以选择最近的数据中心，我家与腾讯云重庆数据中心直线仅 145.8km，所以选择了他们的重庆机房。图中也可以看到，上传速度为每秒 π MB，下载速度为每秒 10.24MB，还是挺满意的。（这俩数字也是绝了）

基于对象存储的私有云搭建

其实介绍完对象存储是什么之后，如何把他当作私有云来使用，那便是很自然的事情了：使用 API 或者 App，或者网页上传文件，再在合适的时候使用同样的方式下载你需要的文件。

唯一还需要介绍一下的是对存储桶的一些额外配置，以及挂载为本地磁盘的方法。

存储桶配置

腾讯云对象存储默认未开启 文件版本控制 功能，需要我们手动开通。

除此之外，我还按照下图设置了一个简单的文件规则：

挂载为本地磁盘

在 Linux/Mac 上挂载网盘可以使用腾讯云 COSFS 工具，其他家也都会有提供类似的官方工具，或者使用来自 Amazon S3 的 S3FS。

而如果在 Windows 上挂载硬盘，可以使用针对 S3 开发的 Rclone，完美兼容腾讯云 COS，同时该工具还可以将 SFTP、OneDrive、WebDAV 等等各种网盘挂载为本地盘，很厉害。使用该工具前还需要安装 WinFsp。

我的挂载命令为：rclone.exe mount cos:f-1251515384/ O: --vfs-cache-mode full --attr-timeout 1m，即可将网盘挂载为本地的 O 盘：

然后有一个很关键的设置如图，如果不这么设置，在图片多的文件夹内 Windows 会自动加载缩略图，在音乐多的文件夹内，会自动读取音乐的 meta 标签，瞬间耗费很多网盘流量，还会造成电脑卡顿。

关于进程保活

Rclone 在前台终端运行之后，我们需要保活，以及在重启之后自动运行。

NSSM 可以便捷地创建一个 Windows 服务，保证该进程在后台运行。不过我用的是 PM2，PM2 在 Windows 上运行会有一些坑，这里就不展开叙述了。

总结

介绍了云存储对普通人的意义，然后提出了使用对象存储这个廉价、简单，且扩展性优秀的私人云方案。可能对于极客而言，这将是自己搭建 NAS 之外的另一条可选的道路。

2 个月后的补充

我的存储量为 22GB，正常使用 2 个月后总开销 7.52 元，确实便宜。速度和稳定性也很满意。

但是，用于 Windows 上挂载网盘的工具 RClone 却是一个大坑：

1. 文件名中不支持 ‘：’ 等几个特定的中文字符。
2. 挂载盘中使用 Office 系列软件会发生异常，保存时必定会丢文件。用 Chrome 直接下载文件到挂载盘时，也丢失过文件。

问题 1 不算严重，重命名就可以了。而问题 2 令人难受，初步判断是 Office 本身的不兼容导致。但是我发现，使用 webdav 方式挂载的网盘并不存在此问题。

于是，我使用了 Python 包 mar10/wsgidav 将本地挂载好的 Rclone 挂载盘转换为 webdav 协议，监听在 localhost:8080。再使用 Windows 连接本地的 webdav 服务器（这里需要修改一下注册表，否则只支持 HTTPS），wsgidav 号称专门优化并支持了 Office 在线编辑，事实确实如此，Office 工作正常了。

多套了一层协议转换，可能不太优雅。 这里分享一下我最近发现的一个好项目：Cloudreve（ 支持多家云存储的云盘系统 ），可以将对象存储作为存储源，提供 Web 访问界面和 WebDaV 接口。并且由 go 语言开发，运行在服务器上既是自己的私有云，运行在本地即充当 S3->webdav 的客户端（代替上面的 rclone+wsgidav 方案），甚至还可以运行在 Android 手机上。

评论区有人留言 rclone serve webdav 可以直接挂载为 webdav，然后再在文件管理器中直接添加该 webdav 服务地址即可，完美解决该问题。

来自 119 寝室的理财 PK 赛：胡中元 vs 景誉文。(随时欢迎更多参与者) 允许使用各种正当的理财手段，PK 结束时赚取金额最多者获胜。

比赛期限：即日起至 2019-2-1
选手启动资金：￥2000（也可以以更低资金参与，翻倍计算即可）
胜负定义：比赛结束时，所有参赛选手按持有资金排名，前 50%（向上取整）定义为胜者，其余为负者。

失败者惩罚：
每位失败者需要无条件执行来自胜者的共计两个请求。为防止胜者提出过分的请求，每位失败者随后也可以要求胜者执行一次同等难度的请求。

比赛要求：

1. 不得使用各种收益率离谱的 P2P 理财平台。仅限使用支付宝、微信和银行。
2. 每次资金变动需要在当日写入本页评论，作为记录。除资金变动信息外，还要附带写上当前你持有的总金额。

热烈欢迎其他同学中途参与比赛，12 月 15 日之前，随时可以以启动资金参与到这场比赛之中。

本科毕业外加考上了西电研究生，作为蓄谋已久的毕业旅行，在这个八月风风火火地带着爸妈前往巴厘岛，开始了为期 7 天的跨国度假。如此美妙的经历自然是要记录一番啦。

之前一直觉得录视频是一件意义不大的事情，因为回看的概率并不高于照片，还特别占空间。直到这次用上了 GoPro，才彻底颠覆了以往的观点。用视频记录下来的美妙瞬间简直太畅快啦！

3 分钟记录我的巴厘岛之旅，强烈推荐大家播放一看 

优酷：https://v.youku.com/v_show/id_XMzc4NjM0NDM3Mg==.html

国外微软的 Azure、亚马逊的 AWS 和谷歌的 GCP 三大云平台提供商之间的战争就如同腾讯云与阿里云，之间的战争硝烟弥漫，而受益最大的则是我们消费者，AWS 提供免费试用 12 个月，GCP 直接给新用户 $200 的余额随便用，而 Azure 则是两者之和，提供了免费试用 12 月外加信用额度 $200，都相当的壕气（均需要国际信用卡）

Azure 的免费政策：https://azure.microsoft.com/zh-cn/free/
正好我有一张 visa 卡，就申请了他们家的免费试用，下面是评测报告。

价格：免费
机型：B1S（1CPU + 1G RAM）
机房位置：香港（东亚机房）
虚拟：Hyper-V

查看更多主机跑分测评来进行横向对比，请点击：https://hzy.pw/p/tag/vps-test

测试结果仅能代表当时的服务器水平，受网络、机房的影响可能会与实际情况有差别。

综合评测

----------------------------------------------------------------------
 CPU Model            : Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
 CPU Cores            : 1 Cores @ 2394.403 MHz x86_64
 CPU Cache            : 30720 KB
 OS                   : Debian GNU/Linux 9 (64 Bit) Hyper-V
 Kernel               : 4.9.0-6-amd64
 Total Space          : 66.9 GB (3.0 GB Used)
 Total RAM            : 913 MB (228 MB Used 544 MB Buff)
 Total SWAP           : 0 MB (0 MB Used)
 Uptime               : 0 days 18 hour 43 min
 Load average         : 0.06, 1.59, 1.48
 ASN & ISP            : AS8075, Microsoft Corp
 Organization         : Microsoft Azure
 Location             : Hong Kong, China / HK
 Region               : Hong Kong
----------------------------------------------------------------------
 I/O Speed( 1.0GB )   : 11.4 MB/s
 I/O Speed( 1.0GB )   : 11.4 MB/s
 I/O Speed( 1.0GB )   : 11.4 MB/s
 Average I/O Speed    : 11.4 MB/s
----------------------------------------------------------------------
 Node Name        Upload Speed      Download Speed      Latency
 Speedtest.net    0.00 Mbit/s       11.96 Mbit/s        39.799 ms
 Fast.com         0.00 Mbit/s       149.7 Mbit/s        0.000 ms
 Shanghai  CT     224.96 Mbit/s     133.47 Mbit/s       134.445 ms
 Hangzhou  CT     282.51 Mbit/s     366.95 Mbit/s       350.036 ms
 Chengdu   CT     297.80 Mbit/s     261.22 Mbit/s       46.351 ms
 Shanghai  CU     205.90 Mbit/s     491.24 Mbit/s       74.781 ms
 Xi'an     CU     241.29 Mbit/s     354.87 Mbit/s       54.176 ms
 Chongqing CU     204.42 Mbit/s     146.99 Mbit/s       303.21 ms
 Xi'an     CM     362.86 Mbit/s     466.86 Mbit/s       429.041 ms
 Kunming   CM     61.42 Mbit/s      118.98 Mbit/s       182.589 ms
 Guangzhou CM     10.72 Mbit/s      26.50 Mbit/s        816.646 ms
----------------------------------------------------------------------
 Finished in  : 8 min 9 sec
 Timestamp    : 2018-08-01 12:39:54 GMT+8

或许你注意到了 11.4 MB/s 的极低 IO 速度，这大概是其他 KVM、OpenVZ 主机的 1/30 ~ 1/10，真的很糟糕。

我使用了免费计划中赠送的 64G SSD 并挂载到 /，如果使用 VM 自带的 4G 存储，则速度有 31MB/S，但是仍然很慢。

网速属于第一梯队水平，无可挑剔。

硬件跑分

Dhrystone 2 using register variables       29081926.5 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     3860.5 MWIPS (9.8 s, 7 samples)
Execl Throughput                               4012.2 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        727708.6 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          190667.9 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       2270825.6 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1089342.0 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 138476.7 lps   (10.0 s, 7 samples)
Process Creation                               9571.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   6999.9 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    912.0 lpm   (60.0 s, 2 samples)
System Call Overhead                         746993.4 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   29081926.5   2492.0
Double-Precision Whetstone                       55.0       3860.5    701.9
Execl Throughput                                 43.0       4012.2    933.1
File Copy 1024 bufsize 2000 maxblocks          3960.0     727708.6   1837.6
File Copy 256 bufsize 500 maxblocks            1655.0     190667.9   1152.1
File Copy 4096 bufsize 8000 maxblocks          5800.0    2270825.6   3915.2
Pipe Throughput                               12440.0    1089342.0    875.7
Pipe-based Context Switching                   4000.0     138476.7    346.2
Process Creation                                126.0       9571.9    759.7
Shell Scripts (1 concurrent)                     42.4       6999.9   1650.9
Shell Scripts (8 concurrent)                      6.0        912.0   1520.0
System Call Overhead                          15000.0     746993.4    498.0
                                                                   ========
System Benchmarks Index Score                                        1119.9

性能属于中等水平。

结论

Azure、AWS、GCP 作为世界最大的云平台提供商，功能非常全面，但同时收费也相当复杂，不要设想一价全包。举个例子，除存储空间外，IO 请求是按次数收费的，IP 地址的占用是按时间收费的，另外每个月宽带有 20GB 上限，超过就需要额外付费等等。这些额外款项都有包括在免费计划中，但要有每个月超限一点点的心理准备。

如上面的评测结果可见，IO 性能极差，已经是因为 IO 严重影响整机服务水平了。另外免费计划赠送的数据库只能使用 SQL Server， 综上，我认为这台免费主机不适合用作建站。

但如果用作梯子，那则是极好的，因为香港机房网速非常给力，而且还是免费 12 个月，过期后再在 AWS、GCP 各来一年，还要啥飞机场~~

流量每个月免费 20G，我实测一个月使用了 17G，超限价格也还好，所以单人使用是足够的。

>> 更多更新关于网络的测试见下一页

为了防止腾讯微博某一天被腾讯关停，使我初中时发的上千条微博灰飞烟灭。遂使用 Python 爬虫外加 React 搭建了一个微博复刻小站，将我的回忆放心地永远留在了自己的服务器中。相关技术介绍： https://hzy.pw/p/2554

在这上千条微博存入数据库之后，我便开始对其进行大数据分析了，包括我最喜欢转发谁的微博、我在星期几最喜欢发微博，以及微博当中包含最多的关键词等等。很是有趣。

我的微博复刻网站欢迎访问： https://hzy.pw/i/qqweibo/

相关技术介绍： https://hzy.pw/p/2554

下面是对我的腾讯微博的大数据统计。

 

我一共发布了 1620 篇微博，其中转发和原创的比例如图。可以看出，初中时候的我可以说是很认真地在更新自己的微博（就像现在认真的写这个博客一样 :P），没有灌水。

 

将所有微博正文提取、分词处理后，使用 NLP 中关键词提取的相关算法，得到了我微博中最常见的 30 个关键字，按照面积比例做成了这幅统计图。

可以看到那时的我完完全全就痴迷于 iOS，从越狱到汉化 App 到开发小程序。不得不承认乔布斯时代的苹果真的是秒杀竞争对手的存在，有着极大的魅力，不过我现在更喜欢安卓就是啦~ 

这时我顺便还进行了所有微博正文的情感分析，后来发现意义不大，模型输出结果显示积极情感  >99.999%（如果是对单条微博进行情感分析，则输出正常，但我懒得去处理和统计了）

 

我从 PC 网页端发布的微博占接近 40%，实际上在 2011 年前后，使用手机发微博真的是一件值得炫耀的厉害事情，但如今正好相反，手机发微博才是理所当然的主流。互联网的发展令人感叹。

 

很有趣的微博附图统计。在当时很长一段时间，微博只允许上传一张图。至于 “无图”，在微博最开始时还真是大家的选择，以现在移动互联网的思维来思考是难以理解的。

 

发了两百多条微博那个月我也是够闲。。。PS：我离开腾讯微博，来到新浪微博的时间是 2012 年 12 月。

 

将数据结构化地存在数据库中就是方便，大多数数据都是一条 SQL 搞定，于是随手统计了一下每周和每日的发微博时间分布。

能得出来的结论就是：我是一名周内认真学习，每天按时睡觉的好孩纸。

 

我转发微博真的挺少，而且转的最多的还是我自己的微博，因为我最喜欢的就是我自己。

 

最后一张是我的的微博的热度统计，热度定义为评论和转发的总数。不过我一直不太在意就是了。各条微博按照时间升序在横轴上排列。

 

结语

腾讯微博对我来就像自己的日记本一般，有着特别的意义，但是目前已经淡出舞台。

欢迎大家关注来我的个人网站、新浪微博，以及 Github 和知乎：https://hzy.pw/connect

大概是微博这个东西刚刚流行起来之时，也就是我初中的时候，我便用心的经营着我的腾讯微博，倒不是想要成为微博大咖，只是认为在同龄人坐在电脑前都只会打游戏时，我刷刷微博、发表一下自己的看法和见解，是更有意思的一件事。

然而腾讯微博迅速就被新浪微博超越，市场占有率几乎为 0 了。我自然也投靠了人多势众的新浪微博，但之前在腾讯微博中发的超过 1000 条微博是我的回忆 —— 中二青春。

我有一种预感，过不了多久腾讯微博就要被腾讯关停了，我可不能让之前写的那些碎碎念就这么消失，于是我用 Python 写了一个爬虫，将所有 [微博+图片+时间+转发微博+转发微博的所有信息] 都给爬到了本地数据库中，然后使用 React 做成了一个网站，名曰“复刻版腾讯微博”，将我发的微博放心地永远留在了自己的服务器中。

查看我的腾讯微博复刻网站，请点击：

https://hzy.pw/i/qqweibo/

## 基于服务器心情而工作的爬虫

截至目前，我的腾讯微博上共 1661 条微博，收听 65 人，听众 765 人。然而爬虫运行完毕之后获取到的微博数量为 1620，另外 41 条数据不翼而飞。我发布的微博和转发的微博中共包含了 1220 张图片，其中 6 张已被他们服务器丢失。微博中共包含 98 个视频，其中的 88 个均丢失（这是视频网站的锅，我们上传到优酷上的视频真的会被他们永远存放着吗，想想也是不可能的）。

微博中还包括了 785 条诸如 http://url.cn/482SZS 这样的短链接，其中 90% 均已失效，访问时直接提示 您访问的网址有误或该网址已过期 :( 此外，虽然 2011 年的微博也还给我留着，但所有微博的评论均没有了，数据被删掉了。。。

我想说的是，要是再不使用爬虫将这些宝贵的回忆取回，真说不定哪天就被腾讯给删掉了 ToT

讲真，各种复杂的情况都被我遇到了： 微博不提供 API，使用 Python 爬取 HTML 再解析，关键是 HTML 结构每次都会变，我花了很久很久的时间才适配了所有情况。另外服务器返回的数据并不可信，第一次得到的数据显示我在某一天发了 1 条微博，带有图片，再获取一次变成了发了 4 条，却无任何图片上传。（这不是腾讯为了防爬虫设计出来的，因为浏览器访问也是这样的，大概是腾讯微博在临死前，为了降低服务器负载而采用的拒绝式服务。。。）

于是我的爬虫在经过数天的完善后，拥有了应对前后数据不一致、连接握手失败、适应 HTTP 结构变化的功能。在此基础上又运行了四五天，才完成了爬取。因为对我那 1000 条微博的每一躺爬取，结果都是不一致的，直到最后连续运行十个小时也没爬出新数据后，我才认为是爬完了。

最终顺利爬取了能找到的所有数据，并存在了数据库里，真的是超级辛苦，让我激动的发了个微博（新浪微博~~）

数据清洗

数据清洗除了格式上的规范，还标记了一些重复的微博，这些微博在我的博客、空间里面重复，我的微博镜像站中没有必要包含这一部分内容。

此外为了制作微博镜像站，使用 Pillow 库将图片原图批量压缩成了 webp 格式的缩略图，在我的微博镜像站中，点击缩略图即可查看大图。 然而事实证明选择 webp 格式是错误的 ，虽然谷歌的 webp 格式拥有很高的压缩率，但是兼容性是个问题，不支持 Firefox、IE 和 iOS，几乎是只有 Chrome 能显示，所谓的 WebP JS 兼容性修复库其实是使用了 Flash 实现，然而后者本身就不值得使用。 所以说 WebP 格式的图片只适合客户端而不适合浏览器端。

最终我还是选择了 jpg 格式作为缩略图。毕竟我的服务器拥有 自动转换为 WebP 功能。

愉悦的 React 开发体验

感谢 facebook/create-react-app 提供的脚手架，webpack+eslint+react 开发环境开箱即用。另外不得不感叹 React 的模块化使得逻辑相当清晰，很方便省心。

另外还要感谢 clean-blog CSS 主题 和 lightgallery.js 图片灯箱插件

接下来

如果 QQ 空间、朋友圈、微博、豆瓣 这些网站在某一天宣布关停，我也会把自己的数据通通扒回本地，当我真心不希望这样，因为这个网站本身，就是一代回忆。

有空的话还要干几件事：试着统计下我发的微博中的一些有趣的数据，比如口头禅、文字情感之类的。再来就是把微博中的短链接替换成为长链接，因为正如上文提到的那样，很多短链接都在陆续失效了。

就酱。

现已完成，对我的腾讯微博的大数据统计挺有意思，请访问： https://hzy.pw/p/2569

对于电脑硬盘，固态肯定是全方面优于机械硬盘的选择，不过按照马克思主义矛盾论的观点，这就存在一个 “低速的 HDD 与高价的 SSD” 之间的矛盾。目前我的笔记本使用 128G+1T 的组合，处于并将长期处于 “个人电脑硬盘的基本矛盾” 之中。

直到，我遇到了 PrimoCache 这款软件。推荐给大家。

PrimoCache 是一款可以将物理内存、SSD 硬盘或闪存盘等虚拟成硬盘缓存的软件。它可以自动将硬盘中读取的数据存入物理内存等速度较快的设备，当系统再次需要该数据时它可以很快从缓存设备中读取，而无需再次访问速度较慢的硬盘，从而有效提升物理硬盘的访问性能。

中文官网：http://www.romexsoftware.com/zh-cn/primo-cache/index.html
平台：Windows（其实 *nix 下也有类似的）
软件类型：共享软件

两个月后更新：

经过 2 个月的实际体验，这款软件并没有宣传的那么完美。少数软件一运行就会完全死机（跑跑卡丁车，并确定是由该软件造成的），整个系统也似乎有一种不稳定的感觉（偶尔弹出一些意义不明的错误提示）。另外还有额外的内存占用。

总之，不推荐将系统盘加速，也不推荐大多数情况下的使用。除非你有一些常玩的游戏，但由于几十 GB 的体积巨大不能放入 SSD，才值得使用此软件。

缓存技术

这种理念我认为非常好，Cache 技术也是计算机硬件软件当中一个使用非常广泛的技术。这和最初的英特尔快速存储技术（RST）以及英特尔傲腾技术类似。都是使用少量高速的 SSD 作为缓存，为低速的 HDD 加速， 使得电脑拥有 HDD 的大容量的同时，拥有接近于 SSD 的速度。

至于什么数据会被缓存到 SDD 中？这是由算法控制的，自动选择 HDD 中最常用的那些数据。

PrimoCache 与 RST 或者傲腾的区别在于，这款软件不需要你使用最新的 Intel 主板，或者是购买 Intel 家的傲腾内存，它兼容一切现有的 SSD。

PrimoCache 还支持使用内存作为一级缓存，SSD 作为二级缓存

是的，这也是 PrimoCache 的一个特有的功能，内存的每秒读写速度单位在 GB 级别，比 SSD 高了一个量级，能有效为 SSD 加速。（不过我还没有直观感受到差异，大概在这时瓶颈已经不在 IO 了）

效果展示

我现在终于可以把动辄几十 G 的游戏放心的放在机械硬盘了，然后使用 PrimoCache 让他们拥有令人满意的读取速度。

我使用了 12G SSD 作为二级缓存，1G RAM 作为一级缓存，运行测速工具对机械硬盘测速结果如下：

未使用缓存：

使用缓存：

注意，由于缓存的原理是将常用数据放在 SSD、RAM 中，需要时快速获取，所以使用测试软件随机读取或写入时并没有预存这个过程，并不能反映实际效果。
但是我们也可以看到明显的进步了。

注意事项

发现的缺点：

• 使用二级缓存 SSD 时，需要占用一定量的内存用于存储映射。
• 这是一个收费软件，虽然有破解版。
• 之前出现了一次显卡被降频，关闭该软件后恢复。但后来开启该软件又没有出现类似状态。

此外，虽然我的 RAM 有 16GB，但我也只使用了不到 2GB 作为硬盘缓存，因为我觉得目前大多数大型软件都会使用 RAM 为自己加速，我们没必要多此一举。并且充裕的 RAM 本身也是提升电脑响应速度的途径。

Node 与 Python，都是脚本语言，有着类似的使用场景，所以在各个地方早已经互相 pk、比较过无数回了。虽然我知道编程语言之间的 VS 是一个很 low 的行为，因为他们必定是各有优势的。但今天我还是特别的想说说自己的心得体会。

Node 是我曾经特别喜欢，也是非常熟练的编程语言。Python 我还处于学习阶段，不敢说深入了解。

使用场景

如果要评论手机 App 开发，自然是有着一堆框架的 Node 胜出，而如果站在科学计算领域，那胜利者绝对是 Python。所以本文主要还是对简单的日常场景进行对比 ———— 代替 Shell 的那些操作、作为服务器中间件与数据库打交道等等。

Python 脚本

前几个周我写了数个 Python 脚本，这便是其中一个。将 NAS 中我收集的漂亮壁纸的分辨率、时间信息记录到 SQLite 数据库中，再定时从数据库中随机取出近期未使用过的壁纸，让桌面壁纸换一换。

Python 对于这种事情确实在行。另外我根据爬虫创建的翻墙规则 Shadowrocket-ADBlock-Rules 也是使用 Python 生成的，5 线程爬虫协同工作，代码清晰简洁。

Node 脚本

Node 上面提到的那些，相对而言更适合较大的项目。比如我开发的 XSYU-GMS 教务系统，就是一个前后端全栈 Javascript 项目。

对于 web 中间件，例如监听 443 端口提供数据相关的 API 调用服务。Node 原生可作为一个守护进程保持运行，灵活维护一些常量（Python 也是这样，只是感觉工作量会更大一点），作为脚本语言的高维护性体现出来，并且 Node “以事务驱动单进程” 的特性在极限情况下可以实现超高的性能。

Node 成败均在回调

继续上文。虽说 Node “以事务驱动单进程” 的特性在极限情况下可以实现超高的性能。但是对于大多数情况下，Python 也是可以撑住的。低负载的情况下，Node 引以为傲的 “事务驱动” 就变成了可怕的 “回调地狱”，在性能提升不大的情况下，严重影响了开发效率，甚至是提高了程序复杂度所导致的出错率。

我曾经在用 Node 开发 RSS 爬虫时，认真思考每一步之间的相互依赖关系，哪些可以并行，哪些必须等待。然后精确地实现，代码看起来非常复杂。实际上的效率提升其实真不是很重要，全部都用串行实现，岂不一样可以达到目的。

毕竟，要最追求效率那我应该选择 C 甚至是汇编，既然选择了 Node 这样的脚本语言，那就是为了开发方便。 实际上，计算机编程语言的发展，就是在不断地用运行效率换取开发效率。当然，不会因为开发效率彻底代替运行效率。

Promise 与 Async Function

这大概就是拯救 Node 回调地狱的存在吧，确实，程序写起来体验好太多了。但是…… 这又导致了 await 地狱…… >o<

下面是我今天的代码，功能从数据库中获取部分 Email 地址，给他们发送邮件。

(async function() {
    let maxTimeStr = new Date().toUTCString();

    ret = await sqlP(`select username from user WHERE 
        d=0 AND status=1 AND created_at line.username);


    for(addr of emailList) {
        try {
            await sendMailForTK(addr);
        }
        catch(e) {
            console.log('sendMail failed', addr, e);
            await sleep(61);
            contine;
        }

        // send Done
        sqlP('update user SET d=88 WHERE username="' + addr + '"');

        await sleep(6);
    }

    process.exit();
})();

/**
三步串行操作：
1. 从数据库取得邮箱地址
2. 发送邮件
3，将记录写回数据库
*/

代码中的 sqlP(), sleep(), sendMailForTK()，都是我自己封装的 Promise Object，虽然封装不是个麻烦事，但我有一种感觉 —— 以后几乎所有的 Node 开发，都要经历这一步了。同时必须要经过的一步那就是在调用的时候用上 await，这就是 await 地狱。

于是问题来了，既然我们 80% 需要的程序逻辑都是串行，那么把这 80% 的代码特殊处理还真是一键麻烦的没必要的事情。像 Python 那样默认为串行，在 20% 的时候再使用多线程，在我看来是一种更合适、更通用的模式。

事件驱动是 JS 的核心，所以 Node 自然以后也只能保持这种模式了。

对 Node 的总结

我认为，Node 的最佳使用场景仅限于需要其特点：”异步回调” 的时候，可以带来高性能。而其他时候，这只会带来麻烦。

当然，Node 超级给力的模块机制，以及与简单易学的 JS 搭配实现的 web 开发语言前后端同一等等，使得 JS 永远充满魅力。

Python 的缺点

就并行串行而言，Python 我更偏好，但是这门语言我还是有一些需要吐槽的地方。

1. 编程风格

对于初学的我来说，完全不能赞同 Python 那些语法就是 “优雅的编程”，而 C 风格的大括号、分号就有多难看。在 class 里面，最多只能一个空行，而不能 2 个。使用 Python 编程让我有种被限制的感觉（也许还是因为我不熟悉吧）

总之我认为 “非 C 风格编程” 是一个缺点。

2. 相比 Node 包管理机制更弱

这不是 Python 太差，而是 Node 太叼了。Node 只提供底层 API，提倡使用第三方包完成你的工作（这也是导致 JS 项目层出不穷的原因），而 Python 并没有这种提倡。

这个假期，我做的最有趣的一件事就是将路由器改造成了一台稳定的 NAS，其中由 Aria2 实现的离线下载服务器是作为 NAS 的一个核心功能。用着非常方便，然而却有以下几个问题：

1. 重启机器后，Aria2 在重启后并不会自动继续之前的下载。虽然保存了 sessions，但 Aria2 重启之后会自动将所有任务暂停。这就没法实现挂机下载了。
2. 删除 Aria2 建立的下载任务后，并不会删除硬盘中对应的文件（包括只下载到一半的破损文件），这很不方便。

---

重要补充说明

我的代码依赖于 Aria2 编译时的 XML 库依赖，而在某些版本中是不带这个依赖的。所以本篇文章不一定适用于所有情况。

为了解决这 2 个问题，我编写了一个 Python 脚本，完美地解决了困扰。

脚本在 Python3 下运行正常，未对 Python2 测试。不依赖第三方模块。
为了实现 “让暂停的任务继续下载”，需要按照 Aria2 文档来调用 RPC，所以 需要在代码内修改相关的连接地址、密码等信息。

脚本同时会自动读取任务列表，并在下载目录找到所有不属于任务列表中的文件，删除之。
你也可以在 fileWhiteList 变量中设置不想要删除的文件的白名单。

#!/usr/bin/python
# -*- coding: UTF-8 -*-

# 1. start all paused tasks
# 2. delete other files on disk

# API: https://aria2.github.io/manual/en/html/aria2c.html#rpc-interface

from xmlrpc import client as xmlc
import os

rpcUrl = 'http://127.0.0.1:6800/rpc'
rpcToken = 'token:PASSWORD'
downloadPath = '/root/usb/nas/download/'  # same to aria2 config
fileWhiteList = ['/bypy', '/PROTECTED']   # while list for delete


s = xmlc.ServerProxy(rpcUrl)
api = s.aria2
# start all tasks
api.unpauseAll(rpcToken)


tasks = api.tellActive(rpcToken)
tasks += api.tellStopped(rpcToken, 0, 99)
tasks += api.tellWaiting(rpcToken, 0, 99)

for task in tasks:
    # started BT tasks
    if ('bittorrent' in task) and ('info' in task['bittorrent']):
        filename = task['bittorrent']['info']['name']
        fileWhiteList.append(filename)
    # other tasks
    else:
        for file in task['files']:
            path = file['path']
            if path.startswith('[METADATA]'):
                path = path.replace('[METADATA]', '')
            else:
                path = os.path.basename(path)

            fileWhiteList.append(path)

# del same items
fileWhiteList = set(fileWhiteList)

print('fileWhiteList', fileWhiteList)


def isStrContainItemInList(str, list):
    for item in list:
        if item in str:
            return True
    return False


for parent, dirnames, filenames in os.walk(downloadPath, topdown=False):
    for filename in filenames:
        path = os.path.join(parent, filename)
        if not isStrContainItemInList(path, fileWhiteList):
            os.remove(path)
            print('del file: ', filename)
    for dirname in dirnames:
        path = os.path.join(parent, dirname)
        if not isStrContainItemInList(path, fileWhiteList):
            try:
                os.rmdir(path)
                print('del dir:  ', dirname)
            finally:
                pass

一般来说，我们需要这段脚本在开机后自动运行，加入至 /etc/rc.local 即可：

sleep 1m && python /root/aria2/afterRun.py > /var/log/aria2.afterRun.log &

相关推荐

Aria2 bt-tracker 跟踪服务器列表自动更新：https://www.feng.ee/aria2-trackers-auto-update.html

我这基于 OpenWrt 的路由器可以说是超级强大，不仅仅是一个无线路由器，插上 U 盘可以变身为 NAS+下载机，可以运行 Python 小程序，甚至还有人在上面搭建 LNMP 运行 Owncloud。可以说是一台 VPS 可以干的事情我都可以在宿舍的路由器上实现，十分强大。

然而最近才了解到，这颗 580MHz 的 MTK7260A 仅仅是一颗智能路由器当中处于中低端的 CPU，说实话我是不信的，于是打算用 UnixBench 来客观测试一下这个小家伙的真实水平。

UnixBench 是基于 Perl 并拥有 30 年历史的基准测试软件，也就是跑分软件。通过运行一系列科学计算函数测试 CPU 性能，以及 OS 的任务执行效率、硬盘性能等。最终得到一个分数。

测试平台

路由器：Newifi Mini
OS：LEDE 17.01.2（一个 OpenWrt 的著名分支）
Linux Kernel：4.4.71
架构：MIPS
RAM：128M
ROM：16M

系统基本为纯净的 LEDE，除了正在运行着路由器的基本网络服务外，跑分时运行了一个 PPTP VPN Client 服务。

交叉编译及运行步骤

OpenWrt 的 libgcc 套件体积 22M 的样子，但正如上面所写，我的路由器 ROM 总共只有 16M，挂载分区什么的不是很有必要，于是我使用交叉编译 UnixBench。

简单介绍一下交叉编译的步骤吧：

1、找一台 x64 的 Linux 机器，按照 <https://wiki.openwrt.org/doc/devel/crosscompile> 步骤开始接下来的操作。必须得要 x64 的主机。

2、下载你的路由器当前系统当前机型对应的 DevPack，比如我的 LEDE 在这里下载的：<http://downloads.lede-project.org/releases/17.01.2/targets/ramips/mt7620/lede-sdk-17.01.2-ramips-mt7620_gcc-5.4.0_musl-1.1.16.Linux-x86_64.tar.xz>，OpenWrt 请在 <https://downloads.openwrt.org/> 下寻找。

3、按照官方 Wiki 的步骤将编译器添加到环境变量。

4、下载 UnixBench 的源代码并解压：<https://github.com/kdlucas/byte-unixbench>

5、开始编译。这里注意官方 Wiki 有误，请使用 make CC=mipsel-openwrt-linux-musl-gcc LD=mipsel-openwrt-linux-musl-ld 命令使用指定编译器进行编译。

6、编译失败？根据提示删除 Makefile 中编译器无法识别的两个参数，即可完成编译。

7、将除了 /src 外的文件 scp 到路由器。

8、安装相关依赖：opkg install perlbase-posix perl perlbase-time perlbase-io perlbase-findbin coreutils-od，跑分完后即可删除。

9、尝试运行 ./Run，你会发现弹出错误，根据错误内容做出以下修改。

10、修改 ./Run，注释掉 use strict 和两处尝试执行 make all 的语句。

11、这时再运行 ./Run，就已经自动开始跑分了。虽然会有几个 Wrong 弹出，但是不要紧。

基准测试结果

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: : GNU/Linux
   OS: GNU/Linux -- 4.4.71 -- #0 Wed Jun 7 19:24:41 2017
   Machine: mips (unknown)
   Language:  (charmap=, collate=)
   17:01:34 up 13:01,  load average: 0.25, 0.49, 0.34; runlevel

------------------------------------------------------------------------
Benchmark Run: Sun Sep 24 2017 17:01:34 - 17:37:25
0 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        1261494.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                       24.3 MWIPS (9.9 s, 7 samples)
Execl Throughput                                452.5 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks            41.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks              18.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks           115.4 KBps  (30.0 s, 2 samples)
Pipe Throughput                              154847.5 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  51157.7 lps   (10.0 s, 7 samples)
Process Creation                               1260.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                     43.2 lpm   (61.1 s, 2 samples)
Shell Scripts (8 concurrent)                      6.5 lpm   (64.3 s, 2 samples)
System Call Overhead                         308931.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    1261494.8    108.1
Double-Precision Whetstone                       55.0         24.3      4.4
Execl Throughput                                 43.0        452.5    105.2
File Copy 1024 bufsize 2000 maxblocks          3960.0         41.0      0.1
File Copy 256 bufsize 500 maxblocks            1655.0         18.5      0.1
File Copy 4096 bufsize 8000 maxblocks          5800.0        115.4      0.2
Pipe Throughput                               12440.0     154847.5    124.5
Pipe-based Context Switching                   4000.0      51157.7    127.9
Process Creation                                126.0       1260.9    100.1
Shell Scripts (1 concurrent)                     42.4         43.2     10.2
Shell Scripts (8 concurrent)                      6.0          6.5     10.9
System Call Overhead                          15000.0     308931.8    206.0
                                                                   ========
System Benchmarks Index Score                                          11.3

感叹

总分 11.3 是什么水平呢，我用我的洛杉矶服务器也跑了一下，3.5GHz 的 E3 处理器，不过是共享主机，并且只有单核的使用权。得到的分数为 1245.

这说明，这个功率为 10W 不到的路由器综合能力果然很弱，哈哈哈。。。

不过就算再弱，竟然可以跑完整的 Linux 4.4，能够运行起 Python、Nginx、MySQL、PHP-FPM、SSHD、Samba、DNS 等等一系列服务，还非常的稳定，不得不让人对 Linux 竖起大拇指呀~

 

---

后来我又换了 K3 路由器，ARM 双核 1.4GHz，可以代表着当前家用路由的最高水平，我用它跑了一遍 UnixBench，结果见下一页。

两年过去了，今天下午又在网上看了一下目前的可穿戴式设备，经过这么几年的发展，风口已过，局面基本已成定局，我再来说说我的观点和看法。

两年前我经过精心挑选，买了我的第一款智能手表 Sony SmartWatch3，当时的文章：《智能手表行业观察 2015-6》

两个月后，觉得所谓的智能手表也就那么回事，比较失望，写了一篇：《对智能手表的负面评测》

。。。

这么长的一段时间，我换用了好几个手表和手环，今天再来说说我的一些观点和看法。

无论对于运动手环还是智能手表，能够看时间这是作为一个表最最基本的职能，除非你就把它视作一个美观的腕带装饰物，所以那些大部分不能看时间的手环，都是小众的选择。（这就是我闲置我的第一任 小米手环 的原因）

说到装饰性，这也是相当重要的一点，可穿戴式智能设备的另一不能忽视的元素就是其颜值。

其三，定位不要太高。除了那些 “可以打电话的手表” 外，大部分智能手表的定位都是作为一个手机的第二屏而存在，在手表上玩的再多的花样，不过是刚买来 2 个月的新奇罢了，具体的可以看上面的那篇文章链接~~

其四，也是我怒卖掉下文所买的 SW3 的原因，那就是续航，作为一款手表，2 天一冲甚至一天一充是根本不能接受的，毕竟这只是个手表，偶尔才看一看的手表，不是手机。我目前用着的 麦步手表，就是在我对充电时间深恶痛疾之后的正确选择—— 21 天待机。

最后，同样重要的一点在于选择一个大公司的热门产品，主要问题在于手机端 App 的开发质量。我现在的麦步手表就面临这个问题，另外第三任 bongXX 也是因为 App 太差而弃掉的。

总结一下，目前在我看来，如果现在要买一个可穿戴式设备，需要在意以下几点：

1. 外观好看。这是第一要素哈哈，另外如果可替换标准表带最好。
2. 续航。5 天以下的直接 pass，待机时间越长越好。（苹果表和安卓表都是垃圾）
3. 时间显示和通知推送，以及健康监测等等基础功能。不过心率和 GPS 我倒是不在意的。
4. 功能性。能否扩展功能，换表盘等等，另外定时器功能是必要的，这是最实用的一样功能。
5. 大公司的产品。不会突然跑路的公司。

 

最后，让我缅怀一下 Pebble 的停产，以及麦步手表的即将倒闭，二者都是极为优秀的产品。但大概是极客的产品总是难以得到广大市场的肯定吧。

这是我打包的一大批 PDF 资源，精品质量，值得永久性收藏。动感新时代的增刊不必过多的介绍，我们这代的 ACGER 都熟悉其超高的质量。而动漫大辞典分为 5 册，涵盖 ACG 领域的方方面面，被誉为二次元的百科全书。

特别说明的是书籍扫描来自网络（贴吧 @ACGNEW），最初的资源都是由这位大神一页一页地扫描出来的，我也是看到了这些优秀的资源才萌生了制作 pdf 版的想法。在此表示感谢。

我做的事情

1. 很郁闷地充了百度云会员，然后从百度云下载了超过 10G 的扫描原件。
2. 使用 PS Script 批量自动调整图片曲线，解决部分扫描图片曝光过度的问题。
3. 批量等比例压缩图片至 1133px 宽度，做到体积与画质的平衡。不然 10G 的 pdf 是没人喜欢的，经测试，在 9.7 寸 Retina iPad 上阅读体验良好。
4. 使用 Python 批量转换 jpeg 为 pdf。

下载地址

动新增刊：链接: http://pan.baidu.com/s/1nvNuXQx 密码: 9tvg（已被百度禁止分享，郁闷）

动漫大辞典：链接：https://pan.baidu.com/s/1c4dH5Ws 密码：b13c

转载说明

打包的 pdf 素材来自于 @ACGNEW，如果有侵权我会立即删除相关资源。

大家可以自由地将此资源转发至任何平台，但是请保留指向本页面的链接 https://hzy.pw/?p=2377，或者表明来自于中原驿站（hzy.pw）

今晚给服务器装上了一个神器：PageSpeed，事实上这是一个 Nginx 的模块，使用它需要重新编译 Nginx，于是我顺便也将 Nginx 更新到了最新稳定版。最终效果相当给力，网站加速效果很好。心里非常的激动。

网站加速

给网站加速，请问有多少种方法？

压缩 JS、CSS，雪碧图，前端静态资源缓存，gzip，合并请求。。。

这些方法要多少有多少，作为一名合格的 web 开发人员，能在我服务器上运用的技术我都给运用上了。在开发前端页面时，各种强大的插件来保障资源的有效压缩。

不过，这始终还得让开发者来进行这样的工作，不开心~ :(

而 PageSpeed 就是这么的一个工具： 在服务器端安装之后，自动对用户请求的 HTML 页面进行语义化分析，智能的为其进行加速，加速途径涵盖了我能想到的一切~

图片所示的功能仅为部分

使用原因

WebP 是 Google 在 2010 年发布的一种新型图片格式，支持无损和有损压缩。在无损压缩方面，同质量的 WebP 图片比 PNG 的体积小 26%，而在有损压缩方面，同质量的 WebP 图片比 JPEG 小 25-34%。WebP 在不降低图片质量的同时，减少了约三分之一的体积。详细可参考谷歌官方。

哎呀，又是谷歌？！是的，我现在越来越喜欢这家公司了，非常酷。

我对 webp 是挺有兴趣的，因为图片一直都是流量的大头，降低了图片体积直接能影响到页面的加载速度。于是最开始，我是在寻找 WordPress 中别人开发的相关插件，可惜并没能找到合适的。

寻找中，我变找到了 PageSpeed，我勒个去，太强大了！作为一个 Nginx 模块，可以通过分析请求头，对支持 webp 的现代浏览器返回转换后的 webp 图片，而其他浏览器则依旧使用 jpg 等旧格式，太符合我的要求了~！

重新编译安装

跟随着教程 https://modpagespeed.com/doc/build_ngx_pagespeed_from_source 将 Nginx 重新编译了一遍，顺便将服务器中的旧版 Nginx 给更新到了 v1.10.3。

要说麻烦的话，那就是由于服务器运行在阿里云机房中，不能运行翻墙软件，谷歌的某个依赖库下载不下来。

另外在配置的时候，对于 HTTPS 也需要进行额外的适配，因为就算作为 Nginx 的模块，也是不能直接读取 HTTPS 协议下的内容的。

效果展示

PageSpeed 这个可爱的模块已经完全担当了服务器 Nginx 端的缓存控制角色，对于 jpg 转 webp 这样的耗时操作会在后台自动执行，下一次相同的请求过来时才会命中缓存，相当的给力！

顺便值得一说的是我的网站使用的是 HTTP/2 协议，速度当然比 20 年前的 HTTP/1.1 要更快啦！

上面的图可以看到，网页中原本的 jpg 资源已经被自动转换为 webp，而这一切都是自动的。

超开心！

最近突然对各种加密算法有点感兴趣，想测试一下各个加密算法在加密同样的一段数据时，消耗的时间各是多少。

于是用 Node.js 写了一个小程序完成了计算，并且将结果生成为一张排行榜，很是有趣，发布到这里，说不定以后会用得上的。

相关说明

测试环境

CPU：i7 4700-MQ @ 2.40GHz

平台：amd64

Node.js v7.4.0

测试数据：8MB 随机二进制文件

对称加密秘钥：8B 随机字符串

源代码

这段小程序的源代码请访问：http://pastebin.com/rEeYHgSy

算法调用简介

我的代码虽然运行于 Node.js，但调用的是其内置模块 crypto，也就是用 C/C++ 编写的加密算法模块，并不是原生 Javascript。并且实际运行时 CPU 占用率为 15%，单核 CPU 满负荷，所以可以反应这些算法的实际运行效率。

输出格式

Hash 算法输出运行时间、结果转换为 hex 后的字符串长度。按算法执行时间升序排列。

对称加密算法输出加密时间、解密时间，以及加密和解密的平均时间。按平均时间升序排列。

测试的算法及特别说明

测试了 Node v7.4.0 中支持的所有 Hash 算法和对称加密算法。比较遗憾没有 chacha20.

其中部分对称加密算法在这个版本的 Node 中是不支持的，已跳过。GCM/CCM 对称加密算法在该版本下只支持加密不支持解密，在结果中标注为了 unknown，并且平均时间直接等于加密时间，但实际上解密时间基本都大于加密时间。

（亏我用的还是 stable 版的 Node，提供了方法一调用却抛出异常，都是坑啊…!）

Hash 摘要算法排行榜

time↓ retLength name
=====================================
12.38 40 ecdsa-with-SHA1
12.39 40 dsaWithSHA
12.39 40 dss1
12.41 40 ssl3-sha1
12.41 40 DSA-SHA1-old
12.42 40 dsaWithSHA1
12.42 40 DSA-SHA1
12.44 40 sha1
12.45 40 DSA-SHA
12.49 40 dsaEncryption
12.51 40 DSA
12.52 40 sha1WithRSAEncryption
12.54 40 RSA-SHA1-2
12.54 40 RSA-SHA1
14.72 32 RSA-MD4
14.72 32 md4
14.74 32 md4WithRSAEncryption
17.31 32 ssl2-md5
17.33 32 ssl3-md5
17.33 32 md5
17.33 32 RSA-MD5
17.34 32 md5WithRSAEncryption
18.52 128 sha512WithRSAEncryption
18.55 96 sha384
18.55 128 sha512
18.55 96 sha384WithRSAEncryption
18.79 128 RSA-SHA512
19.42 96 RSA-SHA384
21.78 40 sha
21.82 40 shaWithRSAEncryption
22.22 40 RSA-SHA
27.05 56 sha224WithRSAEncryption
27.06 64 sha256WithRSAEncryption
27.27 56 RSA-SHA224
27.37 56 sha224
27.57 64 RSA-SHA256
27.60 64 sha256
57.38 40 rmd160
57.39 40 ripemd160WithRSA
57.39 40 ripemd
57.39 40 ripemd160
57.53 40 RSA-RIPEMD160
78.92 128 whirlpool
657.74 32 mdc2WithRSA
658.35 32 mdc2
659.48 32 RSA-MDC2

对称加密算法排行榜

cipherTime decipherTime avgTime↓ name
=====================================
26.33 unknown 26.33 id-aes128-GCM
26.49 unknown 26.49 aes-128-gcm
26.52 unknown 26.52 id-aes192-GCM
27.35 unknown 27.35 id-aes256-GCM
27.48 unknown 27.48 aes-192-gcm
27.94 unknown 27.94 aes-256-gcm
25.12 30.89 28.01 aes-128-xts
25.29 30.87 28.08 aes-192-ctr
26.54 31.42 28.98 aes-256-ctr
27.22 31.28 29.25 aes-128-ctr
26.12 32.41 29.26 aes-256-xts
38.23 unknown 38.23 aes-128-ccm
38.29 unknown 38.29 id-aes128-CCM
37.07 43.09 40.08 rc4
25.70 55.17 40.43 aes-192-ecb
26.24 54.79 40.52 aes-128-ecb
25.91 55.21 40.56 aes-256-ecb
41.40 unknown 41.40 id-aes192-CCM
40.07 45.45 42.76 aes-128-ofb
44.35 unknown 44.35 aes-256-ccm
44.58 unknown 44.58 id-aes256-CCM
39.14 54.62 46.88 aes-128-cbc
39.50 55.86 47.68 aes128
45.21 50.54 47.87 aes-128-cfb
46.30 51.85 49.07 aes-256-ofb
41.94 57.43 49.69 aes-192-cbc
44.25 55.84 50.05 aes256
45.72 55.95 50.83 aes-256-cbc
49.21 53.30 51.26 aes-192-cfb
38.77 66.82 52.79 aes-128-cbc-hmac-sha1
51.51 56.69 54.10 aes-256-cfb
44.75 67.53 56.14 aes-256-cbc-hmac-sha1
54.38 59.59 56.98 rc4-hmac-md5
68.07 55.45 61.76 aes192
73.48 50.08 61.78 aes-192-ofb
53.46 81.27 67.36 aes-128-cbc-hmac-sha256
67.95 unknown 67.95 aes-192-ccm
53.43 85.33 69.38 aes-256-cbc-hmac-sha256
92.37 96.32 94.35 camellia-128-cfb
86.76 118.05 102.41 camellia-128-cbc
89.88 119.94 104.91 camellia-128-ecb
115.26 98.84 107.05 camellia-128-ofb
111.06 118.04 114.55 camellia-256-ofb
113.69 117.35 115.52 camellia-256-cfb
113.71 117.39 115.55 camellia-192-cfb
118.05 117.26 117.66 camellia128
107.79 137.33 122.56 camellia256
107.93 137.41 122.67 camellia-192-cbc
107.63 137.71 122.67 camellia192
107.78 137.58 122.68 camellia-256-cbc
109.79 140.16 124.98 camellia-256-ecb
110.63 143.20 126.91 camellia-192-ecb
140.93 116.48 128.70 camellia-192-ofb
131.18 138.02 134.60 cast5-ofb
123.23 152.91 138.07 cast
123.20 153.14 138.17 cast-cbc
124.30 153.77 139.03 cast5-cbc
123.54 154.71 139.12 bf-ecb
128.97 153.40 141.18 blowfish
139.52 143.40 141.46 bf-cfb
129.20 154.59 141.90 bf
128.50 155.55 142.02 bf-cbc
140.97 151.75 146.36 cast5-cfb
160.98 138.92 149.95 bf-ofb
153.84 153.59 153.71 cast5-ecb
169.80 175.30 172.55 seed-ofb
175.17 171.99 173.58 idea-cbc
179.36 197.25 188.30 seed
180.20 199.18 189.69 seed-cbc
204.93 179.90 192.41 seed-cfb
192.36 197.95 195.16 des-ofb
190.88 212.10 201.49 des-cbc
190.91 212.15 201.53 des
200.83 203.79 202.31 des-cfb
190.93 216.70 203.81 desx-cbc
212.52 215.72 214.12 des-ecb
193.71 247.75 220.73 desx
285.34 208.45 246.90 rc2-ecb
287.99 207.70 247.84 rc2-64-cbc
383.14 407.20 395.17 aes-128-cfb8
428.57 433.04 430.80 aes-192-cfb8
472.68 478.71 475.69 des-ede3-ofb
473.08 478.73 475.90 des-ede-ofb
466.29 495.94 481.12 des-ede
466.96 496.02 481.49 des-ede3
469.45 494.77 482.11 des-ede-cbc
470.11 495.39 482.75 des3
480.87 485.29 483.08 des-ede-cfb
471.00 496.02 483.51 des-ede3-cbc
478.58 508.53 493.55 aes-256-cfb8
510.35 485.85 498.10 des-ede3-cfb
1144.31 1161.45 1152.88 camellia-128-cfb8
1433.53 1452.09 1442.81 des-cfb8
1486.53 1500.01 1493.27 camellia-192-cfb8
1490.02 1501.36 1495.69 camellia-256-cfb8
3486.28 3491.02 3488.65 aes-128-cfb1
3742.25 3749.80 3746.02 des-ede3-cfb8
3875.10 3877.43 3876.26 aes-192-cfb1
3990.26 3974.18 3982.22 des-ede3-cfb1
4271.61 4273.34 4272.48 aes-256-cfb1
9526.06 9744.03 9635.05 camellia-128-cfb1
12183.0 12151.8 12167.4 camellia-256-cfb1
12180.5 12200.0 12190.2 camellia-192-cfb1
12273.5 12334.8 12304.2 des-cfb1

一直觉得现在的安卓系统越来越优秀了，在会玩机的人的手里可玩性相当的高。我这里整理出了一系列非常棒的 App，属于谁用安卓系统我就会推荐给他的那种。希望大家喜欢！

这个应用集由我整理于酷安（最良心的国内应用市场），进去之后可以直接点击下载：

http://www.coolapk.com/album/2798021

 简介 

这是一个用于高校毕业生毕业流程线上管理的教务系统，由 Moshel 独立开发，并与 2016 年末开始被应用在西安石油大学计算机学院内。

毕业生在毕业设计时，需要学生与老师所出的题目建立一个多对一的关系，教师出题需要两层审核，而学生拥有三轮选题的机会，并且学生之间可相互竞选题目，此外，管理员可统揽全局，控制教务流程的进行，以及对相关数据的处理。这些就是本系统的大致功能。

答辩环节的完全线上化将是本系统的下一个主要开发方向。

链接：http://bkbysj.xsyu.edu.cn/（限西石大内网访问）

 系统功能 

作为一个完善的业务系统，除了 “选题” 功能外，还拥有完善的账号管理系统及附件管理系统等。

这张用例图是系统设计阶段所画，目前系统的功能已不局限于此。

教师拥有的功能

  

（↑ 点击可查看大图）

教师可以出题，并且实时跟踪自己题目的状态，历年所出题目会形成一个自己的题库以供复用，题目支持上传附件。这些特性弥补了旧选题系统的遗憾。

值得一说的是，本系统中所有的用户头像均不相同，根据用户 UID 哈希生成的随机矢量风格，避免了所有老师学生都使用默认头像的尴尬又无聊的景象。

学生角色

学生是本系统中最简单的角色，可进行选题，以及在选题成功之后通过此系统向老师发送文件。

在选题方面设计了 2 个人性化的特性：1、能看到某道题当前已选人数，这大大避免某道题被大家集中选择。2、在教师查看你的选题志愿之前，可以取消申请，并另选一道题。（事实上在此系统中所有的状态转移均支持最大程度的撤销操作）

管理员信息统揽

（↑ 点击可查看大图）

专门为管理员设计的功能占整个系统工作量的 70% 以上。管理员面板中，可以管理所有的用户类型，设定每位用户的类型，也可以看到现在所有选题配对情况。

值得一说的是，管理员支持使用 Excel 批量导入每届学生老师信息，系统会自动解析 xlsx 文档，并创建对应的登陆账号。

此外，本系统网页中所有可见的表格信息均可一键导出为 Excel 或 Word 文档，方便进一步办公处理。

仪表盘

数据可视化算是最近几年的技术热点，所以我为管理员开发了一个单独的仪表盘页面，用于总览整个选题流程的进行。

在这里，可以直观的看到待选题目和学生总数的柱状对比图，也可以分专业以饼状图的形式看到当前各专业学生的选题状态分布。这些都是选题流程中管理员需要掌握的数据。

数据库备份还原

 

本系统还拥有一个强大的自动备份还原功能，系统会自动在每天凌晨 3 时进行一次数据库备份，同时自动删除 15 天前的备份（不支持手动删除），当然，用户可以选择在需要的时候随时手动创建一个备份。

这样的设计使得系统更加稳定，无论是管理员的误操作，还是被任何形式的恶意攻击，都不会对系统造成很大的影响。

公告系统

 

（↑ 点击可查看大图）

本系统拥有完善的公告系统，支持富文本编辑、设置置顶、支持设置公告对不同类型用户的可见性，以及附件支持。

 关于技术 

以上说的是功能介绍，关于技术的细节欢迎大家点击以下两个链接继续阅读：

1、我在 2016 年 9 月写的：Meteor + React 教务系统开发经历

2、我在 2016 年 10 月发的相关论文：A High Performance Information System for College Graduation Management Cloud

技术亮点预告

1、使用 Javascript 全栈开发，包括 Node 作为后端，React 作为前端框架，MongoDB 作为数据库。

2、使用 Websocket 进行前后端通信，而不是 HTML 或者 AJAX。

3、使用黑科技实现前端浏览器直接操作数据库。