Browse Source

Move contents out of the repo

Track3 5 years ago
parent
commit
4d3e98a943

+ 1 - 0
.gitignore

@@ -1,4 +1,5 @@
 .sass-cache/
 public/
 resources/
+content/
 hugo.exe

+ 0 - 23
content/about.md

@@ -1,23 +0,0 @@
----
-title: "About"
-date: 2018-03-20T20:16:07+08:00
-draft: false
-comments: false
----
-
-大学狗一只,纺织工程专业。喜欢折腾各种事物,热爱数码科技,本想学计算机专业,却在纺织的路上越走越远。
-
-本站始建于2016年,用了两年多的WordPress,终于还是换成了静态博客。不管怎么说,这还是那个分享个人所见所闻所思的自留地。
-
-## Contact
-
-* Telegram: [@ThatTrack3](http://t.me/ThatTrack3)
-* Twitter: [@ThatTrack3](https://twitter.com/ThatTrack3)
-* Weibo: [@Track-3](http://weibo.com/u/2350674815)
-* QQ: 5-7-2-3-0-3-7-1-2
-* Email: pengliabc{at}live.cn
-
-也欢迎去这些地方和博主一起愉快地玩耍:
-
-* Steam: [@Track3](http://steamcommunity.com/profiles/76561198244211610)
-* 网易云: [@Track3](http://music.163.com/#/user/home?id=34583669)

+ 0 - 17
content/friends.md

@@ -1,17 +0,0 @@
----
-title: "Friends"
-date: 2018-03-20T20:16:19+08:00
-draft: false
-comments: true
----
-
-这里是本站的留言板,你可以在这里随意留言。
-
-以下是小伙伴们的网站:
-
-* [闲淡酱杂货店](https://www.geekcj.com/)
-* [清风小墨](https://windy.ink/)
-* [Ozem's Blog](https://ozem.xyz/)
-* [远方的行者](https://webnotes.me/)
-* [果壳Sir](http://gksir.top/)
-* [柠檬不萌](https://hmian.online/)

+ 0 - 78
content/posts/2017/3-years-of-win10.md

@@ -1,78 +0,0 @@
----
-title: 三年Win10,回首
-date: 2017-10-02T20:40:21+08:00
-draft: false
-toc: true
-images:
-  - https://assets.xxxlbox.com/images/2017/win10.jpg
-tags:
-  - 杂谈
-  - Windows 
----
-
-三年前的今天,Windows 10首次与我们见面。转眼三年过去,回头看,Win10的变化真的不少。
-
-作为第一时间加入Windows Insider Program的第一批Win10用户,我对Win10有一种特别的感情。Win10的成长之路中,有太多的惊喜与感动了,这里就简单回顾一下Win10发展历程上一些令人难忘的瞬间吧。
-
-## "Windows TH" or "Windows 9" ?
-
-很早就听到下一代Windows的传言,当时已经有了代号为Windows Threshold的系统运行截图泄露出来。于是大家就在猜测下一代Windows的正式命名,可以说大部分网友都认为是Windows 9,然而有意思的是,北京时间10月1日凌晨的那场面向媒体的小规模发布会上,Terry宣布下一代Windows将是Window 10。记得那时正是我高三的国庆节假期,早上起很早打开IT之家,Windows 10这几个字疯狂轰炸我的眼睛,然后评论都是什么“Windows9吧吧主哭晕在厕所”“软媒Win9之家哭晕在厕所”什么的,真的挺搞笑的,好吧,微软你赢了。
-
-![Windows10 name](https://assets.xxxlbox.com/images/2017/img017.jpg)
-
-我第一时间加入了Windows Insider Program,装双系统尝鲜了Win10的第一个对外公开的版本Build 9841。对这个版本第一感觉就是,真的太像Win8.1了。把开始屏幕移到了开始菜单里,Charms栏并未移除,用Win+C组合键依然可以呼出,桌面图标,任务栏也是Win8的风格。窗口边框变成了只有一像素宽,过渡动画也被移除,让人很不习惯。现在看来真的很难想象,Win10能变化成今天这个样子,是要动多少刀子啊……
-
-随后推送Build 9860时也是让人难忘,在系统设置里检查更新,下载时没有进度条,5个小圆点就一直在那转圈。我足足等了四个小时都没什么变化,也不知道进展如何,最后没办法直接下系统镜像安装……传言这个版本进行了7000多处改进,好吧,基本上都是内核改进。另外有人记得Build 9879的硬盘丢失事件吗,幸亏我装的是慢速版,并没有碰到。
-
-可以说这个阶段Win10基本上只能算是雏形,当时公开的这些版本叫做技术预览版(Technical Preview),显然,Win10还有很长一段路要走。
-
-## “下一篇章”
-
-2015年1月22日北京时间凌晨1点(1月21日太平洋时间早上9点),微软将在总部雷德蒙德举行发布会,主题为“Windows 10: The Next Chapter”。这次发布会可以说干货满满:宣布Win10一年免费升级、发布Win10面向消费者的预览版、宣布手机版Windows 10、宣布全新浏览器斯巴达(Project Spartan)、Continuum概念的提出、Cortana来到PC,另外还有重磅硬件Hololens……发布会后推送的Build 9926开始菜单获得重新设计,任务栏也用上今天Win10上默认的黑色配色。可以说终于有个版本看上去比较像今天的Win10了。
-
-![Windows10 9926](https://assets.xxxlbox.com/images/2017/img018.jpg)
-
-四月底的Build 2015大会上,斯巴达浏览器被正式命名为Microsoft Edge,同时,技术预览版也被改名为Insider Preview。我们已越来越能够感觉到,Win10离正式版越来越近了。
-
-终于2015年7月29日,Win10正式版来了,版本锁定Build 10240。
-
-然而,这并不是终点,而是起点。
-
-## Windows as a Service
-
-Windows 10将是最后一个Windows,这意味着Windows将不会再有像Win11、Win12这样大版本的更新了,而是隔一段时间进行小更新。也就是说Windows 10将不仅仅是作为一款软件来销售,更是当成一种服务来卖。因此Win10会不断得到更新,不断完善。
-
-Win10正式版10240推出后,微软随即开始了TH2分支的开发。新系统在15年11月面向Win10用户推送,这个版本是Build 10586,外部版本号称为1511,按年月来命名。我个人感觉Build 10240更像是一个为了让Win10尽快上市而赶工完成的伪正式版,一些功能特性并没有达到预期,1511版正是对10240的一些细节上的完善,可以说,1511这个版本才算是真正的Win10初代正式版。1511新特性主要有:
-
-* **右键菜单。**在任务栏上点击右键,弹出菜单变成与开始菜单和磁贴上的右键菜单一致深色风格,而不是10240上与桌面右键菜单相同的浅色风格。
-* **标题栏配色。**标题栏颜色可随着系统颜色同步改变
-* **Edge浏览器。**支持标签页预览、Cast Media和WebRTC。
-* **应用可安装到其他分区。**应用商店下载的应用可放在C盘之外。
-* **……**
-
-TH2分支后便是RS(Redstone)分支了。16年7月,Win10一周年更新(Anniversary Update)推送,版本锁定Build 14393。时过一年,Win10的免费升级期限也到了,可是改系统时间也能享受免费升级的Bug却迟迟没有修复。可能三年10亿安装量的目标有些大了,MS也就睁一只眼闭一只眼了。不过好消息是,Win10八个月装机量已突破 2.7 亿,看来完成目标还是很有希望的嘛。
-
-当然,1607作为一周年的大更新,新特性也自然不少:
-
-* **Windows Ink。**平板电脑和支持触控的笔电带有手写笔会很实用,提供不错的绘画手写体验。
-* **Edge浏览器扩展。**可在应用商店下载。
-* **Cortana升级。**锁屏上可唤醒Cortana。
-* **系统界面调整。**开始菜单布局逻辑调整、操作中心图标被移到了任务栏最右侧……
-* **安装界面尴尬的中国古诗。**
-* [……](https://www.ithome.com/html/win10/244377.htm)
-
-时间迈向2017年,RS2分支迎来正式版Build 15063,这次更新被称为创意者更新(Creators Update),外部版本号1703。
-
-* **画图3D。**经典《画图》程序可能是很多“老司机”们刚接触电脑时的好基友,承载了很多老用户的回忆。现在我们有了更强的《画图3D》,可以轻松创造3D图像,放飞创意。创意者更新大概就是这么得名的吧。
-* **游戏模式。**
-* **Windows Defender迎来更加Modern的设计。**
-* **夜灯。**开启之后,屏幕会显示偏暖色调,减少蓝光伤害。
-* [……](https://www.ithome.com/html/win10/302312.htm)
-
-三年来,Windows 10的各种变化远远不是简单罗列一下就能说尽的,不过总之,Win10是越来越好了,越来越好看,越来越好用。不出意外的话,秋季创意者更新(Fall Creators Update)将在17号推送,期待全新的设计语言Fluent Design(Project Neon)……
-
-Win10的时代,我们不仅仅是见证人,从“Win9”突然变Win10,经历Win10从襁褓到弱冠的整个历程,我们更是Win10时代的参与者。用户从来没有在Windows的开发中有这么高的参与度,用户的反馈从来没有受到像现在这样的重视。正如Win10的Slogan:
-
-> Windows 10 is not for all of us, but for each of us.
-
-![Ninja Cat](https://assets.xxxlbox.com/images/2017/img019.jpg)

+ 0 - 16
content/posts/2017/decided-to-buy-cuphead.md

@@ -1,16 +0,0 @@
----
-title: 下定决心买《茶杯头》
-date: 2017-10-05T22:22:08+08:00
-draft: false
-tags:
-  - Steam
-  - 游戏
----
-
-纠结了几天,最终还是决定买下。
-
-复古卡通画风,配上爵士乐BGM,一下子就把我带回童年。为了保持20世纪30年代的卡通美学,游戏的每一帧均为手工绘制,这工作量也就可想而知了。难怪Cuphead几年前就已亮相,直到现在才正式发售。
-
-可以说,游戏的品质毋庸置疑,唯一让我犹豫的就是游戏难度。看到Steam上很多玩不下去退款的,我就先下了破解版体验了一下。虽然狠狠砸了几次手柄,不过感觉游戏还没有难到让我碰都不想碰的地步。难,但是很有意思,决定入正了。
-
-这次就不在Steam上买了,Win10商店这边可是支持"XBOX Play Anywhere"啊,万一以后买了Xbox呢?

+ 0 - 95
content/posts/2017/goodbye-my-windows-phone.md

@@ -1,95 +0,0 @@
----
-title: 别了,我的Windows Phone
-date: 2017-08-14T21:47:52+08:00
-draft: false
-images:
-  - https://assets.xxxlbox.com/images/2017/lumia-830.jpg
-tags:
-  - 杂谈
-  - Windows
----
-
-Windows Phone死了。一年之前我是不信的,现在,我不得不信。
-
-几天前看到了WP8.1结束主要支持的消息,心头一凉。去[微软官网上查询](https://support.microsoft.com/zh-cn/lifecycle/search?alpha=Windows%20Phone)得知,WP8.1主要支持结束于2017年7月17日,这也就意味着WP8.1用户将不会再收到任何功能上的更新了。要知道有相当一部分的WP用户并未升级到Win10 Mobile系统(事实是很多机型被微软放弃适配,理由是硬件性能不达标),WP8.1在Windows手机阵营中仍占有七成的份额,因此这个消息算是足够劲爆了。
-
-## 我与WP
-
-我接触Windows Phone系统并不是很早,记得那是WP阵营最好的时代——2014年。
-
-故事还要从老妈的直板按键机说起。老妈使用多年的爱机因充电口松动导致充电易中断,严重影响正常使用,因此换机就提上了议事日程。正如很多的2G用户那样,老妈对手机的要求就是打电话发短信,所以她还是更倾向于用功能机。作为家里最懂手机的人,老妈换机就必然要参考我的意见,我当然是劝他换智能手机啦。用过几年Android的我深深感到此系统不适合她,又对WP系统“觊觎已久”,因此我最终还是说服了老妈,下单了Lumia 525。
-
-{{< figure src="https://assets.xxxlbox.com/images/2017/img012.jpg" alt="Lumia 525" caption="依然健在的Lumia 525" class="left" width="403" height="302" >}}
-
-525使用Lumia Black固件,搭载WP8 GDR3系统。这个在今天看来边框能跑航母的手机,打开了我进入WP世界的大门。说实话,第一次打开这个系统的时候真被惊艳到了,系统丝滑流畅,相当跟手,磁贴界面在Android、iOS那种桌面图标面前显得是如此别致,过渡动画也是逼格满满。深入体验下来,微软服务用起来也是爽爽的,OneDrive与系统深度集成,跟电脑同步照片文件真心方便。WP系统比Android省心不少,老妈也能轻松上手了,还学会了玩微信……
-
-要说WP系统功能缺失其实我并没有明显的感觉,不过得知WP8.1有预览版的时候我还是忍不住就升级了。WP8.1的改进可以说是巨大的,一些一直遭受诟病的问题在WP8.1上得到了比较好的解决。WP8.1用起来很是舒服,我深深感到已经无法离开这个系统,因此我觉得,我的下一部手机将会是Windows Phone。
-
-{{< figure src="https://assets.xxxlbox.com/images/2017/img013.jpg" alt="Lumia 830 box" caption="只留下了盒子和一段美好的回忆" class="right" width="403" height="302" >}}
-
-真的不会再有哪个手机能像Lumia 830这样打动我了,从发布会看到手机的第一眼,我就被Lumia 830的工业设计深深吸引。高考过后,要入新机了,当然,我入了骚绿色的830。拿到手机后简直爱不释手,细细端详,这手机真的是不管从哪个角度看都好看啊,我不得不佩服老诺的设计功底(此时微软已经完成对诺基亚手机业务的收购,不过还是原班人马)。830使用Lumia Denim固件,系统为WP8.1 GDR1。之后的大学时光里,830一直都是我的主力机。应用生态方面,我也没什么好抱怨的,常用的应用都有了,就是有时一些应用的功能缺失会导致小尴尬,不过还在可以接受的范围内。
-
-本来想着WP我会一直用下去,没想到那天……暑假收假,火车凌晨四点半到榆次站,没公交,跟别人拼车,没想到手机竟落在车上。可能是我习惯调成震动的缘故,手机打了没人接,而且手机电量也不足了。回到宿舍定位,之后便杳无音讯——我的Lumia 830就这样丢了。
-
-{{< figure src="https://assets.xxxlbox.com/images/2017/img014.jpg" alt="一切信号停留于此" caption="一切信号停留于此" width="745" height="310" >}}
-
-没想到,我就此离开了WP。由于实在是找不到适合心仪的WP新机,就想先买个安卓用用。考虑到以后可能还是要用回WP,于是我就买了台便宜的魅蓝 note3。它陪伴了我接近一年的时间,万万没想到这一年的时间,微软一台新手机也没出。我对WP死心了,这个暑假,我在闲鱼上淘了个二手Nexus 6p,那么这也就意味着我短期不会再用回WP了。
-
-我离开WP不是因为系统不好用,也不是因为应用生态不行,更不是因为大家都脱坑了,而是微软自身对WP的消极态度。看看WP阵营还有新机发布吗?官方商城上都没手机的影子了。以前微软口口声声说不会放弃Windows Phone,好,我信,只要你手机在出,我就会买。再看看现在这架势,不明摆着破罐子破摔吗,那我还有什么必要坚持呢?
-
-别了,我的Windows Phone。再也不会熬夜等新系统推送了,再也不会因应用有更新了而激动不已……
-
-## 扶不起的阿斗
-
-WP系统真是个扶不起的阿斗,即使诺基亚倾其所有,光荣献身。要知道微软在手机行业有近20年的征战历史。早在1997年,微软就发布了第一代移动设备操作系统Windows CE1.0,远远早于iPhone以及Android的2007年。那为什么微软的Windows Phone乃至整个移动部门都走如此艰难呢?我个人总结了这么几点:
-
-### 折腾
-
-微软真的太能折腾了,战略决策失败。微软似乎一直没有为WP系统的发展规划好清晰的路线图。WM6到WP7,基本上就是推倒重来,这个我们暂且不提。WP8改用NT内核,一举废掉WP7的CE内核。系统的内核不同,这意味着什么?这意味着WP8与WP7几乎就是两个系统,虽然它们有着相似的系统界面。这一更改直接导致WP7设备与WP8系统无缘。可以说这是广大WPer最受伤的一次经历了吧。之后又发生了什么呢?普通用户这可能感觉不明显了,WP8.1推出了一个叫UAP(Universal Apps)的概念,就是通用应用,应用的格式从xpa改为appx,与桌面Windows实现了一定的意义上的共通。Windows 10年代,微软又提出UWP(Universal Windows Platform)的概念,即通用平台。UWP支持跨设备跨体系结构,一次编写,全平台运行。我承认,微软的这些理念都非常先进,都非常面向未来。然而,这每一次应用架构的更改,可都是需要开发者或多或少地重写代码啊,看看你的用户数量市场份额吧,有多少开发者愿意陪着你玩!每次,都是大折腾,一次两次也就算了,数数看这有几次了?
-
-{{< figure src="https://assets.xxxlbox.com/images/2017/img015.jpg" alt="Win的统一之路" caption="艰难的统一之路:从统一内核到统一应用再到统一平台" width="600" height="331" >}}
-
-### “龟软”
-
-在系统功能残缺不全时,微软动作太慢,市场份额被Andriod和iOS蚕食。就说一个应用媒体播放音量与来电通知音量单独设置的功能,微软硬是拖到WP8.1才加入。这个说出来一些一直用Android或iOS的读者会感到震惊吧?8.1以前的WP系统只有一个音量调节,是的,游戏、音乐、来电、短信、闹钟等通通是一个音量。再比如说常用设置快捷的快捷开关,这种重要的功能同样是在WP8.1中加入的。连个WiFi不得不进系统设置,在长长的列表里翻找,想想就累。你可能会说有应用可以把常用设置固定到开始界面的,没错,我的确装过这种应用,不过我不认为需要用第三方应用来满足刚需的系统是一个合格的系统。更不用说WP很多接口都不开放,第三方应用也无能为力了。
-
-就这样慢慢地,Windows Phone系统就被戴上了残废系统这个帽子。可以说直到Windows Phone 8.1这一代,WP系统的功能才跟上Android以及iOS的步伐,然而这都为时已晚。说WP8.1是残废系统肯定不对的,然而,“残废”的想法早就在人们的头脑中根深蒂固了,微软的不走心导致用户以及开发者的大量流失,应用生态的建设难上加难。要知道生态上落后了可并不是像添加几个功能这样好追上的。
-
-### “巨硬”
-
-微软太固执死板,不重视用户的反馈,满满的大企业作风。前面说到的音量分离、快捷开关包括通知中心哪一个不是WP用户满心期盼吵着要的功能?为什么微软一直都无动于衷呢?微软一直都在用做桌面的思路来做移动系统,WP系统的手机硬件配置似乎总比同时期的Android低一些,而价格却又相对更高一些,WP系统的授权费功不可没。微软梦想着能像自己的PC系统那样,坐收授权费,可是却被现实狠狠地扇了几耳光。素质不过硬,并没有人会用你的系统,即使你是桌面操作系统领域的霸主。
-
-说了这么多,总结起来就是:在怎么讨好消费者以及开发者两方面,微软都做得不好。然而这一切的根本原因是微软根本就不重视移动部门,哪怕微软拿出做桌面系统十分之一的热情,Windows Phone也不会落到今天这般田地。
-
-## 未来
-
-微软错过了互联网黄金十年,现在看来是不是又错过了移动时代?Windows Phone包括Windows 10 Mobile该何去何从?传说中的Surface Phone会到来吗?
-
-我们来看看纳德拉提出的“移动为先,云为先”的战略吧。说实话,目前从表面上来看我真的只能看出云为先。
-
-* 大幅减记并购来的诺基亚资产,百亿美元的收购算是打了水漂。
-* 今年的Build2017大会,第一天的Keynote通篇讲云计算,演示用的手机还是iPhone。
-* Lumia迟迟未出新品,产品线几乎停掉。
-* 云计算业务营收疯狂增长,而WP系统份额则跌到接近消失
-
-请问移动为先体现在哪里,自己的独家应用纷纷登陆登陆Android、iOS等移动平台算是移动为先吗?
-
-相信微软心里是有数的。微软在云为先上动作非常快,因为没有沉重的包袱,而在移动为先上,情况就要复杂得多。微软的很多独家服务,以往只能在微软自己的平台上才能用到,现在则覆盖到了更多的平台上。与其让那些软件服务独占,还不如让更多的人使用上自己的产品。这其实就是一种甩掉包袱的表现,不能让WP微不足道的市场份额拖累了自家服务的推行以及用户的培养。微软现在停止了Lumia产品线的更新应该也是想甩掉包袱,准备搞些大动作。
-
-Build2017上演示的骁龙835运行Windows 10,想想看,这样的设备不就是Surface Phone吗。一台搭载ARM芯片的手机,接上显示器和键鼠,就可以运行桌面应用,这不就是我们梦寐以求的移动计算吗?以前的思路是把手机系统慢慢改造成与PC共通,建设与PC通用的应用架构,使手机能够变得更加强大,以代替一些必须电脑才能完成的事;现在的思路就是让桌面Windows能够在ARM架构上运行,同时适应移动设备的小屏触摸操作,然后手机接上键鼠显示器后不光能运行UWP通用应用,而且还能运行桌面应用。不管是哪一种思路,UWP通用应用都是重要的一环,微软的想法是让通用应用慢慢取代传统应用程序,最终把Windows打造成真正的通用计算平台。
-
-最近又听说了微软代号为Andromeda的系统,外媒Windows Central爆料:
-
-> Andromeda是一个Windows版本,旨在模块化,其不受设备形态约束,能够模块化适用于不同的设备,并且支持折叠特性,支持Win10 CShell。 需要注意的是,现有Windows 10 Mobile手机不会获得红石3更新,会待在Feature2分支。但会更新Feature2分支的API,使Feature2也能使用为红石3、4开发的UWP应用。
-
-听到这个消息,我便不得不相信Surface Phone的存在——估计就是搭载着这个Andromeda系统。那么,现有Windows 10 Mobile手机不能升到新系统会不会被骂啊,毕竟历史似乎又一次重演了。不管怎么样,UWP通用应用平台这个东西应该是会一直坚持下来的吧,以前各种换内核还架构的,终归还是为了实现这个大一统,现在这个已经实现得差不多了吧,所以UWP应该不会有大变化了……
-
-不得不说,在实现多个计算平台统一上,微软的做法是真的激进,有时候甚至觉得是“步子大扯着蛋”了,频繁的变故导致用户和开发者纷纷逃离。我个人还是看好微软的万体一核战略的,最近各种查找资料,感觉纳德拉所说的“移动为先,云为先”可能就是这样的:
-
-> 我一直在等Surface Phone(或者确切说是等Continuum 3.0),不是执着,不是执迷,而是,我坚信绝大部分的办公性PC都不应该继续存在,一个公司和组织内部办公桌上应该只有显示器键盘鼠标,要么全公司全部云主机化办公,要么移动设备即为主机。上班,无线接入显示器和键鼠,下班,随身带走,随时也可以在家里加入外设办公或娱乐。手机即主机,这是一个大的进化方向。而手机做PC主机,Windows系统是现在演进成本最小的。
->
-> 云计算办公主机和手机即主机,这两种都是很不错的方向,起码,能极大的节约社会资源,凡是极大的节约社会资源和推动社会进步的,一定会成现实。第一代的计算机,像山一样,然后Wintel 带我们进入第二个时代:个人PC时代,再接着,会是移动PC时代和随身助理时代。
->
-> <cite>IT之家-刺客</cite>
-
-说到这里,我想表达的是,Windows Phone应该已是过去时了。是时候收好你的记忆,挥手告别了,微软移动新的时代或许就要到来……

+ 0 - 91
content/posts/2017/my-personal-landing-page.md

@@ -1,91 +0,0 @@
----
-title: 自己写的个人Landing Page
-date: 2017-10-22T21:10:04+08:00
-draft: false
-excerpt: 苦学Web前端,终于弄了个像样的网页出来。
-tags:
-  - 前端
----
-
-苦学Web前端,终于弄了个像样的网页出来。不废话,链接:[i.xxxlbox.com](https://i.xxxlbox.com)。
-
-![Landing页](https://assets.xxxlbox.com/images/2017/img020.jpg)
-
-我给这个页面起了个名字叫“The One”。为什么叫这个名字呢?说来真的巧,正想起名字的时候,听到了这首《[The One](http://music.163.com/#/song?id=469272617)》。虽然歌曲表达的意思跟页面内容完全无关,不过借用一下做个标题也无妨嘛……
-
-## 先说说特点吧:
-
-1. 使用Bootstrap框架,响应式布局;
-2. 黑白相间的熊猫配色,极简主义;
-3. 向下滚动时会有呼出动画(Reveal Animations)。
-
-## 使用的框架/库/API:
-
-* [Bootstrap](http://getbootstrap.com/);
-* [jQuery](http://jquery.com/);
-* [Font Awesome](http://fontawesome.io/);
-* [lightGallery](http://sachinchoolur.github.io/lightGallery/);
-* [scrollReveal.js](https://scrollrevealjs.org/);
-* [百度地图 JavaScript API v2.0](http://lbsyun.baidu.com/index.php?title=jspopular)。
-
-为了充实文章内容,我决定贴出一些代码,分享一下心得。
-
-首先我想分享一下CSS里"vh"和"vw"这两个单位,他们分别表示相对浏览器视窗的高度和宽度。浏览器整个可视区的高度和宽度分别被定义为100vh和100vw,所以如果你想把一个元素的高度设定到占满整个浏览器,那么可以简单地设定`height: 100vh`。而且,不管你怎么改变窗口大小,元素的高度总是会保持刚好占满浏览器视区。看到很多人用js实时改变高度来实现铺满效果,反正我的原则就是,CSS能实现的,坚决不碰JavaScript,这个单位简直不要太好用。
-
-然后我想分享一下Flexbox轻松实现元素垂直、水平居中对齐的方法。
-
-拿我的这个页面的header部分来说吧,我的header中有两个container,一个是装着标题以及社交按钮的大容器,一个是装着“点我向下滚动”按钮的靠下的容器。html就像这样:
-
-```html
-<header>
-    
-  <div class="container" id="hdr-center">
-   <h1 id="hdr-big-text">大标题</h1>
-    <h2 id="hdr-smaller-text">小标题</h2>
-    <p id="hdr-social">
-      <a class="fa fa-flag" href="#"></a>
-      …
-      <a class="fa fa-envelope" href="#"></a>
-    </p>
-  </div>
-    
-  <div class="container">
-    <p>
-      <a class="fa fa-chevron-down" id="showmore" href="#me"></a>
-    </p>
-  </div>
-    
-</header>
-```
-
-首先,我指定整个header部分:
-
-```css
-header {
-  display: flex;
-  flex-direction: column;   /* 设定主轴的方向(即项目的排列方向)为垂直方向 */
-  justify-content: center;  /* 定义项目在主轴上居中对齐 */
-  align-items: center;      /* 定义项目在交叉轴上居中对齐 */
-}
-```
-
-
-这样,header中的两个容器在水平和垂直方向上都是居中的。“点我向下滚动”按钮跑中间去了,那怎么样把它拉到header底部呢?这个时候,我对它上面的容器也就是`#hdr-center`设定:
-
-```css
-#hdr-center {
-  flex: 1;
-  display: flex;
-  flex-direction: column;
-  justify-content: center;
-  align-items: center;
-}
-```
-
-`flex: 1`算是`flex-grow: 1`的简写。`flex-grow`默认为0,表示如果轴上存在剩余空间,元素不放大。当只指定`#hdr-center`为`flex-grow: 1`时,该容器会扩大到占满整个轴,这样“点我向下滚动”按钮自然就被挤到下面了。然后再把`#hdr-center`设为`flex`,里面的大小标题和社交按钮就可以完美居中了!
-
-Flexbox真的是快速定位布局的神器,难怪新版Bootstrap都改用Flexbox定位了。如果不用Flexbox的话,垂直居中就不好实现,估计就是要把position设为absolute,然后`left: 50%; top: 50%;`之类的,这就把元素从正常的文档流中剥离了,总感觉这样的居中让人不舒服……
-
-心得体会大概就说这么多吧,总之,写这个页面真的学到了不少东西。栏目设计参考了一些大佬的个人主页,毕竟萌新,各位大佬莫见笑。另外,既然是前端,所有代码都是公开的,需要的可以直接拿走。也欢迎大家给我一些建议,遇到什么兼容性问题欢迎给我反馈,当然了,请务必使用现代浏览器.
-
-等等,是不是少了点什么?好像缺一个反馈表单。以我目前的能力,还做不出表单提交的后端。还是慢慢来吧,不管怎么说,这次整个页面都是自己一手设计、一行一行代码码出来的,虽说简陋了点,但我还是蛮开心的。毕竟萌新,以后会越来越好的。

+ 0 - 69
content/posts/2017/raspberrypi-lede-setup.md

@@ -1,69 +0,0 @@
----
-title: 变身智能路由器,树莓派配置LEDE
-date: 2017-05-29T17:25:44+08:00
-draft: false
-images:
-  - https://assets.xxxlbox.com/images/2017/Buy_Pi_Cover-01.png
-tags:
-  - 折腾
-  - 树莓派
----
-
-对于一台仅仅是能用来上网的路由器,我是不满足的。为了做很多interesting的事,我把目光投向手上这台吃灰已久的Raspberry Pi 3B。
-
-早就听说树莓派可以做路由器,可是网上总找不到详细的教程,[OpenWrt](https://openwrt.org/)官方也没有适配树莓派3B,我一直都没成功。直到有一天,我惊喜地发现OpenWrt的一个分支[LEDE](https://lede-project.org/)支持3B了,体验了一番,发现稳定性还有些问题,无法正常使用。最近发现LEDE有更新,试了一下,发现终于能用了。
-
-{{< figure src="https://assets.xxxlbox.com/images/2017/img005.gif" alt="techdata" caption="最先支持3B的一版是17.01.0,最近更新的版本是17.01." width="1232" height="171" >}}
-
-去[这里](https://lede-project.org/toh/views/toh_fwdownload?dataflt%5BBrand*~%5D=Raspberry+Pi+Foundation)下载树莓派LEDE固件。
-
-下载.gz格式的压缩包,解压,用Win32 Disk Imager将镜像烧录至SD卡。这个就不用多说了,相信玩树莓派的都熟悉。
-
-**2018.6.17 更新**:经测试,目前的最新版17.04工作不正常,17.01.2版能用。把下载链接里的所有`17.01.4`改成`17.01.2`即可下载到17.01.2版。至于17.01.3版请自行测试。这里再提供一个3B的[百度网盘下载](https://pan.baidu.com/s/1Vi-4PdQdJTw7ZJs41BUlyw)。
-
-由于树莓派刷LEDE系统后默认IP地址是192.168.1.1,这会与一般路由器的网关地址冲突,所以如果我们要把树莓派直接连到现有路由器上,以实现同一个网段对树莓派的访问,首先就要更改路由器的LAN IP为192.168.1.0或其他你开心的数字( 确保是同一个网段)。要是不想碰现有路由器,或者你现在并没有路由器(正准备用树莓派做一个),可以直接把树莓派用网线连接至电脑(LEDE的WLAN默认是关闭的,只能用有线;此时最好关闭电脑的WLAN)。我这里就是直接有线连接的。浏览器输入192.168.1.1进入LEDE的Luci web界面。
-
-![Luci web](https://assets.xxxlbox.com/images/2017/img006.gif)
-
-设定好密码以后进入Network>Wireless,点击"Edit"。在下面的"Interface Configuration"中的"Wireless Security"选项卡中设定WIFI密码(加密方式选WPA2-PSK),然后启动WLAN网络。
-
-![Luci interfaces conf](https://assets.xxxlbox.com/images/2017/img007.gif)
-
-此时就可以拔下网线,用WIFI连接,腾出来的那个网口就是WAN口了,我们把宽带接上。再次打开LEDE的后台配置界面,进入Network>Interfaces,编辑"lan"的配置。在"Physical Settings"里面去掉"eth0"即物理有线网卡的勾。保存并应用。这样,就可以确保树莓派上的有线网口是WAN专用了。
-
-{{< figure src="https://assets.xxxlbox.com/images/2017/img008.gif" alt="Luci interface conf" caption="取消'eth0'的勾选" width="1454" height="589" >}}
-
-然后,我们回到"Interfaces"界面下,点击新建一个"wan"的配置,协议请根据自己的实际上网方式选择,我这里是PPPoE。下面的"Cover the following interface"选"eth0"。然后输入宽带账号密码就可以连接上网了。
-
-![Luci interfaces conf](https://assets.xxxlbox.com/images/2017/img009.gif)
-
-![Luci interfaces conf](https://assets.xxxlbox.com/images/2017/img010.gif)
-
-有了网络,首先我们可以安装Luci的中文语言包。进入System>Software,点击"Update lists"更新一下源。直接搜素"zh-cn",安装"luci-i18n-base-zh-cn"。装完后进System设置,"Language and Style"里面选择中文就行了。
-
-![Luci software conf](https://assets.xxxlbox.com/images/2017/img011.gif)
-
-此时还有一个问题。我用的16G的SD卡,在LEDE下大概只有200多MB可用,我们还需要手动为文件系统扩容。我是参照网上的教程,用的fdisk和resize2fs,然而失败了。最后resize2fs的时候时报错,目前还没解决。不过听说还有个工具叫GParted,但是没有Linux的环境,Windows下需要U盘启动,就没有试……
-
-不知道是不是心理因素,用了树莓派的路由器感觉网比以前快多了(65元的渣渣路由器你懂的)。就是开网页的时候感觉反应飞快。虽然网速没有变快,但是感觉网络整体响应变快,可能网络延迟降低了吧。毕竟树莓派四核CPU加上1G内存对一个路由器来说简直豪华……
-
-然而,如果我们把树莓派刷成路由器,只是简单的把它当成一个上网用的设备,那是不是有点过于大材小用了?LEDE是OpenWrt的一个分支,本质还是一个Linux系统,因此有很多软件包可以<ruby>使<rp>(</rp><rt>zhē</rt><rp>)</rp></ruby><ruby>用<rp>(</rp><rt>teng</rt><rp>)</rp></ruby>。这些软件可以极大地拓展路由器的功能,实现各种黑科技。
-
-LEDE采用opkg的软件包管理系统,类似于Debian系的"apt-get"与红帽系的"yum"。我大致看了看软件源,感觉基本上可以把路由器弄成一个服务器了。
-
-下面说说我安装一些软件包:
-
-* openssh-sftp-server:实现sftp访问树莓派,方便传输文件。
-* UPnP:通用即插即用。一般的路由器都支持,没有理由不安装。
-* QoS:判断网络行为所需的带宽并进行自动分配,保障重要的网络行为数据优先转发,还可以为某个IP限速。一般的路由器都支持,没有理由不安装。
-* DDNS:动态dns,将自己的公网IP映射到一个固定的域名解析上,实现公网访问路由器,配置好防火墙和端口转发后还可以直接访问内网。由于一般宽带都不是固定IP的,所以这很重要。普通路由器也支持这个功能,不过往往是只支持花生壳(oray.com)的服务,LEDE上这个支持更多的服务商。
-* Aria2 + yaaw:下载机,设置好DDNS后轻松远程下载。
-
-还有一些软件是打算装的,还没有来得及:
-
-* Adblock:屏蔽广告。
-* Samba和MiniDLAN:打造NAS和多媒体共享中心。
-* LNMP:LEDE是带了一个web server的(不然Luci的web界面怎么打得开),叫uHTTPd。看了一下软件源,发现Nginx和php版本好新,Apache很旧。可能没有多少人会在路由器上跑数据库吧,mysql版本才5.1……考虑到树莓派的性能,sqlite可能是更好的选择。
-* Seafile:私有云。
-
-说实话,树莓派还是适合用来折腾,而不是拿来使用。毕竟不是专门的网络设备,网卡的带宽还是共享USB的,而且还是USB2.0,所以就捉襟见肘了。另外,市面上有很多智能路由器产品,它们都有图形化的后台界面,有配套的手机app,只需要几个简单的操作就能实现上面的很多功能,用户体验不知道要强多少。然而,费尽辛苦做成一件事的喜悦,真的只有经历过才会懂,这或许就是折腾的意义吧。

+ 0 - 91
content/posts/2017/stories-behind-amd.md

@@ -1,91 +0,0 @@
----
-title: 写在“锐龙”上市之际——AMD那段励志的故事
-date: 2017-02-24T20:27:13+08:00
-draft: false
-excerpt: 十年磨一剑,AMD Ryzen终于来了。可是AMD背后的故事,又有多少人了解?
-toc: true
-images:
-  - https://assets.xxxlbox.com/images/2017/amd-ryzen.jpg
-tags:
-  - 杂谈
-  - AMD
-  - Intel
----
-
-北京时间2月22日22:00,AMD在美国正式发布了全新的Ryzen(中文名“锐龙”)处理器。
-
-作为A饭,怎按捺得住内心的激动!要知道在这以前的很长一段时间里,PC半导体行业都被牙膏厂Intel支配,想买到高性能的U,穷鬼也只好捡破烂了。真不敢相信,自己竟能在有生之年见证“农奴翻身把歌唱”之日!实测AMD Ryzen 7 1800X完全可以匹敌Intel Core i7-6900K,而且价格还是后者的一半(黑心牙膏厂一直都在利用垄断攫取暴利)。桌面CPU市场终于可以从Intel挤牙膏的节奏中走出来,风暴终于来临了!
-
-{{< figure src="https://assets.xxxlbox.com/images/2017/img001.jpg" alt="Ryzen发布" caption="Ryzen来了!" width="1022" height="611" >}}
-
-也许直到今天,我们谈起AMD时,一些人仍会感到陌生,就算知道这家企业,印象也往往是什么CPU性能不如Intel、GPU市场份额没NVIDIA高之类的。必须承认的是AMD曾一度一蹶不振,持续低迷了很长一段时间,曾经的辉煌已鲜有人知。下面我们就来谈谈AMD的发展历程吧,一段艰苦奋斗的励志故事。
-
-首先我有必要解释一下,AMD是"Advanced Micro Devices"的缩写,翻译过来就是“超微半导体公司”,简称“超微”或“超威”(也许是因为在IT业界还有一家知名的主板企业“SuperMicro”在中国同样被称为“超微”,官方确定的中文名是“超威半导体”)。
-
-## 最初的十二年
-
-AMD成立于1969年,只比Intel晚一年,但它的基础却比Intel公司薄弱得多。公司的启动资金只有10万美元,刚成立时只能在创办人之一的约翰·凯利(John Carey)家中的客厅办公。除资金问题外,人才的缺乏也是AMD公司成立之初的一大棘手问题。Intel的两位创业者,诺伊斯(Robert Noyce)是集成电路的发明者之一,戈登·摩尔(Gordon Moore)则是著名的摩尔定律(Moore's Law)的提出者,他们在创办Intel前就在业界享有很高声望。而AMD就是一家普普通通的创业公司,不被大家看好,也很难吸引到人才。因此,AMD的创业初期可谓是困难重重。
-
-{{< figure src="https://assets.xxxlbox.com/images/2017/jerry-sanders.jpg" alt="AMD创始人桑德斯(Jerry Sanders)" caption="AMD重要的创始人桑德斯(Jerry Sanders)" width="1000" height="594" >}}
-
-通过团队的不懈努力,几个月后,AMD推出了第一个产品——一个4位的寄存器Am9300。次年AMD推出出了自己的专利产品 Am2501逻辑计数器(Am2501 logic counter), 取得了成功。之后AMD又相继开始生产晶圆,发行股票,在马来西亚建立生产基地,进入RAM市场……一直稳步发展。
-
-## 与Intel的合约
-
-Intel的先天优势使它在微处理器的研制上一开始就处于领先地位。1974年Intel研发出8位微处理器8080。AMD看到了微处理器所蕴藏的巨大市场,投入技术力量进行研究,根据逆向工程第二年就开发出兼容8080的微处理器8080A,投放市场。当时,为Intel设计出全世界第一颗微处理器的工程师Federico Faggin带领安泽曼、西玛等人离开Intel,投靠石油大亨埃克森(Exron),成立了Zilog公司,研制出一种叫Z80的微处理器,性能上甚至高于Intel同档次的8085(8080的增强型)。Intel为和Zilog竞争,需要生产更多的8085,但又苦于自己的生产能力不够。这时创始人桑德斯亲自到Intel公司总部谈判授权事宜,Intel同意授权AMD做它的第二供应商(Second Source)。
-
-之后,AMD表现出强劲的发展势头,公司的业绩达到了一个又一个的里程碑。当Intel开发出16位处理器8086时,却迟迟不愿给AMD授权,因为此时Zilog公司的威胁已不那么严重,Intel认为自己不需要借助AMD的力量了。何况AMD生产的芯片已经对Intel自己的产品构成了威胁,Intel不愿看到AMD再继续发展壮大。
-
-Intel在1978年推出了世界上第一颗x86微型处理器。1981年,IBM设计出了自己的PC产品并希望使用Intel的x86处理器,同时要求将AMD作为第二供应商。Intel不想丢失像IBM这样大的订单,只好又一次与AMD谈判,签署了一个十年技术交换协定(10-year technology exchange agreement)。1984年AMD的销售额达到了创纪录的11亿美元,同年Intel的销售额是16亿美元,作为第二供应商,能取得这样的成绩是很不容易的。此时,Intel已经有点坐不住了,准备采取些行动,防患于未然。
-
-{{< figure src="https://assets.xxxlbox.com/images/2017/img002.jpg" alt="Intel i386 & AMD Am386" caption="Intel的i386和AMD的Am386" class="left" width="359" height="558" >}}
-
-1985年Intel推出了32位处理器80386,但是当386芯片正式上市后,Intel却宣布将由自己独家制造。AMD公司和桑德斯本人都被Intel的出尔反尔激怒了,根据双方1981年签订的协议获得授权是理所当然的事情。在双方谈判无效的情况下,AMD在1987年一纸诉状将Intel告上了法庭。
-
-对于Intel公司来说,只要诉讼一天没有最终判决,AMD就一天不能生产386芯片,所以就想尽办法把这场官司拖着,希望能拖垮AMD。要是AMD像这样一味等待无异于坐以待毙。桑德斯果断地决定,AMD要自主开发完全兼容80386的芯片。
-
-一个精干的技术团队迅速投入开发工作,终于在1989年开发出AMD自己的386芯片Am386。但就在AMD公司上下举杯庆贺、为Am386的正式上市作准备的时候,Intel从一个极其偶然的机会获得了这一信息。为阻止AMD借助此新产品东山再起,Intel别出心裁地想出个理由,起诉AMD非法使用“386”这一所谓Intel的名字,Am386的上市又被拖延了。好在法院最后判定386是一个通用的名字,而非Intel所专用,Am386才得以上市,但这已经是1991年3月的事情了。虽然在Intel的百般刁难下,AMD错过了销售新产品的最佳时机,但Am386的推出对于AMD来说意义重大,它打破了Intel一手垄断PC处理器市场的局面,是AMD独立研发处理器的成功开始。
-
-AMD和Intel的官司从1987年开始,一直拖到1995年才最终结束。最后AMD终于取得了生产X86处理器的权利,赢得了在PC芯片业中的生存权和发展权,同时也为此付出了惨重的代价:数千万美元的诉讼开支、公司高层精力的分散以及新产品不能上市的无奈等,难以尽述。AMD能在旷日持久的“马拉松”式的诉讼中坚持下来,与桑德斯顽强不屈、百折不挠的个性是分不开的。这位AMD的领头羊和精神领袖出生在芝加哥一个底层家庭,有一种硬汉子的脾性。在和Intel的抗争过程中,桑德斯毫不屈服,正如他所说的那样:“永不放弃,永不投降!”,因此被誉为“硅谷牛仔”。
-
-## 开发自己的微处理器
-
-接下来AMD在1993年发布Am486,以比Intel版本更低的价格销售。很多OEM,包括Compaq都使用Am486。其实到目前为止,AMD设计的每一款处理器都是逆向工程Intel的产品得到的。由于电脑工业生产周期的缩短,这种策略令AMD越来越难生存下去,因为这意味着他们的技术将一直落在Intel的后头。于是,AMD坚定地走上了一条自主开发处理器的发展之路。
-
-> 我们不能只做Intel的追随者,我们此前似乎一直在模仿或追赶它,这种做法大错特错。
-  <cite>桑德斯(Jerry Sanders)</cite>
-
-1993年,AMD宣布了独立开发AMD K5处理器的项目,业界纷纷看好这颗K5的架构与性能。但是由于采用了全新架构,研制工作的复杂度和难度都大大增加,到了1994年AMD预定发布的日子,K5的开发工作还未完成,因而挫伤了外界对它的热情。1995年K5处理器终于上市,AMD对这款处理器给予了很高的期望,希望它能狙击Intel势头正盛奔腾(Pentium)处理器。可这时AMD才发现自己的一个重大失误:K5和Pentium的针脚不兼容。当时绝大多数主板都是为Pentium处理器设计的,要采用AMD的K5处理器就必须重新设计新的芯片组和主板,而依AMD当时的实力和影响力又无法做到这一点,结果K5的架构一直无法推广起来。这给了AMD一个沉痛的教训:即使有比市场主流产品更优越的架构,如果不能兼容于市场上的现有规格,还是无法成功的!
-
-经历K5的惨痛教训后,AMD决定引进新的技术力量以充实开发队伍。1996年收购了NexGen。随后推出K6、K7。其中具有K7具有重大战略意义,被命名为Athlon(速龙)。Athlon在性能测试中全面超过当时的Pentium Ⅲ处理器,从Am386到K7,经过长期不懈的努力,AMD终于在CPU技术上超越了Intel。
-
-2002年4月24日,AMD正式推出了K8架构的Opteron(皓龙),它具有划时代意义:世界上第一颗64位的CPU。是的,“amd64”就是这么来的!
-
-与此同时,Intel那边也丝毫不敢松懈,Pentium也一直在不断更新换代。
-
-这段历史也是整个行业发展史上最精彩的篇章。正是由于AMD的存在,Intel才不敢停下脚步,努力创新,生怕自己落后。红蓝大厂之间的竞争,直接加速了技术的进步。
-
-麦克尔·马龙说,在所有的高科技公司中,AMD公司是最可怕,也是最英勇的;它年复一年,代复一代,顽强地挑战这个星球上最成功、最著名、最具竞争力的公司之一。在同Intel的竞争中,Zilog、国家半导体、摩托罗拉、德州仪器、Cyrix、IDT、Rise等一个个败下阵来,不是烟消云散,就是无奈放弃,只有桑德斯带领的AMD,历经33年,不仅没有倒下,而且实力越来越强大。在80年代Intel授权的15家第二供应商中,SIEMENS、FUJITSU、HARRIS等都已放弃,只有AMD一家迄今还屹立在电脑芯片业。无怪乎桑德斯在接受UPSIDE杂采访时无比自豪地说:“唯一能阻止Intel在计算机世界实现全面控制的就是AMD。”
-
-## “后桑德斯”时代
-
-2000年,桑德斯正式把CEO的职务交给公司总裁瑞兹,自己则留任公司的董事长直到明年年底。瑞兹是桑德斯在2000年从摩托罗拉半导体公司挖来的芯片高手,以严格的营运专家著称。桑德斯相信这位新的CEO会做得比自己还好。
-
-现在桑德斯退居幕后了,他留给继任者的是一个在台式机处理器上和Intel分庭抗礼的AMD,一个在工作站和服务器处理器上雄心勃勃的AMD,一个在移动处理器上大举进入的AMD;更重要的是,他留给继任者的是一个在技术创新上已经能与Intel一争高下的AMD。
-
-可是之后发生的事多少有点让人揪心——AMD在与Intel的竞争中落后了。Intel推出了Core(酷睿)处理器,AMD全面落败,从此就一直被Intel压着。Intel也由于竞争对手不给力,开始了挤牙膏……
-
-2006年,AMD收购了ATI,从此有了自己的图形技术。同时,也与NVIDIA成了竞争对手。虽然AMD整体上持续低迷,但是还是取得了一些成就的。2010年,AMD(ATI)独立显示核心出货量超越NVIDIA成为世界第一。2011年,AMD推出APU=CPU+GPU的概念,即融合(Fusion)CPU及GPU于一体。Xbox One及PS4采用的均是AMD的芯片。
-
-不管怎么说,在Intel与NVIDIA的强力围功下,AMD终究还是活了下来。所以业界也有种说法:AMD是打不死的小强。
-
-现在大家该知道为什么Ryzen的发布让广大A饭如此了激动了吧?经历十年的低迷,AMD在处理器性能方面终于又能与Intel抗衡了。也许Ryzen不会使AMD今年的出货量一举超越Intel,但是市场早就需要这么一个搅局者了。Intel如果短时间内不能拿出产品,必然会选择降价,得实惠的还是广大用户。也许Ryzen并不会让AMD在短时间内崛起,但是它向外界释放了一个信号:红色巨人终于从沉睡中醒来!Intel,你还敢挤牙膏么?
-
-英特尔:不知怎么的7nm工艺突然就成熟了,我们决定8代酷睿直接上7nm!
-
-## 参考
-
-本文参考并引用了大量资料以及一些大神的帖子,现将主要的贴出:
-
-* 百度贴吧:[【给不了解AMD的你】AMD公司的历史](http://tieba.baidu.com/p/762849907);
-* Wikipedia维基百科:[Advanced Micro Devices](https://en.wikipedia.org/wiki/Advanced_Micro_Devices)。

+ 0 - 29
content/posts/2017/what-i-learned-from-removing-seafile.md

@@ -1,29 +0,0 @@
----
-title: 因卸载Seafile引发的尴尬
-date: 2017-08-17T17:42:40+08:00
-draft: false
-tags:
-  - 折腾
----
-
-前几天用Seafile搭建私有云时,一不小心吧程序安装在root目录中,导致Nginx死活403 Forbidden,不得已只能删了重装。
-
-先用`rm -rf`命令顺利删掉了Seafile的目录,之后就是删除Seafile在MySQL中创建的三个数据库了:`ccnet-db`、`seafile-db`、`seahub-db`。由于以前经常把WordPress折腾到重装,所以删除数据库的命令我还是记得很清楚的,不就是`drop database database_name;`吗,于是我在命令行中输入`drop database ccnet-db;`,结果……
-
-> ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-db' at line 1
-
-What?难道新版改了语法?
-
-TL;DR 太长不看(~~我真的没有注意到后面的提示'-db',还以为真的是我的语句打错了。首先我检查的是后面的分号是不是打成了中文的“;”,很显然不是,我把成功执行过的sql语句中的分号直接复制下来,结果还是报错。难道是语句前面部分要大写?我试了`DROP DATABASE ccnet-db;`,依然不行。难道是因为这个数据库特殊了,设定了什么不能删除的东西?不可能,明明报的是语法错误啊。百思不得其解,然后我就去找度娘了,还去了Seafile的官方社区,都没有什么线索,场面一度陷入僵局,我甚至想装一个phpmyadmin了。~~)
-
-我仔细看了一下错误提示,好像就是这个"-db"的锅,我猜测这个是MySQL的保留字段,所以整个数据库的名字应该用引号包起来:`drop database "ccnet-db";`,结果不行。那单引号呢,也不行。最后还是上百度查了一下,原来MySQL还真的有保留字,解决方法就是……用单引号括起来?不,那不是单引号,是“\`”这个字符,就是键盘数字1左边的那个键。好吧,问题就这么解决了,感觉自己宛如一个智障……
-
-我以前也删过Seafile的数据库,真的是一切正常啊,这个“-db”肯定是新加的保留字……我不得不吐槽一下Seafile了,你说你加个-db干嘛呢,你这放在数据库里的东西,谁不知道这是个数据库,偏要后面加个-db,有必要吗?重装时询问创建数据库名字时,我默默地把“-db”全都删掉了。
-
-事情远远没有结束。我查了一下“\`”这个键,又发现了一些奇妙的东西。这个符号叫重音符或抑音符,是一个变音符号,用于希腊语(1982年前)、法语、加泰罗尼亚语以及一些其他语言内。重音符在编程方面有独立的用途,通常被码农称为反引号。参见维基百科:[重音符](https://zh.wikipedia.org/wiki/%E9%87%8D%E9%9F%B3%E7%AC%A6)。然后让我很气的是,中文下,这个键可以输入间隔号“·”!我能说我以前一直都用输入法打间隔号吗?
-
-![输入间隔号](https://assets.xxxlbox.com/images/2017/img016.png)
-
-之后,我把键盘上所有的符号键都试了,发现数字6那个键,就是英文下能打出乘方的“^”,中文下竟打出了省略号……即“Shift+6”。好吧,6个点,数字“6”键,真的好有道理!
-
-你们不要说我水,最起码我打省略号都用的输入法这种高级方式,省略号打六个句点的大有人在,我就不信没人中枪。

+ 0 - 213
content/posts/2017/wp-sites-nginx-conf.md

@@ -1,213 +0,0 @@
----
-title: WordPress站点如何配置Nginx
-date: 2017-06-17T00:48:35+08:00
-draft: false
-tags:
-  - Nginx
-  - WordPress
----
-
-从LAMP换到LNMP环境有相当一段时间了,一直在研究怎么配置Nginx最科学,这里就简单分享一下经验。
-
-众所周知,Apache是全球使用最广泛的Web服务器,各种模块很多、教程也多,几乎可以满足你的各种需求。Nginx是一个高性能的Web服务器,它占用资源少,能轻松应对高并发的连接,相比Apache更加轻量化。可以说Nginx与Apache风格迥异,然而,网上很多关于Nginx的教程都是用的Apache的思路,一个配置文件各种写法的都有,让人很疑惑。也许是Nginx配置文件比较智能吧,感觉怎么写都能正常访问,然而作为强迫症,找不到最正确最科学的配置方法,简直难受。
-
-好好看了一下Nginx的官方文档,结合了codex.wordpress.org以及Nginx Wiki上的教程,我这里就简单总结一下,贴一下我的配置,有什么问题欢迎指出……
-
-首先,在运行WordPress时,Nginx与Apache大概有这些区别:
-
-* 对于一个php请求,Nginx无法直接处理php文件,所以一般它是将php请求传送到后端的php-fpm(默认在本地的9000端口侦听,即127.0.0.1:9000)来处理。而Apache是将php当作自己的一个模块来调用,只要开启了这个模块,无需进一步的配置,Apache就能直接解析php。
-* Nginx没有像Apache的`.htaccess`那样的文件目录级别的配置文件。Apache的配置文件是可以`AllowOverride`的,也就是说你在`.htaccess`文件中的配置可以覆盖程序目录中的主配置文件(那么这也就意味着每次请求,Apache都会去读取网站根目录下的`.htaccess`文件,这效率想想就可怕)。当然对于虚拟主机用户来说,由于无法自行更改Apache的主配置文件,`.htaccess`就很有用了。WordPress的自定义固定链接功能正是通过自动将伪静态规则添加到`.htaccess`中实现的,由于Nginx没有这个特性,所以伪静态规则就要在`nginx.conf`中自行添加了。
-
-## HTTPS+HTTP/2配置
-
-这一部分配置应该写在`http`块中。
-
-```nginx
-# Upstream to abstract backend connection(s) for php
-upstream php {
-    server unix:/run/php/php7.0-fpm.socket;  #使用unix socket
-    server 127.0.0.1:9000;  #使用TCP端口
-    # 上面两个取决于php-fpm的配置,二选一即可
-}
-
-# Main server
-#
-server {
-    listen       443 ssl http2;
-    server_name  www.xxxlbox.com;      # 你的网址
-    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;    # 开启HSTS
-
-    ssl on;
-    ssl_certificate fullchain.pem;     # 指定ssl证书路径
-    ssl_certificate_key privkey.pem;
-    ssl_dhparam dhparams.pem;
-    ssl_session_cache    shared:SSL:15m;
-    ssl_session_timeout  30m;
-    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
-    ssl_ciphers   ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
-    ssl_prefer_server_ciphers  on;
-
-    root   html/wordpress;     # 指定网站根目录
-    index  index.php index.html;
-
-    location / {
-        # This is cool because no php is touched for static content.
-        # include the "?$args" part so non-default permalinks doesn't break when using query string
-        try_files $uri $uri/ /index.php?$args?;
-    }
-
-    location ~ \.php$ {
-        # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
-        fastcgi_pass   php;
-        fastcgi_index  index.php;
-        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
-        include        fastcgi_params;
-    }
-
-    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
-        expires max;
-        log_not_found off;
-    }
-
-    location = /favicon.ico {
-	log_not_found off;
-	access_log off;
-    }
-
-    location = /robots.txt {
-        allow all;
-        log_not_found off;
-        access_log off;
-    }
-}
-```
-
-其中,`location / {}`里的`try_files`非常机智。网上很多教程都是在这里用了if判断加rewrite,就像这样:
-
-```nginx
-if (-f $request_filename/index.html) {
-    rewrite (.*) $1/index.html break;
-}
-if (-f $request_filename/index.php){
-    rewrite (.*) $1/index.php;
-}
-if (!-f $request_filename){
-    rewrite (.*) /index.php;
-}
-```
-
-这很类似Apache的.htaccess的写法,这样配置必然是可以正常访问的。然而,Nginx官方并不推荐使用if,请参见《[If Is Evil](https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/)》。
-
-`try_files`语句的作用就是按顺序检查文件或文件夹是否存在,返回第一个找到的文件或文件夹,如果所有的文件或文件夹都找不到,会进行一个内部重定向到最后一个参数。拿这里的`try_files $uri $uri/ /index.php?$args?`举个例子:当客户端请求`https://www.xxxlbox.com/post/2031`时,此时`uri$`就是`post/2031`(还是`/post/2031`?我不知道)。很明显,这是一个为了美观的“假”链接,网站目录下没有post这个文件夹,`$uri`和`$uri/`都是不存在的,所以请求会被重定向为`https://www.xxxlbox.com/index.php?$args?`。结果请求就被发送到php-fpm了,WordPress自己会判断请求的地址,因此就能显示正确的内容。另一个例子:当客户端请求`https://www.xxxlbox.com/wp-content/uploads/2017/10/img1.png`时,显然,此时$uri能找到,该png文件会直接被发送给客户端。由此可见,`try_files`能很好地支持WordPress的自定义固定链接功能,同时避免了每次都进行if判断,十分高效,推荐使用。
-
-## 301跳转,强制https访问
-
-```nginx
-# Redirect non-www to www
-#
-server {
-    listen       80;
-    listen       443 ssl http2;
-    server_name  xxxlbox.com;
-    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
-
-    ssl_certificate 1_xxxlbox.com_bundle.crt;
-    ssl_certificate_key 2_xxxlbox.com.key;
-    ssl_dhparam dhparams.pem;
-
-    return 301 https://www.xxxlbox.com$request_uri;
-}
-
-# Redirect http to https
-#
-server {
-    listen       80;
-    server_name  www.xxxlbox.com;
-
-    return 301 https://www.xxxlbox.com$request_uri;
-}
-```
-
-在网上搜索“Nginx 301跳转”,很多地方都是这么做的:
-
-```nginx
-server {
-    listen       80;
-    server_name  www.example.org  example.org;
-    if ($http_host = example.org) {
-        rewrite  (.*)  http://www.example.org$1;
-}
-```
-
-Nginx官方文档上是这么写的,强烈建议大家去看看这一页:
-
-> This is a wrong, cumbersome, and ineffective way. The right way is to define a separate server for `example.org`
->
-> <cite>[Converting rewrite rules](http://nginx.org/en/docs/http/converting_rewrite_rules.html)</cite>
-
-这里使用的是`return 301`,也是新版Nginx推荐的用法。
-
-## WP Super Cache
-
-Apache下,WP Super Cache可以自己生成rewrite规则并写入`.htaccess`文件中,而Nginx没有这样的机制,因此rewrite规则需要自己配置。这个规则可以直接放入`server`块中。
-
-```nginx
-# WP Super Cache rules.
-#
-set $cache_uri $request_uri;
-
-# POST requests and urls with a query string should always go to PHP
-if ($request_method = POST) {
-    set $cache_uri 'null cache';
-}
-
-if ($query_string != "") {
-    set $cache_uri 'null cache';
-}
-
-# Don't cache uris containing the following segments
-if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
-    set $cache_uri 'null cache';
-}
-
-# Don't use the cache for logged in users or recent commenters
-if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
-    set $cache_uri 'null cache';
-}
-```
-
-此时你的`location / {}`块中`try_files $uri $uri/ /index.php?$args?`应加上WP Super Cache的路径,即:
-
-```nginx
-location / {
-    try_files /wp-content/cache/supercache/$http_host/$cache_uri/index-https.html $uri $uri/ /index.php?$args?;
-}
-```
-
-当然如果你的不是https站点,应稍作修改:
-
-```nginx
-location / {
-    try_files /wp-content/cache/supercache/$http_host/$cache_uri/index-http.html $uri $uri/ /index.php?$args?;
-}
-```
-
-把WP Super Cache设置为Mod_rewrite模式,这样的话,借助WP Super Cache生成静态html文件,当条件符合时,Nginx可以直接把这些静态文件发送给用户,完全绕过php,实现全站伪静态。
-
-另外,WordPress上还有一个很有名的缓存插件叫W3 Total Cache,它的Nginx规则在WordPress文档里也能找到:https://codex.wordpress.org/Nginx#W3_Total_Cache_Rules
-
-## 一些其他问题
-
-我们知道WordPress能上传文件的最大体积是由php.ini的配置决定的,然而除此之外,Nginx对文件的上传大小也有限制(默认好像是2MB),超过这个大小WordPress会报http错误。因此nginx.conf的`http`块中需加一句`client_max_body_size  64m;`(改成你想要的大小)。另外,别忘了开启gzip压缩,`gzip on;`。
-
-使用`nginx -t`命令可以测试nginx.conf的语法是否正确。
-
-暂时就说这么多吧,有什么其他东西以后再慢慢添加。并非专业人士,有问题欢迎指出。
-
-个人感觉Nginx的配置文件比Apache的简洁多了,写Nginx的配置文件就跟写作文一样,每一行的意思都很清楚,非常接近英文语句,可读性很高。
-
-我的Nginx配置主要参考自:
-
-* https://codex.wordpress.org/Nginx
-* https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/
-* 关于Nginx的配置常见错误,官方吐槽:[Pitfalls and Common Mistakes](https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/)

+ 0 - 218
content/posts/2018/compile-nginx-tls1.3.md

@@ -1,218 +0,0 @@
----
-title: "编译升级Nginx尝鲜TLS1.3"
-date: 2018-07-31T17:13:03+08:00
-draft: false
-toc: true
-tags:
-  - 折腾
-  - Nginx
----
-
-## 从PCI DSS说起
-
-PCI DSS,全称Payment Card Industry Data Security Standard,第三方支付行业(支付卡行业)数据安全标准,是由PCI安全标准委员会制定,力在使国际上采用一致的数据安全措施。 早在去年,PCI安全标准委员会就为TLS 1.0设定了最后期限——2018年6月30日,也就是说自2018年6月30日起,网站将需要停止支持TLS 1.0协议才能实现PCI合规。 虽然我这博客跟支付行业并没有什么关系,但是考虑到网站上有大量的CSS3、ES6代码,那些老旧的浏览器就算能连上,又能有多好的用户体验呢,于是我果断去掉了TLS 1.0和1.1的支持。
-
-事实上,TLS 1.0发布于1999年,至今将近20年,该版本协议有各种已知漏洞,易遭受BEAST、POODLE等攻击。现如今最流行的TLS版本毫无疑问是1.2,而且,支持TLS 1.1的浏览器一般都支持1.2,这也是我同时去掉TLS 1.1支持,仅保留1.2版本的原因了。TLS 1.2发布于2008年,是服役时间最长的一个版本,整整10年,TLS协议都没有更新过。要知道TLS协议跟HTTP可不能比啊,HTTP可以10年不更新,TLS不行。HTTP设计之初就几乎没有考虑到安全问题,正因为如此才有SSL和后来的TLS,所以才有HTTPS嘛。TLS是HTTP下面的一个安全层,跟安全有关的东西,就有潜在的漏洞,发现漏洞就得打补丁。与其修修补补,不如出个干净的新版。
-
-TLS 1.3从2014年开始准备到现在,终于快要发布了。要说新版的亮点,除了安全性提高之外,更让大家兴奋的是速度与性能的提升。TLS 1.3增加了新的握手模式,建立连接的速度更快,而且还支持0-RTT的特性。关于TLS 1.3的技术特性以及跟旧版的区别,这里就不多说了,网上文章多的是,总之,TLS 1.3好处有很多就是了……
-
-如今,像Cloudflare、又拍云等CDN都纷纷支持了TLS 1.3,谷歌首页也用上了,我自己何尝不想体验一番,可我用着Nginx官方维护的软件源,实在是太舒服,根本就懒得重新编译安装。然而就在几天前,我一不小心`rm -rf`了服务器的上的`/usr/local/bin`及`/usr/local/lib`文件夹,虽然不是什么关键位置,并没有造成严重的后果,但是强迫症还是决定重装个系统吧,重新编译Nginx,试一下 TLS 1.3,再顺带加上Brotli压缩算法的支持以及对Certificate Transparency的支持。
-
-## TLS 1.3的现状
-
-虽然已经有很多网站用上了TLS 1.3,但是TLS 1.3标准并没有正式发布。目前最新草案是Draft 28。从[https://github.com/tlswg/tls13-spec/releases](https://github.com/tlswg/tls13-spec/releases)上可以看到,Draft 28发布后好几个月都没有再发新版本了,所以我猜应该是差不多了。Nginx从1.13开始支持`TLSv1.3`的选项,然而能否成功开启TLS 1.3还取决于编译Nginx时所用OpenSSL的版本。OpenSSL 1.1.1才能支持TLS 1.3,现在还是预览版,而且[OpenSSL的官方Wiki](https://wiki.openssl.org/index.php/TLS1.3)上写得很清楚:
-
-> OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. 
-
-一般的Linux发行版自带的OpenSSL肯定不可能是预发行版的,Nginx官方的软件源也肯定不会用预发行版的OpenSSL来编译,所以基本上只要你的Nginx用的是包管理器安装的,即使你用着1.14这样的版本,也是无法成功开启TLS 1.3的。(使用`nginx -V`命令即可查看Nginx所用的OpenSSL版本。)现阶段只能在编译Nginx时用`--with-openssl=/path/to/openssl `手动指定OpenSSL的源码位置来达到支持TLS 1.3的目的。
-
-再说说客户端这边。从Chrome 65开始,Chrome会默认开启并使用TLS 1.3 Draft 23,最新的Chrome 68则添加了Draft 28支持,在Chrome的试验性功能下可手动开启。Mozilla提供了一个TLS 1.3 Draft 28的测试服务器:[https://tls13.crypto.mozilla.org/](https://tls13.crypto.mozilla.org/),如果你的浏览器能打开就说明支持最新的Draft 28。很重要的一点是,服务端与客户端支持的Draft版本必须一致,不然就会握手失败。最新的[OpenSSL_1_1_1-pre8](https://github.com/openssl/openssl/releases/tag/OpenSSL_1_1_1-pre8)支持26、27以及28版本,并不支持现在浏览器支持更普遍的Draft 23等版本,关于这个问题已经有补丁出来了,可以让OpenSSL支持旧的Draft版本。不过我只是想简单体验一下TLS 1.3,而且浏览器总会更新的,所以就不打这个补丁了……
-
-**更新**:TLSv1.3已于8月10日正式发布。Welcome, [RFC 8446](https://tools.ietf.org/html/rfc8446).
-
-## 编译安装Nginx的过程
-
-我编译安装Nginx的过程基本就是按着[屈屈大佬的这篇文章](https://imququ.com/post/enable-tls-1-3.html)来的。屈哥这篇文章最后更新时间还是去年,那时OpenSSL还没有出1.1.1的预览版,只是在GitHub仓库中有一个draft-18分支,有些细节还是不一样的,所以我还是这里简单记录一下我的编译安装过程。
-
-我的系统是Debian 9 Stretch 64位,并且是root用户,一些命令可能需要根据情况调整了哦。
-
-### 安装系统依赖
-
-```bash
-apt update
-apt install build-essential libpcre3 libpcre3-dev zlib1g-dev git
-```
-
-### 获取依赖&组件
-
-#### OpenSSL
-
-```bash
-wget https://github.com/openssl/openssl/archive/OpenSSL_1_1_1-pre8.tar.gz
-tar -zxf OpenSSL_1_1_1-pre8.tar.gz
-```
-
-#### ngx_brotli
-
-谷歌开发的压缩算法,压缩率比gzip高。
-
-```bash
-git clone https://github.com/google/ngx_brotli.git
-cd ngx_brotli
-git submodule update --init
-cd ../
-```
-
-#### nginx-ct
-
-使Nginx支持证书透明(Certificate Transparency)功能。
-
-```bash
-wget https://github.com/grahamedgecombe/nginx-ct/archive/v1.3.2.tar.gz
-tar -zxf v1.3.2.tar.gz
-```
-
-### 编译并安装Nginx
-
-我安装的是最新的主线版1.15.2,编译参数是在Nginx官方软件源中的编译参数的基础上改动而成,值得注意的是:
-
-* 并没有自定义安装位置,因此默认会被安装到`/usl/local/nginx/`目录下。即:
-  * 二进制位置`/usl/local/nginx/sbin/nginx`;
-  * 配置文件位置`/usl/local/nginx/conf/nginx.conf;`
-  * 网页根目录`/usl/local/nginx/html/`;
-  * 总之,日志、缓存、动态模块都在`/usl/local/nginx/`下……
-* 指定的运行用户和用户组分别是nobody和nogroup。
-* nginx-ct的编译使用了Nginx的动态模块特性。
-
-```bash
-wget http://nginx.org/download/nginx-1.15.2.tar.gz
-tar -zxf nginx-1.15.2.tar.gz
-cd nginx-1.15.2
-./configure --add-module=../ngx_brotli --add-dynamic-module=../nginx-ct-1.3.2 --with-openssl=../openssl-OpenSSL_1_1_1-pre8 --user=nobody --group=nogroup --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module
-make
-make install
-```
-
-这样一来,Nginx就安装完成了,但是为了方便,我们可以建一个软连接:
-
-```bash
-ln -s /usr/local/nginx/sbin/nginx /usr/local/bin/nginx
-```
-
-这样就可以直接用`nginx`命令来管理服务了。然而这还不够,我们还要一个启动脚本。`nano /etc/init.d/nginx`,写入以下内容:
-
-```bash
-#! /bin/sh
-
-### BEGIN INIT INFO
-# Provides:          nginx
-# Required-Start:    $all
-# Required-Stop:     $all
-# Default-Start:     2 3 4 5
-# Default-Stop:      0 1 6
-# Short-Description: starts the nginx web server
-# Description:       starts nginx using start-stop-daemon
-### END INIT INFO
-
-PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
-DAEMON=/usr/local/nginx/sbin/nginx
-NAME=nginx
-DESC=nginx
-
-test -x $DAEMON || exit 0
-
-# Include nginx defaults if available
-if [ -f /etc/default/nginx ] ; then
-  . /etc/default/nginx
-fi
-
-set -e
-
-. /lib/lsb/init-functions
-
-case "$1" in
-  start)
-    echo -n "Starting $DESC: "
-    start-stop-daemon --start --quiet --pidfile /usr/local/nginx/logs/$NAME.pid \
-        --exec $DAEMON -- $DAEMON_OPTS || true
-    echo "$NAME."
-    ;;
-  stop)
-    echo -n "Stopping $DESC: "
-    start-stop-daemon --stop --quiet --pidfile /usr/local/nginx/logs/$NAME.pid \
-        --exec $DAEMON || true
-    echo "$NAME."
-    ;;
-  restart|force-reload)
-    echo -n "Restarting $DESC: "
-    start-stop-daemon --stop --quiet --pidfile \
-        /usr/local/nginx/logs/$NAME.pid --exec $DAEMON || true
-    sleep 1
-    start-stop-daemon --start --quiet --pidfile \
-        /usr/local/nginx/logs/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS || true
-    echo "$NAME."
-    ;;
-  reload)
-    echo -n "Reloading $DESC configuration: "
-    start-stop-daemon --stop --signal HUP --quiet --pidfile /usr/local/nginx/logs/$NAME.pid \
-        --exec $DAEMON || true
-    echo "$NAME."
-    ;;
-  status)
-    status_of_proc -p /usr/local/nginx/logs/$NAME.pid "$DAEMON" nginx && exit 0 || exit $?
-    ;;
-  *)
-    N=/etc/init.d/$NAME
-    echo "Usage: $N {start|stop|restart|reload|force-reload|status}" >&2
-    exit 1
-    ;;
-esac
-
-exit 0
-```
-
-保存后添加执行权限,并设置Nginx为开机启动:
-
-```bash
-chmod a+x /etc/init.d/nginx
-update-rc.d -f nginx defaults
-```
-
-然后就可以用`service nginx start|stop|restart|reload `等命令愉快地操作Nginx了。
-
-### Nginx的配置
-
-#### SSL相关
-
-```nginx
-ssl_protocols TLSv1.2 TLSv1.3;
-ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5;
-ssl_prefer_server_ciphers on;
-```
-
-要注意从1.15.0开始,`ssl on|off`这个选项已经废弃,现只需在`listen`选项中带上`ssl`即可,即`listen 443 ssl http2`。
-
-#### ngx_brotli相关
-
-这里有很多选项可以调整,但是我基本都用默认了。
-
-```nginx
-gzip         on;
-gzip_vary    on;
-gzip_types   text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;
-
-brotli       on;
-brotli_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;
-```
-
-## 感受效果
-
-由于现在几乎没有默认支持TLS 1.3 Draft 28的浏览器,所以现阶段用户访问本站基本上还是会用TLS 1.2。如果你用的是Chrome 68,现在就可以在地址栏中输入`chrome://flags/#tls13-variant`开启Draft 28体验一番。目前手机版Chrome还没更新,暂不支持Draft 28,而我又不想装金丝雀版,所以还在坐等中。我自己在PC版Chrome中的感觉是几乎没什么区别,可能是请求数少,本来就很快了吧……F12 Security选项卡下效果:
-
-![Chrome 68测试结果](https://assets.xxxlbox.com/images/2018/img024.png)
-
-贴一下[SSL Labs的检测结果](https://www.ssllabs.com/ssltest/analyze.html?d=www.xxxlbox.com),“Protocol Support”一项终于是满分了:
-
-![SSL Labs测试结果](https://assets.xxxlbox.com/images/2018/img025.png)
-
-突然发现,即将发布的TLSv1.3加上2015年定稿的HTTP/2,这两个组合起来简直就是加强版的https啊!那些说https慢的人也该醒醒了吧。

+ 0 - 68
content/posts/2018/hello-hugo.md

@@ -1,68 +0,0 @@
----
-title: "Hello Hugo"
-date: 2018-05-07T22:24:24+08:00
-draft: false
-toc: true
-tags: 
-  - Hugo
-  - 折腾
----
-
-新站终于做好了。
-
-几天前我在《[关于本站的未来](https://www.xxxlbox.com/posts/2018/whats-next-about-this-site/)》一文中详细阐述了我从WordPress换到静态博客系统Hugo的原因,这里不再赘述。简单总结下目前博客迁移的情况:
-
-* 文章只保留了一部分,一些没有很大意义的就删掉了,保留了共11篇文章;
-* 评论全部丢失;
-* “友链”与“关于”页面的重写还在进行中。
-
-~~关于新站的架构、工作原理、技术细节等话题我们以后会详细讨论。这周有两个考试,等有时间了,我再更新这篇文章……~~
-
-考完了。
-
-## 代码
-
-先来聊聊新站代码相关或者说跟这个Hugo主题相关的话题吧。这个主题目前是自用主题,很多地方都写死了,而且代码比较粗糙,还有一堆bug,因此暂时不会开源。Hugo在中文博客圈里并不是特别火,用的人较少,主题什么的也是挺少的,我是很愿意为社区作贡献的,所以以后等代码拿得出手了我一定会把它丢到GitHub上的。
-
-设计灵感来自Hugo主题“[Sam](https://github.com/hivickylai/hugo-theme-sam)”。看到这个主题的第一眼就被Get到了。文章页,从上到下,映入眼帘的是文章的标题,而不是Header里的站点标题,舒服。排版上,字符与字符之间有一定的间距,不是挤到一起的,配上灰色背景,那叫一个优雅啊,Zhuangbility爆表。本来就打算用这个主题了,实际使用下来,细节问题还是挺多的,改也不好改了,索性就自己写一个,这才有了后面的故事。
-
-写一个Hugo主题可比WP主题容易多了。也就研究了几个主题的源码,对着文档看,几天就把HTML骨架写好了,加样式也比想象中的要顺利。第一次尝试在项目中使用Sass,安装node-sass时踩了不少坑,最后发现了Koala这个软件。Koala带了编译sass的环境,不用手动安装了,而且还带js压缩的功能,简直神器。这次为了实现底栏自动隐藏以及异步加载评论的功能,写了100多行js,最终效果还挺好的,我都有点不敢相信自己。
-
-主题依然走极简风,借鉴了Sam主题多处写得好的地方,包括一些页面布局和文字间距。配色并没有抄Sam主题,抄的是[Humble Bundle](https://www.humblebundle.com)的官网,配色什么的借鉴一下不犯法吧?在框架与库的使用上:
-
-* Normalize.css
-* 动画库[animate.css](https://daneden.github.io/animate.css/)
-* 图标库使用[Feather](http://feathericons.com/),轻量,风格也很搭。
-
-既然都用静态博客了,何不把加载速度优化到极致。animate.css特地用gulp自定义构建了,只取了几个需要的动画。借助sass,几个css被合并成一个文件,输出还是压缩的,最终css只有15KB,gzip压缩后只有4.5KB了。js也是做了压缩的,100行代码也就2KB,Feather图标并没有用那个js,而是直接将svg插到html文档中,减少了请求数,也避免了js动态插入svg到DOM时造成的图标显示延时。对了,还有字体,我并未使用任何网络字体,用的是“Trebuchet MS”。该字体绝大多数Windows PC和Mac均有安装,实测iOS也支持,就Android不支持,不过也无所谓,默认的Sans Serif字体也不丑。
-
-评论系统使用Valine,需要加载Leancloud的依赖库,100多KB,评论本身js体积也有70多KB。这要是跟页面同步加载,那我前面做的那些优化就……一夜回到解放前。所以我就开始学习js异步加载的操作了,由于整个项目并没有用jQuery,就不能用jQuery的`.getScript`方法了,最终我在Stackoverflow找到了原生js的替代方法:
-
-https://stackoverflow.com/questions/16839698/jquery-getscript-alternative-in-native-javascript
-
-于是就很爽了。js计算评论框相对页面顶部的像素距离,监听窗口滚动事件,获取滚动距离,与评论框位置对比,就可以判断评论框是否可见。可见,就开始用上面提供的这个loadScript函数加载并执行那两个js。而在页面加载时,就完全不用管这两个巨无霸,速度快得飞起。原先打算用InstantClick.js,现在看来不用了,已经很快了,而且instantclick.js与现有js的一堆兼容问题也不是那么好解决的。
-
-目前还有件事让我有点不舒服——百度统计。我的首页只有三个请求,gzip压缩后总体积也就8KB多,引入百度统计js后,直接多了3个请求,共有9KB,所以说页面体积直接就翻了一翻。难受,却没办法,也不知道Google Analytics怎么样。
-
-## 部署
-
-不太希望别人看到我的每一个Commit,就把源代码放在GitLab上了,私密仓库。腾讯云学生机还没到期,就暂时把博客部署到云服务器上。关于自动部署,这个就有的说了,大致过程是这样的:
-
-1. 将更改Push到GitLab;
-2. GitLab通过Webhook向服务器发送一个POST请求;
-3. 服务器上运行着一个Node.js小程序,监听该请求,收到POST请求后运行一个shell脚本;
-4. 脚本运行,先从GitLab上拉取最新的代码,然后Hugo构建页面,构建的HTML等文件直接放到Nginx网页根目录中,部署完成。🎉
-
-所以本地写完文章,Commit提交后,Push到GitLab,等几秒钟,再打开网站,刚写的文章已经出来了,舒服。为了防止那个js小脚本被杀掉,特地用pm2来管理进程,还可以实现脚本的开机启动。
-
-这样写博客,体验已经很好了,我很满足。但是为了应急,我还是搞了一个可以在线编辑文章的管理“后台”。由于Netlify CMS暂时还不支持GitLab,于是我就用了Forestry.io。
-
-![Forestry.io CMS](https://assets.xxxlbox.com/images/2018/img023.png)
-
-这个“后台”本质上是一个单页应用(SPA),它能与Forestry.io的后端API进行通信,在这里编辑好文章后,点击发布,Forestry.io会自动Commit并Push到GitLab,然后自动部署过程就开始了,美滋滋。事实上Forestry.io也带有自动构建并部署的功能,除了支持GitHub Pages、Amazon S3等静态文件托管之外,还支持FTP/SFTP。
-
-那些说静态博客不好管理的,怎么样,涨姿势了吧。
-
-写的有点乱啊,基本上是想到哪写到哪,就说这么多吧,以后说不定会写个详细点的Hugo博客部署指南……
-
-**更新**:利用DNSPod智能解析,国内访客自动解析到腾讯云服务器,国外访客解析到Netlify全球CDN。

+ 0 - 169
content/posts/2018/hugo-deployment-webhook.md

@@ -1,169 +0,0 @@
----
-title: "Hugo利用Webhook实现自动部署"
-date: 2018-06-02T14:19:05+08:00
-draft: false
-toc: true
-tags: 
-  - Hugo
-  - GitLab
----
-
-既然是静态博客,部署可不就很简单嘛,本地电脑上用`hugo`命令生成静态文件,然后FTP上传到服务器不就行了?这是最直接的方法,但实在是有点麻烦,更重要的是,这一点也不geek。都8102年了,谁还用FTP啊,大家都在用Git好不好!这里我就简单记录一下利用GitLab提供的Webhook来实现Hugo在VPS上自动部署的方法。
-
-## 前提
-
-本文记录的方法适用于有shell访问的云服务器或VPS上的部署,对于使用GitHub Pages或用Netlify部署的同学们,你们根本就不用这么折腾。用各类Pages服务的直接本地生成然后Push到Git仓库就行,或者搞个CI自动构建;Netlify就不用多说,绑定账号,选定好Git Repo和分支就不用操心了,一切都是全自动的。
-
-关于怎么搭建并配置Hugo站点这里就不做讨论,这篇文章默认你已经在本地安装好了环境,搭好了Hugo站点,并且,你已经把源放到远程Git代码托管了,我本人用的是GitLab,后面也是以GitLab为例,当然,跟GitHub大同小异。
-
-另外,我服务器的系统是Debian 9,其他Linux发行版应该也是大同小异的。并且,以下操作我都是以root身份,如果你用非root账户,出现权限问题记得加`sudo`哦。
-
-## 原理
-
-我在上一篇文章《[Hello Hugo](https://www.xxxlbox.com/posts/2018/hello-hugo/)》中已经说过了,就是更改Push到GitLab,GitLab发送一个POST请求到服务器,服务器上一个Node.js脚本监听请求,收到请求就运行一个shell脚本自动拉取最新代码并构建。废话不多说了,开始吧……
-
-## 操作
-
-###  配置环境
-
-#### Git
-
-安装Git,这个不用多说了吧:
-
-```bash
-apt update
-apt install git
-```
-
-#### Hugo
-
-在Linux上安装Hugo大概有三种方法:
-
-1. 从系统源安装,这种方法安装更新方便,缺点是版本很低,低到生成页面时都会报错,所以不推荐。
-2. 使用snap。安装snap,然后`snap install hugo`,优点是安装更新方便、版本新,然而,如果你是国内的服务器,下载速度可能会慢到你怀疑人生。是否用该方法完全取决于你的服务器的下载速度和你的忍耐度。
-3. 直接去[Hugo Releases](https://github.com/gohugoio/hugo/releases)上找最新的release,官方提供了各个平台的二进制文件,还提供了deb格式的封装,Debian类系统可以直接用`dpkg`来安装,其他Linux发行版下载二进制拷到`/usr/local/bin`文件夹中即可使用。
-
-我用的就是第三种方法,以安装最新的0.41(64位)为例:
-
-```bash
-wget https://github.com/gohugoio/hugo/releases/download/v0.41/hugo_0.41_Linux-64bit.tar.gz
-tar -zxvf hugo_0.41_Linux-64bit.tar.gz
-cp hugo /usr/local/bin/hugo
-```
-
-然后运行一下`hugo version`,出现类似信息就表示安装成功了:
-
-```
-Hugo Static Site Generator v0.41 linux/amd64 BuildDate: 2018-05-25T16:57:20Z
-```
-
-#### Node.js
-
-这个我就不多说了,直接去https://nodejs.org/en/download/ ,有多种安装方式,总有一个适合你。
-
-### 配置服务器上的Git仓库
-
-源码放在GitLab上,为了能在服务器构建,我们需要在服务器上克隆一份。`git clone`提供ssh和https两种方式,我这里还是推荐用ssh来连接,因为https说不定什么时候就要你重新输入账号密码了,这样一来自动部署就卡住了。用ssh要先添加ssh key,GitLab添加ssh key的详细方法请看这里:[GitLab and SSH keys](https://gitlab.com/help/ssh/README),这里不做过多介绍。配置好ssh key以后,以我的GitLab仓库为例:
-
-```bash
-git clone git@gitlab.com:Track3/my-hugo-blog.git
-cd my-hugo-blog
-hugo -d /usr/share/nginx/html/blog/
-```
-
-第一次连接GitLab要确认信息,以后就不用了。后面的`/usr/share/nginx/html/blog/`是我的Nginx文档根目录,也就是生成的静态文件输出目录。
-
-### 配置脚本
-
-新建一个文件夹,先把hugo的自动构建脚本写好。
-
-```bash
-mkdir webhook
-cd webhook
-nano hugo-deploy.sh
-```
-
-`hugo-deploy.sh`中写入以下内容并保存:
-
-```bash
-#!/bin/bash
-
-cd ~/my-hugo-blog
-git pull origin master
-hugo -d /usr/share/nginx/html/blog/
-exit 0
-```
-
-很简单的bash脚本,其中`~/my-hugo-blog`是你的Git仓库也就是网站源码的路径。别忘了添加执行权限:
-
-```bash
-chmod +x hugo-deploy.sh
-```
-
-然后,我们就要用到Node.js来监听GitLab那边发送过来的请求了。用了[gitlab-webhook-handler](https://github.com/SixQuant/gitlab-webhook-handler)这个中间件:
-
-```bash
-npm install gitlab-webhook-handler --save
-```
-
-然后创建一个`gitlab-webhook.js`,写入以下内容并保存:
-
-```javascript
-var http = require('http')
-var exec = require('child_process').exec
-var createHandler = require('gitlab-webhook-handler')
-var handler = createHandler({ path: '/webhook-123456' })
-
-http.createServer(function (req, res) {
-  handler(req, res, function (err) {
-    res.statusCode = 404
-    res.end('no such location')
-  })
-}).listen(7777)
-
-console.log("Gitlab Hook Server running at http://0.0.0.0:7777/webhook-123456");
-
-handler.on('error', function (err) {
-  	console.error('Error:', err.message)
-})
-
-handler.on('push', function (event) {
-    let currentTime = new Date();
-    console.log('\n--> ' + currentTime.toLocaleString());
-    console.log('Received a push event for %s to %s', event.payload.repository.name, event.payload.ref);
-    exec('sh ./hugo-deploy.sh', function (error, stdout, stderr) {
-        if(error) {
-            console.error('error:\n' + error);
-            return;
-        }
-        console.log('stdout:\n' + stdout);
-        console.log('stderr:\n' + stderr);
-    });
-})
-```
-
-这个脚本主要是来自[gitlab-webhook-handler](https://github.com/SixQuant/gitlab-webhook-handler)的README,我自己改了一下,加了日期输出。利用的是Node.js的`child_process`模块来执行shell脚本。上面的`path: '/webhook-123456'`你可以任意设置,由于没有设置secret_key验证,所以这里的`webhook-123456`就相当于是密码了,以让该路径不至于那么明显。端口用的是`7777`,你可以随意设置,总之不要过于明显。这样下来最终的监听地址就是`http://0.0.0.0:7777/webhook-123456`了,`0.0.0.0`表示该http服务监听本机的所有ip上收到的请求,说白了就是`0.0.0.0`可以换成服务器的ip或者指向服务器的所有域名。拿我自己的服务器作例子就是`http://xxxlbox.com:7777/webhook-123456`。
-
-然后,我们要运行这个脚本:
-
-```bash
-node gitlab-webhook.js
-```
-
-现在我们只要告诉GitLab,当有Push的时候,向`http://xxxlbox.com:7777/webhook-123456`发送一个POST请求。于是我们要设置一下GitLab。
-
-### 配置GitLab Webhook
-
-进入你的项目主页,在左边侧栏里选择“Settings”,然后选择“Integrations”,“URL”一栏里填入你的监听地址,“Secret Token”留空,“Trigger”选择“Push events”就行了。添加Webhook后,下边可以发送测试,可以测试脚本是否工作正常。
-
-### 使用pm2管理Node.js进程
-
-pm2是一个很好用的Node应用的进程管理器,具有守护进程,监控,日志等一整套完整的功能,用它可以非常方便地启动、重启Node应用,并且可以实现Node应用的开机启动。用npm安装pm2:
-
-```bash
-npm install pm2@latest -g
-```
-
-前面出于测试目的,我们直接运行了`gitlab-webhook.js`这个脚本,所以要先按`Ctrl-C`退出,然后用pm2来启动:`pm2 start gitlab-webhook.js`,使用`pm2 startup`命令来设置脚本开机启动。pm2的更多高级用法还请查看[文档](http://pm2.keymetrics.io/docs/usage/quick-start/)。
-
-这样一来,Hugo的自动部署就配置好了,不管是在本地写文章,还是使用Headless CMS,最终只要Commit提交并Push,你的网站就会自动更新,还是很<ruby>方<rp>(</rp><rt>zhuāng</rt><rp>)</rp></ruby><ruby>便<rp>(</rp><rt>bī</rt><rp>)</rp></ruby>的。

+ 0 - 50
content/posts/2018/hugo-theme-hermit.md

@@ -1,50 +0,0 @@
----
-title: "一个Hugo主题:Hermit"
-date: 2018-11-27T14:49:11+08:00
-draft: false
-tags:
-  - Hugo
-  - 折腾
----
-
-从WordPress换到Hugo,深深感到Hugo在国内的流行度很低,远不如Hexo。之前,在Hugo主题库中实在是找不到满意的主题,于是我一头扎到文档中,写了这个主题。很想为Hugo官方主题库贡献一些东西,无奈自己还是比较菜,一些问题只能慢慢解决。经过自己近5个月的使用、改进,该主题一些较明显的Bug已被修复,最近我抽了点时间,把原来写死了的代码改成了可在配置文件中方便调整的变量,主题终于是拿得出手了。
-
-可以说这是我第一个准备认真去做的开源项目了。小心翼翼地写好Readme,按照官方主题库的要求修改,使用脚本测试完成后,我鼓起勇气向官方主题库发了一个[Issue](https://github.com/gohugoio/hugoThemes/issues/453),指向我的项目地址。经历了大概一个多月的等待,主题终于在出现在了官方主题站中。
-
-* Hugo官方主题站主页:https://themes.gohugo.io/hermit/
-* GitHub项目地址:https://github.com/Track3/hermit
-* 演示:https://hugo-theme-hermit.netlify.com
-
-在《[Hello Hugo](/posts/2018/hello-hugo)》这篇文章中我们已经聊了不少关于这个主题的话题,所以这里我就简单总结一下,列一下主要特点:
-
-* 内容至上,注重文字排版,单栏布局,功能及导航均位于可自动隐藏的底栏上;
-* 至简,无第三方框架,使用Hugo Pipes[^1],最终打包压缩的css文件<20KB;
-* 文章列表页采用按年分组、以日期排列的形式,类似于书籍目录;
-* 支持文章特色图片,以背景图显示[^2];
-* 响应式设计,矢量图标。
-
-![Hermit](https://assets.xxxlbox.com/images/2018/img026.png)
-
-主题的使用方法及配置,项目Readme里都有说明,不过是用英文写的,所以我这里还是简单说明一下。 
-
-首先是主题的安装。你可以直接将主题clone到`theme/hermit`目录下,或者,如果你的Hugo站点已经是一个Git仓库了,可以考虑将主题安装为一个submodule,这样更新起来会方便一点。当然,你也可以直接下载zip压缩包手动安装。
-
-然后,复制主题的`exampleSite`目录里的`config.toml`到Hugo的根目录中。请根据自己的需求修改配置,配置文件中有一定的说明,应该很容易理解。关于网站的favicon图标,建议使用[RealFaviconGenerator](https://realfavicongenerator.net/)这个在线工具来生成。主题的社交图标都来自Feather Icons,所以就没有国内的社交媒体的图标了,目前仅支持[这些](https://github.com/Track3/hermit#social-icons)。当然,图标都是保存在`layouts/partials/svg.html`中的独立svg,可以非常方便地添加、更换。
-
-主题对待内容分两种,`posts`文件夹内的内容会被当作所谓的“博客文章”来看待,`posts`之外的则会以“页面”来渲染。使用`hugo new posts/hello-world.md`命令可以生成一个标题为“Hello World”的文章,`hugo new hello-world.md`则会生成一个标题为“Hello World”的页面。
-
-值得注意的是本站目前正在使用的主题并不完全就是Hermit主题,Hermit主题是本站代码修改得到的。当然,页面设计什么的都一样,而且,本站的所有源代码都可以在GitHub上找到[^3]。精力所限,我在短时间内应该不会换主题了,所以这个项目会长期维护下去,以我自己的设想以及GitHub上Issue里的建议来看,这个主题接下来要做的大概有:
-
-* [ ] 点击底栏空白处返回顶部,或者加一个返回顶部按钮;
-* [x] 文章目录TOC;
-* [ ] 底栏中加入搜索;
-* [x] i18n支持,让主题中的字符串可翻译;
-* [ ] 标签页模板(即“tags”页面);
-
-这些只是设想,不保证都能实现,当然欢迎各种形式的Pull Request。
-
-截至本文章发布时,项目已经收到了11颗Star,作为一只萌新,还是很受鼓舞的,尤其是考虑到主题除了被Hugo官方Twitter推广过之外几乎没有任何宣传。说实话,我严重怀疑带有如此强烈个人喜好的主题会有人真正拿去使用,更多希望的是能够抛砖引玉,提供一种思路和参考吧。
-
-[^1]: https://gohugo.io/hugo-pipes/
-[^2]: 演示效果见 https://hugo-theme-hermit.netlify.com/posts/post-with-featured-image/
-[^3]: https://github.com/Track3/blog

+ 0 - 58
content/posts/2018/lets-encrypt-wildcard-cert.md

@@ -1,58 +0,0 @@
----
-title: "Let's Encrypt终于支持泛域名证书了"
-date: 2018-03-14T23:51:28+08:00
-draft: false
-toc: true
-tags:
-  - 折腾
----
-
-经历两个多月的测试以及两个多星期的延期,Let's Encrypt的ACME v2 API终于正式开放了。我也在第一时间换上了Wildcard野卡证书。
-
-这里简单记录一下用[acme.sh](https://github.com/Neilpang/acme.sh)获取Wildcard证书的方法。
-
-## 安装
-
-我的腾讯云机器用curl下载不下来,因此我直接`git clone`整个库:
-
-```bash
-git clone https://github.com/Neilpang/acme.sh.git
-cd ./acme.sh
-./acme.sh --install
-```
-
-## 生成证书
-
-ACME v2只支持DNS模式颁发证书,即通过在域名上添加一条txt解析记录来验证域名所有权。acme.sh强大的地方在于支持40多种域名解析商的api,像国内常用的腾讯云dnspod、阿里云dns、cloudxns等都支持,这里是完整列表:https://github.com/Neilpang/acme.sh#currently-acmesh-supports。
-
-如果你的DNS服务商在支持之列,就不用手动添加txt记录了。这里以dnspod为例, 首先先登录到[dnspod](https://www.dnspod.cn/)(dnspod已被腾讯收购,账号体系也并入了腾讯云),生成你的api id和api key。然后用`export`命令导入:
-
-```bash
-export DP_Id="your_id"
-export DP_Key="your_key"
-```
-
-然后就可以愉快地获取证书了:
-
-```bash
-./acme.sh  --issue  -d example.com  -d *.example.com  --dns dns_dp
-```
-
-不出意外的话,获取成功,证书会被放在`~/.acme.sh/`目录下。
-
-## 安装证书
-
-证书放在`~/.acme.sh/`目录下了,最好不要直接让Nginx/Apache读取这些证书文件,正确的方法是使用`--install-cert`命令将证书文件复制到Web Server对应目录下,一般是配置文件目录。我这里用的是Nginx:
-
-```bash
-./acme.sh --install-cert -d example.com \
---key-file       /etc/nginx/key.pem  \
---fullchain-file /etc/nginx/cert.pem \
---reloadcmd      "service nginx force-reload"
-```
-
-然后你需要手动修改Nginx的配置文件来安装证书以及key。
-
-值得一提的是,acme.sh支持自动更新证书。在你执行`./acme.sh --install`的时候就已经自动建立了cron job,每天0:00点会自动检测所有证书。获取并安装证书的命令会被记录下来,证书在60天以后会自动更新,Nginx配置文件目录下的证书也会同步更新,Nginx会重启——你无需任何操作。
-
-可以看到acme.sh获取Wildcard证书还是比较方便的。当然,acme.sh功能远不止如此,很多高级操作请看[acme.sh wiki](https://github.com/Neilpang/acme.sh/wiki/)。

+ 0 - 75
content/posts/2018/my-wp-theme-alchemist.md

@@ -1,75 +0,0 @@
----
-title: 本人首个原创主题——Alchemist
-date: 2018-02-27T19:56:25+08:00
-draft: false
-excerpt: 用WordPress有一年多了,我一直都用的是别人的主题。考虑了很长时间,终于下定决心要写一款主题。
-toc: true
-tags:
-  - 折腾
-  - WordPress
----
-
-刚接触圈子时,我是个不折不扣的小白,能把一台服务器装上LAMP环境、跑起WordPress,我都觉得很满足。当时连HTML都不会,自己写一个主题真的是想都不敢想。士别三日,当刮目相看,这一年多的时间,说起来真的很神奇,我对HTML、CSS、JavaScript以及PHP竟然都已略懂一二。
-
-大概是去年10月底的时候,我就着手准备这个主题了,之后的几个月,考试,实习,还有课程设计,忙得不可开交。更可怕的是,越忙,人就越懒。与此同时,我对于页面的设计布局一直是摇摆不定,再加上自己是新手,各种原因导致主题开发进度缓慢。放假后,我终于可以从玩游戏里挤出时间好好写写主题了……
-
-废话不多说,下面回到主题本身上来吧。
-
-## 名字、灵感及设计思路
-
-按照惯例,先说说名字。
-
-在放假回家的火车上,我终于决定看一下自己在Kindle上买了许久的小说——巴西作家保罗·戈埃罗的《炼金术士》(又名《牧羊少年的奇幻之旅》)。相信很多人都知道这个,人教版语文有节选的课文的。象征性很强的一部寓言,平淡简洁的语言中蕴含着深刻的人生哲理。当年语文课上我就很喜欢这部小说,现在看了完整的可以说更是被深深地震撼到了,于是我就把这个主题命名为“炼金术士”——"Alchemist"。
-
-关于页面的设计与风格上,“极简”是一开始就定下了的方向。多年前的iOS 7官方宣传片至今仍让我记忆犹新。视频前面Jony Ive说的那几句话感觉真是太有道理了:
-
-> I think there is a profound and enduring beauty in simplicity, in clarity, in efficiency. True simplicity is derived from so much more than just the absence of clutter and ornamentation, it's about bring order to complicity.
-
-复杂有了秩序就是简洁。在设计主题的时候,我在页面该显示那些内容以及页面布局逻辑层级等方面上都非常小心。来自Anders Norén的两个主题:[Hamilton](http://www.andersnoren.se/teman/hamilton-wordpress-theme/)与[McLuhan](http://www.andersnoren.se/teman/mcluhan-wordpress-theme/),以及我当时在用的主题:[Cover](http://eichefam.net/projects/cover/)都给了我很大的启发。
-
-首页的文章列表参考自McLuhan,文章模板以及页面模板参考Hamilton。第一次看到McLuhan的日期归档首页时,我就深深爱上了这种显示形式。进入首页就是个归档列表,干净整洁,一目了然,不会显示摘要,也不会显示属个分类啊有几条评论啊什么的,只能从标题揣测文章内容,给人一种神秘感,让人有点击进去的理由(标题党的福音)。当点击链接进入文章后,大标题与文章摘要映入眼帘,下面用字号较小、颜色较浅的一串文字显示的是文章所属分类以及评论数量。所属标签和文章发布日期被放到了正文的下面。特色图片也是支持的,而且会以更大的宽度显示(仅较大屏幕上)。可以说文章模板基本上完全照搬Hamilton的布局——好的设计就要虚心学习嘛,毕竟代码是自己的,没有照抄……
-
-Archive以及Search模板的设计参考Cover。所谓Archive模板就是按分类、标签或日期查询文章时显示的页面模板。我觉得在这个页面上如果把文章像首页那样按日期列表显示并不合理,所以用不同的设计还是有必要的。Cover主题这样就很好。
-
-小工具区域可控制隐藏的概念也来自Cover主题。对于WordPress的小工具,我是又爱又恨,它们很有用,但是我始终认为,作为一个注重内容至上的博客,它们很容易让读者分心,而且会失去单栏布局的优雅。这一点我是很认同Cover主题作者的观点的。小工具不应该一刀切砍掉,而是应该把它们隐藏起来,在需要的时候它们可以被呼出来。最终我决定做一个可隐藏的侧边栏。
-
-Alchemist主题的大致布局就是这样了,要说设计风格和排版,我的想法就是:去掉所有纯装饰用的图片,力求实现文字与线条最直接的美感。主色调就是黑白灰,再加上一点点个性的主题色。到时候也许会做一个自定义颜色的选项。
-
-## 实现与现实
-
-即使我已经会了一点PHP,很显然我也还没到能独立写一个WP主题的水平。主题能够做出来很大程度上要感谢Automattic的一个项目:[Underscores(_s)](https://underscores.me)。这是一个有着完整PHP代码以及一点点CSS的起始主题。有了这个起始主题,PHP不好的萌新们也可以更容易地制作出符合WordPress编码规范的主题。
-
-就算有了这个起始主题,作为新手,开发也是很艰难的。刚开始时,我基本都是把PHP源代码和最终HTML输出对着一行一行地看,外加查文档和百度,终于是把主题的每一个文件都差不多弄清楚了,之后基本上就是按着自己想法DIY了。
-
-当主题开发还没有动手的时候,我就告诉我自己:我要一个加载很快的主题。所以我一开始就是拒绝各种CSS框架的。另外,我是直接放弃较老浏览器的兼容性的。我在页面定位布局中使用了大量的Flexbox。`justify-content: space-between`这个属性真的太好用了!我几乎在所有的需要把两行放到同一行中,并且一个居左一个居右的地方用了这个。想到以前用`float + clearfix`都觉得害怕。
-
-Alchemist主题的侧边栏是花费时间最多的一块。js什么的倒是很简单,就是按钮点击事件触发,为侧边栏及主体添加对应的class就行了,CSS样式才是最麻烦的。我的想法是侧边栏可以滚动但是不能出现滚动条,因为页面还有一个滚动条,那样会有两个滚动条。在CodePen上找了很多例子,也在很多有侧边栏的网站上学了学,最终找到了一个让子元素比父元素宽度大16个像素,导致滚动条显示不出来的偏方。为了能让侧栏在小屏幕上以100%宽度显示,而且内容要居中,我真的是使尽了浑身解数。反正最终我摞了三层div。这个侧边栏真的已经到我的能力极限了,说实话,我尽力了。
-
-一直在纠结要不要用Font Awesome。Font Awesome用起来真的很方便,但是对于一个如此精简的主题而言有些臃肿了。我就只要十几个社交网站的图标和几个简单的图标按钮,却要加载一个包含近700个图标的webfonts!可是,我找不到合适的替代方案,只好妥协了。
-
-主题的排版、文字显示很大程度上是[typo.css](https://typo.sofi.sh/)的功劳。Underscores的style.css里已经自带了normalize.css,但是我个人认为normalize.css对中文显示并不友好。主题虽然用英语开发(为了实现translation ready),但是主要目标用户面向国内。于是,我就直接给换了,而且还DIY了一下,毕竟没有经过多个平台的测试,不知道会不会有什么Bug。反正最终的显示效果我个人还是比较满意的。
-
-就在前天,我把自己的生产站点换成了Alchemist主题,本来只是想换上试一下,看看效果就撤下来,没想到效果出乎我的意料。我的主题在Surface Pro 3的高分屏下的显示效果甩开我这段时间一直做开发用的台式机好几条街,文字渲染得太漂亮了!我当即决定不换回来了。然后,我突然发现主题的完成度已经有好高了,我想要的效果基本上已经达到了,同时为了方便后续开发,决定现在就把源代码放到Github上。主题采用GPL-2.0协议开源。
-
-https://github.com/Track3/alchemist
-
-此主题带有很严重的个人偏好,而且自定义的东西非常少,所以很难保证大家都可以接受。而且目前Alchemist主题处在开发初期,还是个半成品,代码相当不成熟,如果你不爱折腾,请避免在生产站点上使用!
-
-## 接下来怎么办
-
-优化,优化,还是优化。
-
-* 页面细节要优化:昨天在各种设备上看了下显示效果,发现有很多地方需要调整,内容的宽度、顶部的高度与页边距、缩进等等。准备为多种大小的屏幕调整一下页面布局,加一波媒体查询。
-* 代码要优化:CSS类名优化,PHP代码再规范一下,毕竟萌新,这方面肯定会犯不少错误。
-
-除了基本的优化以外,还有一些东西要加上。
-
-* 呼出侧边栏后可以点击任何空白处关闭侧栏。(必加)
-* 即时搜索建议,用WordPress REST API实现。在搜索框中输入时下面会给出搜索建议。(必加)
-* 简单的灯箱效果(看情况)
-* Editor Style(看情况)
-* 暂时只想到这些,慢慢添加……
-
-将来如果可行的话,我会把主题发布到wordpress.org上,到时候下载更新就都会很方便了。
-
-最后我想说,如果你喜欢这个主题,欢迎参与进来,提意见,反馈问题,发PR。现在这个阶段我不求Star,因为它还没准备好。

+ 0 - 74
content/posts/2018/whats-next-about-this-site.md

@@ -1,74 +0,0 @@
----
-title: 关于本站的未来
-date: 2018-05-01T16:55:29+08:00
-draft: false
-tags:
-  - Hugo
-  - JAMstack
-  - WordPress
----
-
-我想是时候放弃WordPress了。
-
-你可能想问,这两个月到底发生了什么,让一个之前还绞尽脑汁地写WordPress主题,用WordPress用得美滋滋的博主突然就要换博客系统?
-
-首先我想说,我对WordPress没有任何抱怨。很多人嫌它慢,我是不认同的,WordPress做一些基本的优化,速度就不慢,最起码像个人博客这种低流量站是不慢的。我目前的WordPress站禁用浏览器缓存的话基本可以在1s内完成Load,Finish的时间一般都在2s以内,有缓存的话会更快,站内页面跳转常常会有“秒开”的感觉。可以说做了伪静态之后,网络因素影响更大,由动态程序造成的延迟并不明显。你也许会说WordPress后台慢,这个我承认,后台肯定不如Typecho快,但是也不慢了。最近把MySQL升级到8.0,后台编辑文章等操作都明显快了很多,以前要等个一两秒才出现框架,现在也一闪就出来了,真的没什么好吐槽的。可能WordPress最受人诟病的就是它过于复杂臃肿了。WP早就不仅仅是一个博客系统,全球有30%的网站是用WP构建的,这其中有很多是各种CMS、商城甚至是论坛。WP的复杂,或者说强大,我在写一个简单的WP主题时就体会到了,它提供的函数非常多,REST API也很强大。然而,我还是不禁问自己,这些强大的功能,我真的都需要吗?
-
-我就想写个博客。
-
-不是说WP不好,是它功能太全面了,我用不上。WordPress曾今很适合我,现在却不是了。
-
-在刚开始做这个网站的时候,我也不清楚我要做什么样的站,可以说这一年半都是在摸索。我为什么隔三差五地换主题?除了喜新厌旧之外,更重要的原因就是我也不清楚我想要什么样的主题。折腾了这么多次,我明白了很多道理,更加明确了写博客的意义。
-
-这一年半的时间,我怎么变了这么多?现在看以前的文章,都觉得low得不行,忍不住把它们设成私密。曾经沉迷于折腾各种主题插件,如今都不再热衷;曾经到处留言换友链在各大论坛发帖,现在也渐渐少了;曾经有事没事各种大杂烩都往上发,如今发文章最起码都能带一点自己的思考;曾经对代码什么的不识一丁,如今也会一点Web开发和基本的服务器运维;曾经看到别人网站好酷炫,我都会问,woc,这什么主题啊,我也想换!如今,我会问,这怎么实现的?F12一下……
-
-这一年半的时间,我从刚上大学的Freshman萌新,变成了一只老油条。这期间我一直坚持写博客,虽然文章不多,质量也不高,但仍感觉自己文笔提高了不少,思想也成熟了不少。我越来越感觉到这个记录了我成长的网站该有一些新的动作了(说白了就是逼格不够了)。
-
-过年的时候第一次尝试了Markdown,真是有种相见恨晚的感觉。MD语法简单好学,码字时可以减少手在键盘与鼠标之间切换的频率,让人更加专注于内容本身。这是我想换博客系统的一个重要原因。早就听说过各种静态博客系统,也看见不少友站纷纷跳坑Hexo,我还是耐不住寂寞,自己尝试了一下。其实我一直都对静态博客持保守态度,感觉内容管理应该挺麻烦的,自己用过了以后感觉也是可以接受的。虽然感觉还行,但这还远远不足以说服我换博客系统。随着对静态博客程序的了解加深,我认识了[Hugo](https://gohugo.io)这个静态页面生成器。
-
-目前最火的静态页面生成器无非就是Jekyll、Hugo以及Hexo。看看[StaticGen](https://www.staticgen.com/)这个网站,上面列出了常见的静态页面生成程序。Jekyll历史最悠久,算是鼻祖,是GitHub Pages的默认引擎,主题什么的也是挺多的。然而问题是Jekyll真的有点老了,页面生成速度较慢。在本地使用时还要装ruby,略麻烦。Hexo的页面生成速度快多了,但是安装还是麻烦,npm安装几千个文件,想想就很烦。其实说Jekyll和Hexo安装麻烦,都是跟Hugo对比才这么说的。Hugo是用GO写的,可以编译成一个二进制文件,在Windows上,下载一个hugo.exe就可以用了,完全不用装GO环境。而且,Hugo的页面生成速度可以说是所有静态页面生成器里最快的,几十篇文章一般也就几百毫秒。真如官网上所说:“Install in seconds, build in milliseconds.”
-
-说静态博客管理不方便是有原因的。设想,你用着某个静态博客程序写博客,现在你离开了你日常操作博客源码的电脑,想发文章,怎么办?你指着别人的电脑,问道:“可不可以借我写篇文章?我可不可以装个git?我可不可以装个Node.js环境?”多不好意思啊,就算别人同意借给你了,搞好这些,也没什么兴致写文章了。当然,git的问题好解决,可以用带git环境cmder,绿色便携,可以装进U盘或塞进OneDrive。其实你甚至可以把整个博客源码放在OneDrive上同步,完全不用Git。不过Jekyll和Hexo还是要解决运行环境的问题,这时Hugo的优势就显现出来了。
-
-可是不管怎么说,这还是没有WordPress方便。事实上,出门在外的时候,想发文章更多的还是得靠手机,这该如何操作?可以说这是我不想换各种静态博客的主因。除此之外,博客评论问题怎么解决?
-
-随着了解的深入,我发现我对静态网页的认识还停留在上个世纪。我以为静态网页就是传统意义上的那种写成什么样就是什么样的,不存在各种数据交互——我完全忽视了Ajax技术的强大。渐渐接触到了“[JAMstack](https://jamstack.org)”这个概念,就是“客户端的JavaScript”、“可复用的API”以及“预构建的Markup”。JAMstack是一个很新的名词,网上能找到的资料也非常少,我已经在写一篇关于JAMstack的文章,谈谈我的理解与思考,目前进度很慢,写了快一个月还没写完,这里就不过多探讨了。JAMstack的网站大概是这样的:将尽可能多的数据预先构建成静态HTML文件,比较动态的、交互性很强的数据(例如评论)做成后端API,用JS来调取。
-
-从JAMstack身上,我仿佛看见了Web的未来。Web是以操作资源(获取、增删)为目的的,是面向数据的。访问一个网页,就是获取数据,或者说资源,不管用什么方式,只要能达到数据传送到目的就行了啊,为什么一定要用动态程序从数据库里拉数据,然后实时生成HTML文件再传送过来呢?做个REST API,浏览器端就可以直接获取数据、处理并插入到页面中。你一定听说过前后端分离、微服务架构这些概念,将各个模块分开部署,独立维护,前端和后端通过REST API来交互,安全高效,而且跨平台。
-
-随后我又认识了[Netlify](https://www.netlify.com)这家公司,事实上JAMstack的概念就是Netlify的CEO,Matt Biilmann提出的。Netlify专注于为JAMstack网站提供提供托管服务,算是一个GitHub Pages的替代品。把你的源码放到Git托管(GitHub、GitLab、Bitbucket等)上,Netlify检测到Commit之后会自动构建并部署,完全不需要手动操作。
-
-听了Matt的很多演讲,发现它经常提到[Smashing Magazine](https://www.smashingmagazine.com/)这个案例,Smashing Magazine是一个关于Web设计与开发的媒体,他们的网站最近就完成了JAMstack的改造。以前用是WordPress做CMS、Shopify做商城、Rails做Job Board、Kirby做活动安排,在各种平台维护一套设计风格差不多的网页。换了全新架构之后,文章用Hugo生成,各种类型的页面可以共用一套API,由于是静态页面,全站CDN就很爽了。可以说Smashing Magazine的案例充分证明了JAM架构做复杂的网站是可行的。Netlify在协助Smashing Magazine完成改造的过程中写了很多开源API,都是做JAMstack网站很好的解决方案。
-
-回到前面的内容管理问题以及评论问题,到这里,我心里已经有数了。
-
-慢慢了解到“Headless CMS”这个东西。不知道大家还是否记得我以前写的那个《[Foxhound主题轻度体验](https://www.xxxlbox.com/posts/2017/try-wp-theme-foxhound/)》,那个主题就是利用了WordPress提供的REST API,页面并不是完全是由PHP生成,如果我没有记错的话应该是用了React。其实这样就是把WordPress当一个Headless CMS来用了。Headless CMS字面上理解就是“无头”的内容管理系统,CMS不再仅仅是对网页内容进行管理,更多的是提供一个通用的接口使各种平台可以获取数据。Headless CMS一般有两种:API Driven和Git-based,大家可以看看[headlesscms.org](https://headlesscms.org),上面有很详细的介绍。Git-based这种不是以提供API为目的,它能做的是让你可以在浏览器里编辑文章,然后把更改提交到你的Git托管中。Git-based Headless CMS目前我试用过的有开源的[Netlify CMS](https://www.netlifycms.org/)和商业(但是免费)的[Forestry.io](https://forestry.io/)。效果都很好,手机上写博客也不是问题了。
-
-{{< figure src="https://assets.xxxlbox.com/images/2018/img021.png" alt="Headless CMS" caption="Headless CMS" width="1281" height="718">}}
-
-评论系统目前考虑过这些方案:
-
-* 第三方评论系统。Disqus被墙,畅言、来必力似乎都不错,但还是怕Vendor lock-in,万一哪天他们倒了,数据迁移就麻烦了。暂时不考虑第三方评论系统。
-* GitHub Powered:这种评论系统要么就是像Gitment或Gitalk那样用GitHub Issue来评论,评论者需要一个GitHub账号,要么就是像[Staticman](https://staticman.net/)这种,把评论以json格式提交到repo中,你只需要把repo授权给Staticman,评论者不需要GitHub账号。Staticman我是肯定会考虑的。
-* 第三方后端服务:[Valine](https://valine.js.org/)就是一个不错的解决方案,用[LeanCloud](https://leancloud.cn/)做后端,完成度比较高,用起来很方便。
-* 自建:听说过ISSO,感觉不适合我。我试着用Firebase做后端,自己写了个,评论提交成功了,才发现Firebase已被墙。后来又发现了CouchDB,现在还在折腾中。
-
-综合来看,Staticman或者Valine都还不错。以后自己写个评论系统,也不是不可能,CouchDB还是很好用的。自己写的评论系统名字我都想好了,就叫Couchat,哈哈。
-
-我的Hugo站还在准备中。目前有一个测试站,hugo.xxxlbox.com,托管于Netlify,源码托管在GitLab上。用的这个主题并不是自己写的,很多地方我都不喜欢,怎么改都改不好,遂决定重新撸一个。Hugo是一个我从来都没有接触过的博客系统,它跟WordPress真的很不同,我踩了不少坑。写一个Hugo主题并不容易,Go Template那一套跟PHP很不一样,还得从零开始学。真的很喜欢那个主题,所以新主题会“借鉴”很多,估计最终差不多就是测试站这种效果了……
-
-原先打算等毕业了再换Hugo,因为那时腾讯云学生机就要到期了,换静态博客可以以较低的成本来运营,然而,我现在就忍不住了。前面提到的升级MySQL 8.0,性能翻一番的代价是内存占用也翻了一番。可以说,跑上一个WordPress站,Minecraft服务器都开不起了……是时候换了,真的该换了。
-
-![ssh top命令显示mysql内存占用](https://assets.xxxlbox.com/images/2018/img022.png)
-
-细心的同学们应该发现本站的固定链接格式改了,从数字变成了文章名,就是为了提前适应博客系统的更换。新博客应该要不了多长时间了,敬请期待。
-
-等等,[Alchemist](https://github.com/Track3/alchemist)主题怎么办?这可是你人生中第一个GitHub项目啊!事实上,我把它放到GitHub上,原因主要有二:其一,我要遵循GPL开源协议,其二,我想学习Git以及GitHub的基本操作。原本是想好好打磨,搞个大事情的,可是计划永远都赶不上变化。主题并没有任何宣传,比较偏个人喜好,算是自用主题了,可是不管怎么说,一旦有人表示喜欢并且想用这个主题,我肯定尽力完善它,做到善始善终——喜欢请Star。
-
-一不小心写了这么长,其实这篇文章原本一句话就完了:
-
-我要换Hugo了。
-
-## 尾巴
-
-WordPress会逐渐被淘汰吗?我觉得会,没有什么技术会是永恒的。在合适的时候,会出现合适的技术,解决合适的问题。并不是说WordPress一文不值了,它依然是目前建站最方便、最好的方案之一。就像jQuery,即使Modern JavaScript已经有很多强大的API,jQuery不再是必须,但是谁也不会忘记在那个浏览器标准混乱、JS还不是很强大、移动端还没有崛起的年代,jQuery给Web开发带来的巨大便利。

+ 0 - 52
content/posts/2019/quicklink.md

@@ -1,52 +0,0 @@
----
-title: "用上了Google quicklink"
-date: 2019-03-25T23:05:42+08:00
-draft: false
-toc: false
-images:
-tags:
-  - 前端
-  - Hugo
----
-
-很久很久以前,还是功能机时代,手机能装`.jar`格式的应用,我记得UC浏览器有个很厉害的功能:智能预加载——即它能够检测出页面中的翻页导航,然后提前为你加载下一页,然后你点击“下一页”这个链接时页面秒开。在那个乌龟网速的2G时代,这个功能可以说极大地提升了刷网页的畅快感(尤其是看网络小说的时候🙄)。只是当时流量贵,5元30M,有时候都有点舍不得开这个功能。现如今网速快了,流量也便宜了,这个功能很少再出现在我的视线中。
-
-几个月之前Google Chrome Labs开源了一个由[Addy Osmani](https://github.com/addyosmani)发起的项目[quicklink](https://github.com/GoogleChromeLabs/quicklink),它可以让浏览器在空闲时预加载视区内的链接以提升后续页面的响应速度,这跟以前的UC浏览器自动缓存下一页功能多少有点像。得知消息我倒是把GitHub地址记下了,却一直没有尝试用一下,最近突然想起这个于是我就在博客上用上了。
-
-关于quicklink的原理,README上已经说得很清楚了,而且已经有了[中文版本](<https://github.com/GoogleChromeLabs/quicklink/blob/master/translations/zh-cn/README.md>),所以我在这里复制粘贴也没什么意义,想更详细了解的直接去看源码就行。大致过程就是:脚本首先检测视区中的链接,等待浏览器空闲的时候,如果检测到用户不是处于慢速连接或省流量模式下,就用`rel=prefetch`来预加载这些链接。
-
-quicklink的使用超级简单,只需引用`quicklink.umd.js`这个gzip后不到1KB的js,然后调用`quicklink()`方法即可,更重要的是它与现有js几乎不存在冲突问题,不像instantclick.js。官方README上有很多使用方法的示例,你可以调整的配置有:
-
-* 设置被检测的元素,默认为document,即整个页面;
-* 指定超时时间(默认两秒)以及超时之后的回调函数;
-* 选择使用`rel=prefetch`还是Fetch API;
-* 设置链接的白名单、黑名单,指定允许进行预获取操作的host,默认只允许同域;
-
-本站利用了Hugo自带的Asset Pipeline,将`quicklink.umd.js`与原有js一并打包,几乎不影响原始页面的加载。相关代码如下:
-
-```html
-{{ $mainjs := resources.Get "js/main.js" -}}
-{{ $quicklinkjs := resources.Get "js/quicklink.umd.js" -}}
-{{ $script := slice $mainjs $quicklinkjs | resources.Concat "js/bundle.js" | minify | fingerprint -}}
-<script src="{{ $script.Permalink }}" {{ printf "integrity=%q" $script.Data.Integrity | safeHTMLAttr }}></script>
-<script>
-  quicklink({
-    ignores: [uri => uri.includes('index.xml')]
-  });
-</script>
-```
-
-兼容性方面,quicklink只支持较新版本的浏览器(Safari除外,最新的也不支持),但是无所谓,你可以把它当作一个渐进性特性([progressive enhancement](https://www.smashingmagazine.com/2009/04/progressive-enhancement-what-it-is-and-how-to-use-it/)),就是说浏览器不支持也不影响网站的正常浏览,也就少一个体验加分的功能而已。~~谁让你用那么旧的浏览器,怪我咯?~~想让IE11和Safari也支持的话你完全可以引入一个6KB(gzipped)的polyfill,给旧浏览器打个补丁。
-
-本站是静态站点,启用quicklink只会增加服务器的带宽开销,对CPU占用等几乎无影响。而如果你是动态网站,用这个你就不得不考虑下性能方面的问题。如果你觉得直接缓存所有可见链接有点粗暴,你可以看看[instant.page](https://instant.page/)这个项目,它是当你把鼠标光标悬浮在链接上时才开始预加载,类似于InstantClick。说真心的,InstantClick的确有些年头了,它的原理是把整个网站变成单页应用,浏览器不会转圈圈,而是脚本自己在页面顶部加了个进度条,地址的更新也是依赖于`history.pushState()`这个API实现的。这样就有一个问题,网页上的其他js有时会依赖于窗口加载事件(比较常见的就是百度统计、谷歌统计等),加了InstantClick之后用户点击一个链接,虽然表面上好像导航到了一个新的页面,但是窗口加载事件并不存在,所以你必须把依赖窗口加载的这些function像这样重新调用一遍:
-
-```javascript
-InstantClick.on('change', function() {
-  // functions
-  // …
-});
-```
-
-quicklink以及instant.page利用的是`rel=prefetch`,就温和许多,用起来要方便不少,所以我这里强烈推荐用instant.page来代替InstantClick。
-
-由于quicklink的README实在是太详细,还有简体中文版的,所以我不多说了,感兴趣的自己去看吧,有问题欢迎在评论区讨论。

+ 0 - 158
content/posts/2019/wsl-my-exp.md

@@ -1,158 +0,0 @@
----
-title: "WSL之我的体验"
-date: 2019-04-14T18:54:00+08:00
-draft: false
-toc: true
-images:
-tags:
-  - WSL
-  - Windows
----
-
-以前,跟绝大多数Windows用户一样,我在日常使用电脑的过程中几乎从来不会碰命令行界面,后来我开始学习建网站,慢慢地就会了一些Linux命令。随着自己对Web开发的了解逐渐深入,我对终端的使用频率也越来越高。新的一年到了[^1],又到了例行重装系统的时候,这次我决定试一下WSL(Windows Subsystem for Linux)。
-
-## 前言
-
-说到Windows的命令行环境,CMD是公认的难用,这个大家应该没什么意见吧?更可气的是这个命令提示符还很丑,默认发虚的字体,黑乎乎的背景、不支持真彩色……硬核的外表不知吓退了多少小白用户,即使已经升级到了Windows 10这样的版本,CMD依然是那么地不友好。难怪很多人都说Linux是在命令行上面做了个图形界面,Windows是在图形界面里顺便带了个命令行。这话一点也不假,在Linux中,无论你用的是哪一种图形界面,一般按<kbd>Ctrl</kbd>+<kbd>Alt</kbd>+(<kbd>F2</kbd>,<kbd>F3</kbd>,<kbd>F4</kbd>,…) 都会切到对应的TTY:命令行的地位自然就不言而喻了。再看Windows,看名字就知道,窗口,那不就是图形界面嘛。Windows本来就是要革了命令行界面的命的,在早期是为了兼容DOS的一些操作,才搞了个cmd.exe。既然命令行界面根本就不是Windows的核心卖点,绝大多数用户不会接触这个东西,微软自然也就不会重视了。
-
-不得不承认的是,在某些特定的场景下,输入命令比在图形界面里面点来点去更高效。考虑到与时俱进,微软推出了PowerShell。PowerShell很强大也足够现代化,但考虑到习惯问题,我始终下不了决心去学习它。可以说,我对命令行界面的使用习惯完全是折腾Linux服务器培养起来的,因此我更习惯类Unix系统的那一套操作。比如说,在查看目录中包含的文件以及文件夹时,我习惯用`ls`命令而不是`dir`,输入路径时,我也经常习惯性地按了`/`而不是`\`。我们当然没有必要去争论PowerShell与Linux shell孰优孰劣,他们都是解决问题的一种工具罢了,多一个工具,总归是好事。前面吐槽了半天Windows的命令行界面,其实无非就两点,而且得益于强大的社区支持,这些都有比较好的解决方案:
-
-一是shell的问题,这其实就是习惯的问题。CMD就不谈了,PowerShell的确是不错,只要你愿意学习,能够习惯。习惯不了的,你可以试试Cygwin或者Git bash之类的,也一样能在Windows上用一些常用的Linux命令。
-
-其二,就是外观的问题。Windows自带的终端模拟器属于比较底层的应用,就很难有多种外观自定义选项。不过这个其实也不是什么大问题,Windows平台上有很多第三方的终端模拟器可以使用,例如ConEmu以及一个不错的整合:Cmder,还有基于Electron的Hyper、Terminus等,最近我又发现一个很不错的基于微软流畅设计风格的UWP应用:[Fluent Terminal](https://github.com/felixse/FluentTerminal)。
-
-我之前的搭配正是Git bash + Cmder,整体上差强人意(差强人意是“基本能让人满意”的意思),Git bash带的几个Linux命令挺就挺够我用的,Cmder说不上是最好看的终端模拟器,但是它的自定义选项丰富,拓展性极强,而且启动速度也挺快的。
-
-那么问题来了,如果说Git bash + Cmder的组合就已经让我满意了,那为什么还要去折腾这个Linux子系统呢?对我个人而言,WSL最吸引我的就是Linux的包管理器了,就拿我最常用的发行版Debian来说吧,几乎就是你需要什么软件,`apt install`一下,一个命令就全部完成了,依赖什么的根本就不用你来操心。而Windows上安装软件基本上就是要用installer点击一波下一步,虽然也不麻烦,但是如果你有很多软件要装,这样就有点耗时间了。虽然Windows上有第三方的包管理器,Chocolatey或者Scoop,然而我都没用过,所以我不能做评价。WSL最黑科技的地方就是它可以直接运行大多数的Linux二进制程序,对,就是直接运行,配合包管理器,搭建各种开发环境就相当方便了。
-
-同样是让你在Windows上执行Linux命令,对比Cygwin,WSL的实现更加底层。Cygwin中运行的各种Linux命令本质上是编译成Win32下的可执行程序,而WSL则是与Win32同级别的子系统,它可以直接与NT内核交互。说白了就相当于微软自己用Windows NT的API来实现了一遍Linux kernel,从一个Linux程序的角度来看,它就是在与一个假的Linux内核进行交互。由此可见,WSL就像一个翻译官,把Linux应用程序的POSIX系统调用翻译成Windows系统上的NT API调用,所以WSL究竟能有多大的本领或者说对Linux程序有多好的兼容性基本就取决于这个假内核能实现多少真内核的特性,就好比说这个翻译官对外语究竟有多好的掌握。理论上只要实现了足够多的系统调用翻译,那么WSL可以完全模拟成一个Linux内核。
-
-运行一下`uname -a`就可以看到了,这个Linux子系统的内核版本号为`4.4.0-17763-Microsoft`,可见它是以Linux kernel 4.4.0为参照,而我运行的正是Win10 1809,也就是Build 17763。
-
-```bash
-$ uname -a
-Linux DESKTOP-BH9C0Q3 4.4.0-17763-Microsoft #379-Microsoft Wed Mar 06 19:16:00 PST 2019 x86_64 GNU/Linux
-```
-
-## 使用
-
-这篇文章就不详细说Linux子系统怎么启用了,反正也很简单。进“启用或关闭 Windows 功能”,然后在列表里勾上“适用于 Linux 的 Windows 子系统”重启即可。或者直接用带管理员权限的PowerShell运行:
-
-```powershell
-Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
-```
-
-启用WSL之后,打开应用商店搜索“wsl”,挑一个你喜欢的发行版安装即可。第一次运行需要设置用户名和密码,之后就可以开始愉快地折腾了。
-
-下面就从我的实际经历出发来记录一下WSL中开发环境的搭建以及一些工具的配置。
-
-### shell
-
-WSL的前身就叫Bash on Windows,可见其重要目标之一就是提供一个类似Linux bash的shell体验。当然,除了默认的bash,你完全可以安装zsh或者fish使用。oh-my-zsh是一个很棒的`zsh`配置管理工具,它可以为你提供一个开箱即用的zsh环境,而且有很多主题插件可用。在WSL上运行oh-my-zsh跟在Linux或者Mac上并无太大区别,值得注意的是oh-my-zsh本身就比较慢,而WSL的I/O性能对比原生Windows又要差一点,所以shell的启动速度就是你要注意的了。在我的电脑上配置了oh-my-zsh后shell启动速度大概为两秒,我个人还是可以接受的。安装oh-my-zsh只需运行:
-
-```shell
-sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"
-```
-
-主题我推荐`ys`,非常轻量,而且没有特殊字符,因此兼容小字符集的字体而不会出现讨厌的框框。更换主题只需编辑`~/.zshrc`,更改`ZSH_THEME`这一变量的值即可,例如`ZSH_THEME="ys"`。
-
-另外,再分享一个alias配置:
-
-```bash
-alias start="cmd.exe /c start"
-```
-
-只需输入`start .`,就能很方便地调用Windows资源管理器打开当前目录[^2]。当然你也可以用`explorer.exe .`命令实现同样的效果,但是前者输入更方便,而且能与CMD、PowerShell共用一套操作。
-
-### 终端
-
-前面被疯狂吐槽的Windows默认终端模拟器(也就是conhost.exe)在最近的这几次Win10更新中已经得到了不少改进,虽然还是被Linux和Mac终端甩开好几条街,但是稍微配置下还是勉强能用的。以下我的配置均是在Win10 19H1(Build 18362)中测试使用的,该版本目前仍处于insider通道,预计5月份正式推送更新。
-
-在终端标题栏上右击,可以看见菜单中有个“默认值”,还有个“属性”,打开它们你会发现其实两个的配置项是一模一样的,不过这两个设置窗口下配置的保存位置是不一样的。建议是优先改“默认值”,改完后保存重开终端就好了[^3]。
-
-字体我用的是[更纱黑体(Sarasa Gothic)](https://github.com/be5invis/Sarasa-Gothic),是一套支持中文的等宽字体。值得注意的是conhost对字体极为挑剔,要是你选的字体兼容性不够,当你在WSL下运行`nano`等命令的时候字体会变成新宋体。配色的话,微软出了一个官方工具[ColorTool.exe](https://github.com/Microsoft/console),支持直接读取iTerm2的`.itermcolors`格式配置文件,可以让你方便地改终端配色。配色直接去[Iterm2-color-schemes](https://iterm2colorschemes.com/)打包下载即可,我用的是`Neutron`。配置了90%的透明度,再加上从Win10 19H1开始支持的全局暗色主题,最终效果如下:
-
-{{< figure src="https://assets.xxxlbox.com/images/2019/img027.jpg" alt="Win10 19H1系统自带终端" caption="Win10 19H1系统自带终端" class="big" width="1455" height="919" >}}
-
-说不上好看,但是最起码不像以前那样丑得刺痛双眼。如果说这个外观还有什么要亟待改进的,我认为就是内边距了,用CSS里的话说就是`padding`。Win10窗口没有像Win7、Win8那样较宽的边框,最终终端的文字是挨着边显示的,总让人觉得有点不舒服。但是总体上来说,新版Win10终端已经是能让我满意了(差强人意),毕竟性能真的无敌,启动贼快……
-
-这里又想起一个可能你还不知道的小技巧,在Windows资源管理器中,按住<kbd>Shift</kbd>右击空白处,右键菜单里会出现“在此处打开 PowerShell 窗口”以及“在此处打开 Linux shell”两个选项。
-
-说完了自带终端,再来聊一下第三方终端模拟器。[Fluent Terminal](https://github.com/felixse/FluentTerminal)绝对是我心目中Windows上最漂亮的终端,它应用了微软流畅设计风格,亚克力半透明效果真的很赞,我个人认为这就是未来Win10上终端该有的样子。
-
-{{< figure src="https://assets.xxxlbox.com/images/2019/img028.jpg" alt="Fluent Terminal" caption="Fluent Terminal" class="big" width="1357" height="888" >}}
-
-但是目前Fluent Terminal并不是十分完善,有些小bug。它基于UWP构建,但是因闪退问题没能通过应用商店的测试而无法上架,所以安装起来相对要麻烦一点。你需要导入作者的证书,然后开启Win10旁加载模式,不过作者有提供一键安装脚本并且支持从[Chocolatey](https://chocolatey.org/)安装。除了Fluent Terminal之外,[Terminus](https://github.com/Eugeny/terminus)也非常好用,是我现在的主力终端模拟器,ssh模块用起来很方便。
-
-### Git
-
-在WSL上安装使用git非常简单,但是麻烦的是,如何让Windows桌面程序调用WSL里的git呢,难道还要再装一个Git for Windows?还好,早就有人意识到这个问题而且有个不错的解决方案——[wslgit](https://github.com/andy-5/wslgit)。它是一个能把Windows形式的文件路径(例如`C:\Foo\Bar`)与Linux的路径(对应的`/mnt/c/Foo/Bar`)进行互相转换的一个可执行程序,就像代理人一样。wslgit.exe的使用非常简单,下载它,将他重命名为`git.exe`,让后把他加到Path里就行了。像我的习惯的就是C盘根目录建一个`bin`文件夹,然后编辑系统环境变量,选中`Path`这一变量,编辑,添加一行`C:\bin`,这样一来,将任何exe可执行文件丢到`C:\bin`目录下,都可以实现全局的调用。最终效果就是你可以在PowerShell或CMD中直接运行`git`命令了。
-
-![](https://assets.xxxlbox.com/images/2019/img029.jpg)
-
-然而这还不够,有些桌面程序可能还需要单独配置git的可执行路径,比如VS Code。在VS Code配置文件中需加入一行:
-
-```json
-"git.path": "C:\\bin\\git.exe"
-```
-
-另外,为了提升wslgit的性能,你可以添加一个环境变量`WSLGIT_USE_INTERACTIVE_SHELL`,设其值为`0`或`false`。这样可以使wslgit运行在非交互模式中,在被调用时无需加载`.bashrc`或`.zshrc`等用户配置文件。
-
-### SSH
-
-现如今Win10已经内置了OpenSSH,我们终于不用像以前那样连个ssh还要装一个putty。很显然,WSL里也有一个ssh客户端,那我们怎么让两边共享密钥以及各种配置呢?其实最容易想到办法就是用`ls -s`命令创建软连接了,将Windows下的`C:\Users\you_name\.ssh`(也就是`/mnt/c/Users/your_name/.ssh`)链接到`~/.ssh`即可。这样就可以在Windows这一侧统一管理ssh配置。首先确保PowerShell下能正常连接ssh,并且WSL中的~/.ssh是不存在的,然后在wsl中输入`ln -s /mnt/c/Users/your_name/.ssh/id_rsa ~/.ssh/id_rsa`即可。由于ssh对密钥文件的权限有严格要求,而默认情况下Win的文件系统挂载到Linux时会被设为777权限,显然这个权限对密钥文件来说实在是太大了,于是ssh会阻止密钥的使用。为了解决这个问题,Win10 Build 17093及以后的版本已经支持了WSL启动选项,就是你可以在`/etc/wsl.conf`里自定义wsl启动时的一些配置。我们可以在`wsl.conf`中加入这个:
-
-```ini
-[automount]
-options = "metadata"
-```
-
-这样WSL就能在挂载时写入metadata,问题就解决了,文档在这里:<https://docs.microsoft.com/en-us/windows/wsl/wsl-config#set-wsl-launch-settings>。
-
-值得注意的是,如果你跟我一样使用了`.ssh/config`文件来设置alias,单独指定密钥文件等,那么以上方法就行不通了,ssh会提示你`.ssh/config`文件权限有问题。据说[^4]是`.ssh/config`只允许读写权限,因此无法存在于Win的文件系统中。所以一个解决办法就是不要链接整个`.ssh`文件夹,而是手动链接`.ssh`下的所有非`config`文件,然后在WSL下手动编辑`config`文件。
-
-### Node
-
-WSL对node.js的兼容还是比较好的,安装起来就跟在普通Linux机器上差不多。你可以进行传统的单版本安装,也可以用nvm来方便管理node的版本。你只需要注意nvm会在你的shell配置文件里加入相关环境变量,会比较明显地拖慢shell的启动速度,至少我自己是这样的。当时我的zsh启动很慢,还以为是oh-my-zsh插件装多了,最后网上搜索了半天才发现是nvm的锅。我现在一直用着Current版的node,也没出什么问题,可能因为是比较轻度的使用吧。
-
-### Docker
-
-Docker利用了Linux kernel的一些比较高端的特性,这些特性WSL还未全部实现,所以现阶段WSL是无法直接运行docker的,即无法启动docker的守护进程。docker的架构是分三个部分的,即Client、API以及Server(守护进程),服务端和客户端无须安装到一个地方。WSL运行不了服务端,但是跑客户端是可以的,服务端就用Docker for Windows好了。在Windows与Linux分别装上对应的docker,然后在Docker for Windows的设置中开启"Expose daemon on tcp://localhost:2375 without TLS"选项,最后在WSL中编辑`~/.bashrc`或`~/.zshrc`,加入`DOCKER_HOST=tcp://127.0.0.1:2375`即可。现在WSL里能正常连接到Win上的Docker for Windows,可以进行各种镜像、容器的管理了。
-
-另外,WSL默认把Windows的文件系统挂载到`/mnt/`下,比如`/mnt/c/Foo/Bar`,而Docker for Windows期望的地址是`/c/Foo/Bar`,所以容器的文件夹挂载就用不了了。还好在`/etc/wsl.conf`中能指定自动挂载的位置,这里只需在`wsl.conf`的`[automount]`组下加上`root = /`即可。值得注意的是,前面我们用的wslgit的期望挂载位置是`/mnt/`,代码里是写死了的,好在作者应大家的要求,单独编译了一份挂载点为`/`的版本,使用这个版本就行了。
-
-### 其他问题
-
-关于hosts文件的共享的问题。Windows的hosts文件位于`C:\Windows\System32\drivers\etc\hosts`,Linux的位于`/etc/hosts`,默认情况下,WSL会自动用Windows的hosts文件生成Linux的hosts,所以如果你要改WSL中的hosts文件,可以直接改Win下的,让后注销重登即可。如果你想让Win与Linux的hosts不同,你可以编辑`/ect/wsl.conf`加上这些:
-
-```ini
-[network]
-generateHosts = false
-```
-
-另外,听说有人在WSL里跑桌面应用……
-
-## 总结
-
-说实话,我真没想到WSL这一侧竟然有这么完整的Linux体验,而且Linux子系统与Windows的互通性竟然是这么的好。
-
-在Windows目录下可以直接启动Linux shell,PowerShell或CMD可以直接通过`wsl xxx`运行Linux命令,而Linux下可以直接执行安装在Windows中的程序,Path还是共享的,更可怕的是Windows与Linux的命令还能混着用,比如这样直接把文件内容复制到Windows剪贴板中:`cat ~/.zshrc | clip.exe`……
-
-诚然,WSL还有许多不完善的地方,比如I/O性能不够理想,直观感受就是`npm install`的时候有点慢,更重要的是Windows上的第三方软件支持度还不够,有时候无法避免地要在Win与Linux两侧都装上某些软件。不过我真的很期待WSL的进一步完善,什么时候能直接跑docker那就真的nb了。我的期待总结起来就是:
-
-* 完善内核;
-* 提高性能;
-* 第三方应用支持。
-
-## 相关参考
-
-我在网上搜索与WSL相关的一些问题时发现了很多写得很不错的文章或是教程,这篇文章也有很多是参考他们的。我在前文中有许多写得不全面的,大家都可以去这几个地方看看:
-
-* [WSL 配置指北:打造 Windows 最强命令行](https://blessing.studio/wsl-guide/)
-* [Dev on Windows with WSL (dowww)](https://spencerwoo.com/dowww/)
-
-
-[^1]: 这篇文章起草于2019年1月5日。
-[^2]: 来源于<https://stackoverflow.com/questions/44245721/launching-explorer-from-wsl>。
-[^3]: 以我自己的亲身体验来看,在19H1以前,改“默认值”没用,保存重开还是原样,只能改“属性”才行。也不清楚这是真的有bug还是我的打开方式不对。
-[^4]: <https://florianbrinkmann.com/en/3436/ssh-key-and-the-windows-subsystem-for-linux/#comment-3109>。

+ 0 - 5
content/posts/_index.md

@@ -1,5 +0,0 @@
----
-title: "Writing"
-date: 2018-11-27T18:43:59+08:00
----
-