分类 后端开发 下的文章

Wake-On-Lan程序解析

组装好NAS之后,我一直在考虑如何让其实现定时开机与关机,其中后者可以通过cron或者systemd-timer轻松解决,问题是开机,想到的方案主要有2个:

  1. 在机箱内安装一块Arduino/ESP开发板,配合时钟模块和锂电,定时接通PWR。
  2. 依靠网卡唤醒,也就是WOL(Wake-On-Lan),通过路由器实现定时唤醒(OpenWRT)。

对于我个人而言,2个方案都可以实现,但后者显然耗时更少,近期忙着毕业,没法抽出大段时间折腾。在编写LuCI插件过程中遇到了一点麻烦,单纯的cbi无法满足需求,所有这部分内容只能滞后了。

阅读剩余部分

持续集成框架buildbot初探

最近在写一个新程序,由于需要依赖平台相关的特性,因此每次提交前都需要手动在各种平台测试,令人十分苦恼。

好在,最近在实验室的一台主机上装了ESXi,虚拟出几个节点别提有多方便,所以CI也可以搞起了。

目前(一直以来)比较流行的CI有Jenkins,那就先从Buildbot开始吧。

阅读剩余部分

thrift 初探

读研以来,很少关注高层架构的变动,所以忽略了期间服务化趋势带来的一些变化。近期,在某厂的面试中就被问到了服务调度和容错。

目前,各厂基本都已进入了服务化的阶段,对于单节点的性能挖掘变得不再是那么迫切,服务调度、容错等问题才是焦点。之前通过开发服务器,基本掌握了Linux用户态的程序开发,但对于服务化方面的知识和经验,还是相当欠缺。

阅读剩余部分

使用docker-compose部署站点

比较早接触docker,也翻译过一些相关的文章,但坦白说平日里用的真心不多。

自2014年博客启用至今,出于对成本和性能的平衡,我已经对网站做了近20次的迁移。期间主要面临的问题是服务商提供的Linux发行版比较有限,且并未在所有平台(例如Xen)成功实施在线的发行版替换工作,由于平台的制约,运行环境无可避免地会出现不一致的情况,细节部分自然也难以统一,为此出过不少差错。

一般情况下,我是比较懒的,除非真正想要折腾,否则能拖就拖。而这次做出了docker化的决定,出于以下2点原因:

  1. 想折腾了,期望能够在部署、备份等环节尽可能实现自动化,最好能够实现闭环,这一切自然需要实践
  2. 近期有在规划重写整个站点将其转成一个SPA,采用MicroService彻底分离前后端,并使其跑在自己的server和framework之上

阅读剩余部分

C单元测试框架——cmocka

在自动化验证技术成熟之前,我们依旧需要测试,能否编写优秀的模块,体现的是能力,而为代码编写完善的测试用例,体现的则是习惯。

虽然测试并不能说明什么问题,但目前我们并无任何备选方案,相信在很长一段时间内,完善的测试用例对于项目而言都是弥足珍贵的。

有些时候会觉得编写测试用例太烦,但是要知道,至少我们还能通过测试用例来进行测试,有很多领域是无法通过如此“傻瓜式”的测试来达成目的的。

阅读剩余部分