2020-08-22 blog

初步研究了一下keras的代码,收获还是蛮大的。
感觉keras最底层的地方其实是比较简单的,只不过就是充当了一个脚手架。(废话,这种中间框架本身就是脚手架啊)
而且这里面其实也会发现,有些实现可能我可以用最近学的设计模式来替代,或者优化。另外再加上这些天研究的轻量化,应该可以做一个比较轻量级的框架内核。


看了一下Code羊的视频,发现其实自己坚持写blog的习惯虽然是有,但是并没有什么总结性
也有一些趟坑的过程,不过也写得比较细碎

可能需要另外开一个新的分区吧,就叫技术?

那么现在的话,就是四个主要分区了

  • blog,也就是博客,每日写的一些感悟和心情什么的,类似于日记
  • talk,杂谈,与日记的区别是一篇文章不一定是同一天写的,可以不断修改,围绕某一个主题来写
  • todo,待办,也就是自己挖坑和填坑的记录
  • tech,技术,主要是记录一些搭建或者问题的解决方案,需要比较完整的细节记录,以及可复现性。

想了想,目前其实我可以写到技术分区的文章其实还是可以有很多的。在自己本地的markdown笔记也积累了一些解决方案。
可以整合一下写几篇文章什么的。
另外还包括最近在研究的keras源码解读,这个也可以是一篇很好的技术文章。
其他的,比如说什么网站部署啊、SSL啊这些之前趟过的坑,也都可以写。
甚至,包括HPE的研究,也可以写出来。
干脆就今天开始吧。


今天整理了一下我自己的hexo解决方案。
不过这一个解决方案跟先前的不太一样。
这个解决方案,是在服务器上面部署nginx和node.js,并且直接运行hexo server并且反代来当网站。
使用syncthing来同步文章的markdown文件。
这样的话,就可以在本地用Typora来写markdown,然后啥都不用做,等一会儿服务器上面也自动更新了。

而我之前的解决方案是:在服务器部署nginx,指向一个html文件夹。也是使用syncthing来更新。每次我在本地写完markdown之后,需要在本地先生成文件,然后再等待syncthing同步。
这需要多一步手动操作,显然是比较不方便的。

当然,目前的解决方案也不是特别完美。因为是直接用了hexo的server,并不是完全的静态文件,因此可能可以借助宝塔的定时任务,每天定时执行hexo c & hexo g,然后nginx指向生成的文件夹。


不过,去尝试写解决方案的文章,确实是会让人有更大的收获。因为要写一个比较可靠的解决方案的话,需要每一步都比较严谨,准确,最重要的是要保证整个流程可复现。
在这个过程中,有可能会遇到各种错误,或者各种情况,都需要自己去记录、处理。而这,会让自己去学更多的知识,或者技术。
这也可以说是输出倒逼输入吧。


使用了一段时间的WordPress,我的体验大概如下

  1. 主题虽然丰富多样,甚至可以自己写。但是好看又好用的主题,基本都是要花钱买的。自己写的话又要花费大量的时间精力,还不如去自己用python或者java手撸一个博客算了。
  2. Markdown需要使用第三方插件来编写,而且虽然右侧也有一个即时预览,但是跟没有差不多。因为右边显示的其实就是GitHub风格的Markdown渲染,但是这并不是真正的在网站上面显示的样子。这一点甚至不如我部署的wiki.js
  3. 非常神奇的文章id自增。每次修改版本都会使得id加一,从而导致明明我目前一百篇文章都不到,pid已经到了两百多快300了。当然,这个虽然算不上是缺点或者不足,但是就是看起来很奇怪。
  4. 不知道为什么,在这个WordPress的Markdown插件的编辑器上面输入文字的时候,微软的输入法候选词会挡住正在输入的字。这是真的非常让人恼火。
  5. 使用PHP。这一点虽然并不是缺点或者不足之处,但是对于我这个打算学Java后端技术的人来说,不免还是有点奇怪的。

总的来说,就是还是打算把WordPress换掉。
但是在换掉之前,还是需要去研究一下。
因为更换的成本太高了。就比如说把文章从本地迁移到WordPress,当时好像花了好多个小时,就更不用说探索排雷以及部署所花费的时间了。

虽然说,对于探索而言,目前我掌握了一个技术,那就是使用虚拟机排雷(这确实是非常方便的)


我发现,我给我自己挖坑的能力,真的是一流

You may also like...

发表评论

电子邮件地址不会被公开。 必填项已用*标注