reedo0910 / velaswebsite3 Goto Github PK

下面列出下一阶段（当然，因为学业的原因，可能将是一周或更长时间）的计划任务。

功能添加

• 为News文章添加待办事项编译功能
• News文章加入上一篇/下一篇导航，以及跳转到留言区的导航
• ⌛️ 为News文章添加目录编译功能

页面添加

• 💪 添加Collection页面，并提供Collection到音乐/美食/电影的二级导航

错误修复

• 滤除News文章列表中摘要中markdown相关字符
• ❓ 调查引起highlight.js对JS代码高亮不正确问题的原因

改版后的留言板使用的是Gravatar的头像服务（与Wordpress等博客平台通用）。默认头像是白色。

如果想要自定义头像的话，请访问 「cn.gravatar.com」 ，并点击“Create Your Own Gravatar”按钮，然后使用你留言的邮箱地址进行注册即可。

注册成功后，即可上传并使用你自己的头像了(・ω・)ノ

把上述步骤完成之后，刷新Velas页面就能看到你的新头像哦(￣▽￣)

与此同时，你在Gravatar中设置的头像不仅仅会在Velas中出现哦。只要你在使用了Wordpress（基本涵盖了绝大多数的个人博客）或是其他支持Gravatar的个人空间中留言，都能看到你漂亮的头像啦。

