闲侃两句“白板面试”

“白板面试”是一个老生常谈的问题了,关于它的利弊仁者见仁,智者见智。下面这些仅代表我个人观点:

(1)像GoogleFacebookAmazon这些公司对“白板面试”还是有很高要求的。如果目标是进入这些公司,那么没其它的选择,就得接受现实,刻苦“刷题”。
(2)有些公司连一句话都不和你说,直接发给你一个链接让你先做题,这种做法很不尊重人。
(3)安排“白板面试”的公司应该想清楚自己的需求是什么,可以从“白板面试”中考察到应聘者那些技能,“白板面试”是否真的适合自己公司?
(4)花时间练习“白板面试”对工程师有好处,但是“性价比”不太高。
(5)我参加过一些“白板面试”,失败居多。我记性不好,很多算法一段时间不用就忘了。在工作中我遇到忘记或不懂的算法就上网查,好像也从来没因为这个影响工作。

总结一下,如果“白板面试”是你心仪公司的“硬性要求”,或者你觉得花在“刷题”上的时间值得,那就多多练习;否则还是把时间用在其它的事情上面,比如读一本小说。

关于编写英文技术教程的一些总结

我从2016年中旬起开始尝试撰写英文技术教程,当时花了小半年写了一本Go语言的入门读物。2017年没动笔;2018年写了三本小册子,内容涉及并发编程,网络通讯等等。今年截至目前又完成一篇有关Linux操作系统性能监控的“小儿书”。现在回想起来,花在编写这些文档上的时间和精力还是相当值得的,我会把这项工作坚持下去。

当初开始这项工作的初衷是我这个人记性不好,学的东西过一段时间就忘了,因此我就打算以笔记的形式保存下来。使用英文的原因除了想锻炼一下自己的英语能力以外,也在想这些文字说不定也可以帮到别人。现在回头看看,收益最多的其实是我自己,比如这一年多来我经常在工作中参考我自己编写的OpenMP手册,:-);此外也很高兴自己的教程有时会被引用为stackoverflow答案。这项工作的另外一个“副产品”是为了弄懂一个知识点,我常常需要去阅读源码,也就会顺便发现bug并贡献patch,算是为开源社区尽自己一点微薄之力。

接下来我会继续编写一些英文技术教程,因为不是写小说,所以定的目标就是力求做到言简意赅,不拖泥带水,争取让读者们花最短的时间得到最核心的内容。

P.S.,我编写的英文教程链接

 

如何实现一个Linux性能监控工具

NmonLinux系统下一个简单但强大的性能监控工具。在新年的头一个月里,我花时间阅读了nmon的代码,总结了如何实现一个简单的Linux性能监控工具:

(1)获取性能数据。/proc文件系统是个宝库,你想要的信息几乎都可以从这里得到:
a)CPU利用率:/proc/stat
b)内存利用率:/proc/meminfo/proc/vmstat
c)磁盘利用率:/proc/diskstats
d)网络利用率:/proc/net/dev
e)单独进程的状态:/proc/[pid]目录;
f)其余感兴趣的信息:比如关于系统的负载状况,可以读取/proc/loadavg

(2)理解和解析数据。参考man手册,了解每一项数据的含义,必要时候可以阅读内核代码和学习相关的硬件知识。

(3)展示数据。Nmon使用的是“原始”的ncurses库,当然也可以使用“现代化”的GUI工具以达到更好的用户体验。

如果想进一步了解nmon内部的原理,也可参考我写的这本剖析nmon代码的小册子

2018年终总结

这一年没有离开过这座城市,也没有休过什么长假,基本都在工作。

工作上主要是C++/CUDA编程,一年做了两个大版本,也对modern C++有了更深入的了解。

业余时间写了三本教程:
OpenMP Little Book:介绍OpenMP并发编程;
Boost.Asio network programming little book:介绍C++网络编程;
OpenBSD netcat demystified:介绍netcat命令和Unix socket编程。

实现了三个开源小项目:
freeOpenBSD上的free命令;
ump:一个通用的线程安全的内存池;
libtlscpplibtlsC++封装。

上半年看了newlisp,下半年主要看Rust。此外,securityHigh Performance computing也关注的比较多。

这一年也看了不少和工作无关的书:从古典小说《红楼梦》,日本的悬疑小说,再到国产的爱情小说,都看了一些。

英文博客更新的还可以,中文写的有点少,明年争取多写一些。

技术会议参加的有点少,看看明年能不能多参加一些,自费也可以考虑。

生活上还是老样子,没什么变化。

就是这样了,看看明年自己有没有什么突破。

2018年11月总结

这个月比较简单,就是全力以赴朝八晚七的忙工作:写代码,做测试,优化性能。原本以为这个月全都完成,不过在今天下班前,还是发现了一个程序挂掉的问题。暂时没思路,看来只能把这个“小尾巴”带到下个月了。业余时间也就看看书,其它的也没什么。

使用uptime命令检查Unix系统的负载状况

Unix系统的uptime命令可以用来检查系统的负载状况。以Linux为例:

$ uptime
 01:32:50 up 40 days,  3:09, 56 users,  load average: 11.72, 11.67, 11.51

load average后面的3个值分别是系统在过去1515分钟负载的平均值(这里的负载包含3种进程:当前正在被CPU执行的,一切条件就绪等待CPU调度的,和等待磁盘读取结果的)。衡量当前系统是否“过载”,需要把load averageCPU的数量结合起来考虑。如果load average的值是1,并且当前系统上只有一个CPU(需要注意,这里的CPU指一个“逻辑CPU”,即需要考虑物理CPU有多个core,每个core支持hyper-thread的情况),那么系统在过去的时间就是“满负荷”运转的。但是如果系统上有4CPU,那么系统就只有1 / 4 = 25%的时间是忙碌的,其余75%是空闲的。

Linux系统的uptime读取/proc/loadavg文件:

$ cat /proc/loadavg
12.97 11.53 11.33 12/3958 7094

前三项对应uptimeload average的输出。第四项中斜线前面的是活跃的kernel进程(线程)数,后面则是系统所有的kernel进程(线程)数。最后一项是系统最新产生的进程ID

对于OpenBSD来说,由于其没有/proc文件系统。它的uptime实现则是通过sysctl系统调用读取vm.loadavg的值。