是不是很酷呢，那快来试试吧( ´▽` )ﾉ

下面列出下一阶段的更新计划 （由于要忙于考试，所以这几个月将酌情延长更新周期）

功能添加

• 增加加载页面的进度提示

页面添加

• 添加Collection页面

错误修复

• 调查引起News文章加载时间长的原因（已修复）

摘要

• Velas News上线，用于记录更新、待办事项和技术记录等。
• Log改名为News，并划分为News、时间胶囊和Log三个子页面，均使用统一的风格重新设计，并为其添加二级导航。
• 修复了一定概率会出现Loading chunk x failed，从而导致页面加载失败的bug。
• 依赖库升级，包括将Webpack从v2升级为v3等。

Velas News

这是啥？

Velas News上线，应该算是本周Velas的大新闻了，因为没有它的上线你也看不到这篇东西。经过两天的开发和两天的测试，这个新系统终于正式被放进了Velas中。

Velas News计划用于刊登每周Velas以及Velas Camp中发生的变化、技术日志以及待办事项。一方面为接管Log的全部职责，另一方面是将以前需要在Talk发布的技术日志放到这里完成，而Talk也从此更偏向个人博客而不是技术博客。

因为使用了GitHub的api，Velas News也因此实现了留言的功能。若想对某篇文章进行留言，只需通过点击按钮跳转到相关的GitHub页面进行留言即可。留言完毕后，通过刷新页面就能看到最新的留言了。

News的版面设计参考了Firefox Nightly的博客的设计，因为我实在太喜欢这种风格了，因此在初期可能会有些雷同。同时我也进行了一些自身的思考，将Nightly的设计风格与原有的Velas 2017 Summer的设计风格相融合。在后期，我还将继续将News调整为更独立的设计。

如何办到的？

主要涉及到的技术内容有：

• vue-cli
• axios
• Promise
• sessionStorage

Velas News的工作原理为通过Axios从我的GitHub仓库中抓取Issue及留言数据，并通过marked.js将数据编译为可读的网页数据，最后由Vue呈现出来。

而News的头图实现原理是：通过一个自制的简易日期算法，从一批我精心挑选的图片中选出一张作为头图，保证了头图选取的唯一性和随机性。

这个通过Vue和GitHub的issue来搭建博客的天才想法我是偶然间从issvue了解到的，后来思考再三也发觉这个方案比较方便可行。通过这个契机，我学习了Session Storage、Promise、API等一直没机会接触的东西。Velas News也成了Velas第一个通过动态抓取数据来生成网页的实例。

相比issvue，Velas News改进了什么？

Velas News的实现方式一定程度上参照了issvue (2017-8-30) 的源码。但是，因为issvue更贴近一个“开箱即用”的博客系统，因此我得根据Velas的实际情况做一些调整和改进。

包括但不限于：

• 将Session Storage的机制调整为刷新页面即销毁
• 在数据获取上，移除了不必要的token参数，用于保证账号安全性
• 针对单篇文章的数据抓取，改为了使用issue编号来获取，而不再全局抓取
• 通过Promise的catch方法增加了一些错误处理，包括联网问题以及issue关闭问题等
• 使用api参数来进行作者过滤，而不在前端完成
• 评论获取的优先级放在了文章获取之后，方便发生错误时能及时响应
• 视觉上增加了读取动画以及错误提示
• 加入了响应式布局，以及其他一些设计改进

我十分欣赏issvue的实现思路，并认为虽然做出了改动，但是在一些实现方式上并无孰优孰劣之分。而这个博客系统仍然不完善，如没有分页处理、错误处理上仍不完善等，甚至在axios的使用上我觉得仍有待改进。让我们继续努力让这套博客方案变得更加完善吧(ง •_•)ง

逝去的Log

就是这样，Velas 2017 Summer又一次将一员大将——Log给砍掉了（误）。

说实话，Log是我一直以来最偏爱的模块，是Velas创建至今最长寿的页面（😂），也是News之前Velas网站里设计最精密的一个网页。通过filter把json数据编译成月份选择、日期选择以及日志列表三个部件的内容，并通过总线来联动三个部件的操作。与此同时，日期选择部件的定位实现也是在仔细思考过百度百科的定位部件实现原理之后做出来的，当时还十分有成就感。

看着从2016年5月3日直到2017年8月29日这段时间断断续续记录的这个网站的成长历程，我真的感触良多。

一直以来，我当程序员最喜欢也是最执着的一个工作就是写更新日志，因为特别有成就感、特别自豪。写代码的过程是枯燥而漫长的，如果不加以记录的话，有时会忘了自己一直以来在干什么，只会以为是在不断的修bug、加feature。而更新日志则是对程序更新历程最直接的反馈，通过这种有形的东西能提醒自己做了什么、需要做什么、是不是真的需要这样做。在编程的初期，这真是非常不错的惊醒。

而砍掉Log的契机是渐渐觉得更新日志这种方式有点太琐碎了。

特别是作为一个网站，在普通的维护期间，做的东西其实是非常单纯而不足为记的，例如一些CSS的调整或是代码优化，写下来其实根本没必要；而大一点的东西，如技术总结、代码分享则没有空间写，最后只能堆到Talk来写。渐渐会听到“我这种外行人看你的博客，却发现自己啥都看不懂”这种令我哭笑不得的话，渐渐思考着是时候做出改变了。于是趁着Velas重构这个契机，因为Log的设计风格格格不入 一咬牙将这个一直以来陪伴我的网页去掉了，改用News来收集每周值得记录的更新内容 （绝不是因为懒）。

虽然不是第一次意识到前端是个快速更替的行业，但就如新Velas的副标题那样——Everything flow。（“一切皆流，无物常驻”，引用自赫拉克利特(Heraclitus)的名言。）虽然世界是不断变化的，但是如果能从这个变化中吸取经验的话，就能将一些宝贵的东西不断延续下去，从而不忘初心、不断新生。

Loading chunk x failed

自从七月中旬vue-router改为按需引入模块后，这个报错就如鬼魅一样纠缠着Velas不放。

表现为：在一定概率下，在页面A点击跳转到页面B的router-link链接时，弹出Loading chunk 1 failed （在网站结构不变时，中间的数字一般不变）报错，同时无法加载页面B。但是从页面C却能通过router-link跳转到页面B。并且在页面B加载完毕后，页面A也能跳转到页面B。

为了解决这个bug，在那一个月的时间内，我先后排除了：运营商DNS劫持、广告拦截插件误杀、Webpack打包未正确配置、Webpack v2.6.1自身的bug等种种可能性，甚至找遍了Google、Github、Stackoverflow等等网站。最后不但未有任何进展，这个问题反而随着二级导航的引入而更加频繁了。这个情形让我想起了当年被Webkit的Font Boosting所支配的恐怖……

当我快要开始怀疑人生的时候，我留意到了另一个伴随着这个报错一同出现的报错Unexpected token <。之前没太在意是因为以为这是加载不出组件的并发症，后来仔细检查才发现问题所在：这个报错是针对某JS文件的，但是在JS中是不可能出现HTML标签开头（"<"开头）的东西，唯一可能就是Webpack打包时误将HTML页面当作JS文件加载了。顺着这条线索，我找到了Webpack的一个设置项：

module.exports = {
  build: {
    /* ...  */
    assetsPublicPath: '/',

对，就是最后一条"assetsPublicPath"的值，我之前是写成了相对路径"./"。当然，绝对路径"/"是Webpack的默认项。之所以会那么手贱改掉，这个锅得由某网站《使用Webpack前你要知道的十件事》一文来背。里面提到的需要将Webpack的build中"assetsPublicPath"改为相对路径，从而可以直接浏览dist文件夹下的html文件来预览网页效果。然而改成相对路径最直接的后果就是会导致chunk包的加载错误。

这次经历后，我意识到虽然前端的坑很多，但是从某种程度上自己踩坑-得到教训-改进，往往比直接听信网上不靠谱的“踩坑教训”，成本来得低得多。看似是避开了错误，却不知在无形之中埋下了更大的祸根。

尾声

不知不觉写的东西有点多😂

这是Velas News的第一篇Weekly，不知你们意见怎么样呢？欢迎通过下方留言给我提意见~~

让我们下周见吧。

Mmmm... 感觉好久也没有更新News了。虽然这篇文章是稍微来得有那么一点晚，但是Velas本身是刚刚经过了一次天翻地覆的大更新，也可能在相当长的一段时间内不会再有那么大的更新了 （虽然你每次都那么说）

OK，让我们快来看一下这次更新了什么吧

摘要

• 使用服务端渲染重构的Velas
  • 什么是服务端渲染
  • SEO与更快的首屏加载
  • 图片懒加载
  • API缓存
• One Velas
• 全新的留言板
• What's next?

Velas in SSR

记得在上一篇文章里说要使用Prerendering帮Velas做SEO优化的。但是在下载prerender-spa-plugin包时由于你懂的的原因，费了好大半天的时间都装不上，还不小心把我的npm给弄坏了……一气之下，决定一劳永逸，直接让Velas上SSR

What is SSR?

Mmmm...这里要说的SSR并不是指Superior Super Rare，而是服务端渲染（Server-Side Rendering）。之前的Velas使用了SPA（Single-Page Application - 单页应用程序）进行构建，SPA虽然有着快速的页面切换速度和优秀的前后端分离特性等优点，但是却在SEO（即对搜索引擎的友好程度）和内容到达时间（time-to-content，即网站首次加载的时间）上有着一定的劣势。因此在构建一个网站，而不是一个Web应用程序方面上、，SPA并不是一个完美的解决方案。而SSR在继承了SPA所有的优点的同时，还有效弥补了这两个缺点。对用户和搜索引擎爬虫来说，SSR渲染出来的网页与传统的服务端模版渲染以及传统静态网站别无二致。

那这么说来，SSR就是一个完美的解决方案了咯？

不是的。 SSR开发对前端开发人员的要求更高，他需要开发者有足够丰富的服务端开发经验。同时，SSR对服务器本身的要求也更高。在SPA中，整个网页视图都是在用户的浏览器上生成的，而SSR则需要在服务端完成一个网页大部分的渲染任务，并将生成的结果发送到用户的浏览器。这个过程相比SPA来说将消耗服务器大量的资源。再者就是，将一套代码同时运行在服务端和浏览器端会不会是一种太过激进的做法？

不管怎么说，相比较SPA，SSR为我们带来了一个加载速度更快、更像网页的Velas，而且多亏了nuxt.js的优秀特性，帮助我快速完成了Velas从SPA到SSR的迁移。

那说了那么多，SSR版的Velas的实际情况如何呢？

SEO

多亏了SSR，现在搜索引擎可以轻易“看穿”Velas了。除了在生成网站地图（sitemap）上更容易以外，Velas的各个网页站点，以及网页内容现在也可以被搜索引擎捕捉到。

来看看谷歌的结果：

搜索“velas电波站”，会发现不仅这个子站点被搜到了，还一并列出了Velas的其他站点。同时，在概览中还显示了这个网页的内容。这在以前使用SPA的时候是不能做到的。

当然，如果说Google的爬虫支持Javascript，所以这个结果不能说明什么的话，我们试试搜一个利用Ajax获取的数据：

可以看到，在之前通过Ajax获取并自动生成的页面如今也成功被渲染成了静态页面且能被搜索引擎爬虫抓取，也意味着以后在Velas发表的每一篇文章都能被搜索引擎搜到啦，是不是非常Exciting呢？

哪怕傲娇如百度，还是可以看到页面内容的。嗯……

更快的首屏加载

在SPA版本中，Velas首次加载是有一段白屏加载时间的 （什么，你说以前也感觉不出来吗？那一定是我调教得太好了） ，而SSR版本的Velas由于采用了服务端渲染， 理论上 会使得这段白屏时间在一定程度上有所减少。至于为什么实测中SPA的DOM加载完成时间还比SSR短500ms，我觉得是因为SPA使用了CDN Combo，而SSR的vendor包目前是直接从我的服务器上下载所导致的。这也说明后续还有一定的优化空间 （虽然我也不觉得那500ms对于这个小破站来说能改变什么）。

图片懒加载

是的，现在我为Velas上几乎所有的图片都加上了图片懒加载功能。也就是说，Velas只会先加载你的浏览器窗口看到的图片，然后才加载其他的。这为Velas的打开速度提速1s~6s不等（根据当前页面的图片数量和大小而定）。不要问我以前为什么没想到要加上去，这并不是SSR独有的功能……

与此同时，我还为图片懒加载添加了一个小小的过渡动画，希望能带给你赏心悦目的体验～

API缓存

由于目前为止，博客和新闻的文章和文章列表获取用的还是通过Github提供的API。在转为服务端渲染后，首次API的数据获取改为了在服务端上完成。当有多人或是被恶意刷新同时访问Velas时，就会重复向API发起数据请求，很容易就会被Github认定为恶意访问并暂时封停API。为了避免这种情况发生，我为这部分的接口加上了服务端数据缓存。每次从API获取数据后，服务端将自动把这份数据保留相当长的一段时间，直至这段数据过期，从而有效解决了这个情况发生。当然，也加快了二次数据获取的速度啦，尤其当网络连接不畅的时候 （明明这个才是初衷啊噗）。

One Velas

现在，你可以在velas.xyz这个站点查看我所有的博客和camp项目啦，为此我还为他们根据Velas原有的风格重新设计了一个界面。

Velas Talk（现在为Velas博客）

Velas Camp（现在为Velas探索）

当然，Talk还有一些功能没搬到这里，像文章的分类显示、按标签查看等，以后会陆续搬过来。希望你们会喜欢～

全新的留言板

是的！在Velas搭建3年之后，我们终于迎来了这个功能，而且这个留言板是实时的！live！而不像最初用Javascript“伪造”的版本！为了这个页面的搭建，我还专门为Velas建了一个服务器和数据库……虽然他们以后还会用到。目前只能实现基本的留言功能，关于留言回复功能还要再等等……希望大家踊跃留言吧～

下一步？

Mmmm，毫无疑问，除了继续完善SSR的Velas外（由于我的水平所限，目前这个Velas比之前的SPA版的bug要多一些。而且单靠我的力量可能有一些bug还发现不了……如果你们发现了什么bug的话，请务必在留言中告诉我，我会非常感激的！），就是要完成电波站页面的搭建，用来发表我在我感兴趣的领域的评论，毕竟那才是我最初制作Velas的目的。（然鹅3年过去了……） 而搭建电波站需要先完善我的服务端以及网站后台的搭建，这将是一项工作量非常巨大的任务。再加上我现在要开始研究生课程的学习了，相信接下来的时间会十分紧张。但我还是会尽我所能抽时间更新的。

Q：Velas还会换架构吗？

A：在相当长的一段时间内不会。 其一，我认为SSR这个技术本身已经满足了我搭建Velas的需求了，而且SSR本身也是目前前端里十分新颖的技术，除非有什么非常翻天覆地的技术革新，我也不会再做像Velas2017到2018这种大重构了 （我也已经学不动了） 。接下来，Velas将把注意力集中在内容的充实和网站后台的搭建上，我也希望Velas不再是一个花瓶 （能称得上花瓶吗？），而是一个能真正输出内容的网站。

让我们一起努力吧(・ω・)ノ

大家好久不见，我又肥来啦♪(^∇^*)（居然还有脸回来）

因为实在是有太多东西做了，导致这近一年时间都没好好更新。一眨眼又来到了2018年，看看这年我将会给Velas带来什么变化吧~

One Velas

提出One Velas的契机是Velas Talk引入了RESTful API，然后突然意识到“啊，这一刻终于要来了呢”。

是的，现在我要维护的域名对我个人来说实在太多了，分别有velas.xyz（包括www.velas.xyz和blog.velas.xyz）、velascamp.cn及其所有子域名、还有个似有似无的velasx.com。

为了缩减一些无意义的开销，以及简化velas的网站结构。在Velas 2018更新之际，我计划将Velas Talk和Velas Camp合并到Velas中（原网站在相当长的时间内维持运作），并将Velas Camp所有的子域名迁移到velas.xyz下。至此，Velas Camp的使命全部完成（谢谢Velas Camp★,°:.☆(￣▽￣)/$:.°★ 。）

预渲染 (Prerendering)

Velas的SEO(Search Engine Optimization, 搜索引擎优化)实在是太糟糕了，以至于目前仍未在国内各大搜索引擎见到它的影子（反观Google的爬虫把整个Velas爬了个遍！超良心有木有！！）。虽然其中也有.xyz域名的锅，但SEO问题很大程度上是由Velas使用的SPA（Single-Page Application, 单页面应用程序）架构对SEO支持不足所导致的。

我计划在Velas 2018中引入 prerender-spa-plugin 的预渲染机制，相信到时SEO问题会有所改善。

留言板什么时候有？！

米错，这个东西是我从Velas建站之初就一直想加上的，只是当时由于姿势水平所限而一直没动工。

那为啥后来有了相关的知识后还是没加上呢？

一方面是我在评估这个举动对Velas会带来什么安全隐患，另一方面是给Velas添加服务器端有一定的工作量。

现在万事俱备了，留言板功能应该很快就会到来。（这应该不是个flag）

摘要

• Velas & Velas Camp全站支持HTTPS
• Velas首页全新设计
• Velas News文章增加上一篇/下一篇导航功能 & 快捷跳转到评论区
• 一些bug与安全问题修复

欢迎来到HTTPS时代

为什么要支持HTTPS？

升级到HTTPS的契机其实是：我发现Velas很容易会被运营商污染、发生DNS广告劫持（即在访问我的网页时在页面上会冒出许多小广告）。这种行为对于一个有精神洁癖的处女座来说是无法原谅的——我不喜欢看到广告，更别说在自己的网站看到满天飞的小广告了。

然而，这还不是重点。重点是，有许多广告拦截插件在拦截这些小广告时，会将我要加载的JS文件也一并拦截掉。这种“误伤”问题还是十分严重的，已经影响到了我网站的正常访问。

为了解决上述问题，并且响应各浏览器安全性的号召。在Certbot的帮助下，我一咬牙将我所有的网站，包括Velas 以及 Velas Camp系，一并升级为HTTPS。（除了Velas Talk由于放在Github Page的缘故，无法对其升级；同时因为考虑到性能损耗问题，因此没有将Aurora默认重定向为HTTPS。但其实可以输入https://前缀来访为HTTPS版的Aurora）

什么是HTTPS？

HTTPS通过在HTTP的基础上加入了SSL协议，为HTTPS提供更安全、更有保障的通信连接。（以前常用于电子交易网站的安全加密）

支持了HTTPS之后对我有什么好处？

其实，目前除了Save Whales和Chat Room两个网站在HTTPS的加持下可以保证用户登陆/信息发送时更安全外，对其他网站的好处也只有防止运营商劫持。但是代价是换来了更长的连接时间与额外的（加密所需的）更多的性能占用。

当然放心，由于Velas目前只是一个很小的、没什么人访问的站点，因此这点开销还是比较值得的。同时，还换来了这把漂亮的小锁~

那为什么Velas的小锁上会有个感叹号？

这位同学你观察的真仔细！

这是由于Velas采用七牛云作为图床，而七牛云默认的传输接口是使用HTTP连接的。浏览器检测到这部分的传输不符合HTTPS的安全要求，因此对其发出了警告。当然请放心，这不会对您有任何影响。

我目前正寻找七牛云使用HTTPS传输的方法，以及其他支持HTTPS的图床。相信在不久的将来，我会把Velas的访问变为彻底的HTTPS连接。

全新的首页设计

在看过许多更为国际化的网站首页时，我发现Velas的首页设计虽然比较简洁大方，但终究还是空了一点。

于是我又一狠心将Velas的首页重新进行了调整。调整包括：引入了News、Talk、Camp以及时间胶囊的内容、并且优化了网站入口的访问方式。其中，News与Talk的内容都是实时从Github抓取数据进行生成的，同时我还为他们添加了非常有趣的过渡效果。

现在，你都可以在首页看到这些变化。希望你能喜欢😄 。

其他改进

• 重新设计了回到顶部按钮
• 为Velas增加了触屏事件监听
• 为Github数据抓取增加一些安全校验
• 将News文章的抓取方式改回抓取Issue列表