与*NIX有关的杂志

本文介绍一些我接触过的与*nix有关的杂志。

首先要提到的就是Linux Journal(官方网址:http://www.linuxjournal.com/)。根据Wikipedia的介绍,这应该是最早的一本介绍Linux的杂志:

Linux Journal was the first magazine to be published about the Linux kernel and operating systems based on it. It was established in 1994.

不过Linux Journal现在不再发行纸质版了,只提供电子版。该杂志这段时间有一项促销活动:即截至到今年328日前,你只需花28.5美元(使用优惠码:2017ARCH可免10美元),就可以购买到从1994年到2016年杂志的电子合订版:

1

个人觉得还是很划算的,虽然有些文章已经年代久远,但是还是很有参考价值的。另外,Linux Journal也会将其文章发布到官网上供读者免费阅读。因次,是否愿意花钱买合订本或者订阅,就“仁者见仁,智者见智”了。

再说一下Linux Format(官方网址:http://www.linuxformat.com/)和Linux Voice(官方网址:https://www.linuxvoice.com/),二者都是英国出版的Linux杂志。不知是否因为Linux Voice的主创团队均出自Linux Format的缘故,二者有太多类似之处:都同时提供纸质版和电子版,都提供过刊的免费下载,等等。也许是由于版权原因,我在国内没见到过这两种杂志。在国外我阅读过纸质版,制作很精美,每期还附赠光盘。感兴趣的朋友可以下载它们提供的过刊了解一下。

以上提到的都是以Linux为主题的杂志,再介绍一个以BSD为主打内容的杂志:BSD magazine(官方网址:https://bsdmag.org/)。这是一本真正免费的杂志,订阅以后,你不需花一分钱,就会收到每一期。从这本杂志里,你可以获悉时下BSD家族的最新动态,虽然偶尔也会有Linux的内容出现。去年年底,这本杂志一度宣布要停刊了,不过目前又撤销了这个决定。我个人很希望这本杂志可以继续办下去。

最后,我很希望自己的国家能有一本中文版的Linux杂志。但是想想现在的情形,我们的时间都被其它的事物占去了,也许根本无法诞生这样一本杂志了。。。

后记:对于其它的类似杂志,比如:http://www.linux-magazine.com/。因为我没有一点了解,就不发表评论了。

HP/HPE公司的*nix操作系统

HP/HPE公司(即通常说的惠普公司,因其在2015年已经拆分成HPHPE两家独立运营公司,且拆分后是由HPE延续操作系统的相关工作,所以在这里使用HP/HPE。)拥有自己的Unix操作系统:HP-UX。以前中国是有团队参与HP-UX的相关工作:功能开发,Unix认证等等,现在相应的工作应该都转到印度了。目前HP-UX应该在一些银行,电信系统还在使用,不过的确是很难见到了。可以通过Wikipedia来了解HP-UX的一些信息。

再来说一下Linux,其实以前HP/HPE公司有一个很大的Linux团队,其甚至有能力做出自己的Linux发行版:

img_20161123_140305_hdr

此外,这个团队也曾经是Linux kernel的一个很重要的贡献者。不过,随着这些年公司的战略调整,这个团队的绝大部分工程师都已经离开了,其中的很多人加盟了其它公司,继续为Linux贡献着力量。目前HP/HPELinux上的工作重心侧重在同Linux厂商的合作,譬如今年与SuSE的合作(详情请参考Sweet SUSE! HPE snags itself a Linux distro)。

希望国内出版社多引进英文技术原版书

目前国内出版社引进的英文技术原版书太少了,大多数还是出版一些国人翻译的版本。我不知道直接引进原版书和找人翻译在成本方面有多大差距,但是凭心而论,很多翻译的书真是不敢恭维,不客气地讲,感觉有些翻译者似乎自己都没看明白原著的意思。毕竟目前很多先进的技术和经典的书籍都是从西方传过来的,也是用英文写的。读原汁原味的书,可以更准确地理解原著的意思,也可以提高自己的英文水平。所以真的很希望国内的出版社可以多引进文技术原版书!

如何组织一场技术沙龙?

从去年到现在,我参加了几次技术沙龙。其中有组织的很好的,也有不尽如人意的。在这篇文章里,我以举办一次Go语言话题分享为例,谈谈我个人觉得该如何办好一场技术沙龙。

(1)组织

首先说一下沙龙的组织者与参与者之间沟通形式的问题。现在是信息高度发达的互联网时代,对于组织者来说,不仅有像meetup这样专门发布聚会信息的网站,还有各种IM群来让大家讨论,献计献策。而在试用过这些五花八门的工具后,我个人倒是觉得,古老的邮件列表可能是最好的联系方式。原因有以下两点:

a)你现在所使用的IM工具也许在某一天会消失,但是电子邮件不会,它依然是现在世界范围内最广泛使用的沟通工具;
b)邮件列表可以很好地把信息和资料保存起来,方便将来查找。

选好沟通工具后,组织者就可以向大家征集与会议题并展开讨论了。同时组织者还要联系场地和赞助,比如说可以提供一些抽奖奖品或是纪念品等等。这些纪念品不用价值很昂贵,个人觉得一个马克杯,一件T恤,或是一个普通笔记本就可以了。此外,对提供场地和赞助的公司或个人,也可以在沙龙上进行一下适度的宣传或广告。毕竟人家提供了帮助,这样也可以提高赞助者们未来提供更多帮助的积极性。

接下来说一下时间的问题。举办一次沙龙还是比较耗费时间和精力的,所以2~3个月一次就可以了。举办时间最好安排在周六的下午,这样可以方便喜欢周末睡懒觉的朋友。选择周六另外一个原因是:第二天是周日,仍然休息,所以即使这一天弄得太晚,也不用担心明天早起上班。

(2)选题

一般的技术沙龙会安排3~4个小时,而这还包含参与者提问和中间休息的时间,所以我觉得安排4个选题就够了。

第一个选题是“暖场”作用,不一定非要技术相关。可以讲讲Go语言社区这段时间的动态,一些轶闻趣事等等,目的是把大家的兴趣和积极性调动起来。

第二、三个选题应该是和Go语言技术紧密相关的了,可以介绍Go语言的使用技巧和调试方法,当前有哪些比较好的Go语言开源项目,以及各个公司使用Go语言的经验分享等等。

最后一个选题可以是其它技术的话题分享:因为Go语言不是孤立的,而是和它运行的环境紧密结合的,所以可以讲讲Unix系统的知识,运维经验的分享等等。

(3)扫尾

开完沙龙后,大家要帮忙把会场打扫干净,这样将来赞助方才更愿意提供场地设施。组织者也要把一些资料及时地发出来,方便大家参考。

以上就是我个人对如何组织一场技术沙龙的一点拙见,希望能给大家一点帮助。

*NIX & Hacking —— 第4期

做一本我感兴趣的杂志,就这么简单!

Compiler

Notes on How Parsers and Compilers Work

Golang

GopherCon 2015 live blog
Testing in Go
Why does adding parentheses in if condition results in compile error?

Kernel

Choosing a Linux Tracer (2015)
Debugging by printing
Learning Kernel Programming
LTTng Packages now Available for Red Hat Enterprise Linux 7

Lua

Cloning a function in Lua

Network

Unit testing a TCP stack

Unix

Where the Unix philosophy breaks down

Easter egg

Starting from scratch: How do you build a world-class research lab?
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

不要招聘“性价比”高的工程师

以前在论坛看到一个帖子,发帖者抱怨自己招不到“性价比”高的工程师。当时没想什么,不过我后来仔细琢磨一下,感觉有点奇怪。为什么一个公司非要招聘“性价比”高的工程师呢?

所谓“性价比”,顾名思义,就是“性能”和“价格”的比值。“性能”越高,“价格”越低,性价比就越高。如果一个人每月工资是5000元,但他每个月为公司创造的价值相当于工资是800010000元的人创造的,那么这个人“性价比”就很高了。但是且慢,这样是不是对这个人不公平呢?当然,人就应该拿到和他能力匹配的工资。为什么公司非要招聘“性价比”高的工程师呢?“性价比”是1,或者性能和价格匹配就好了。谁都不是傻子,都知道自己有几斤几两。当他发现工资与自己的能力和价值相差太远时,或是降低工作效率,或是准备拍屁股走人,这样对公司有什么好处呢?开始以为招聘“性价比”高的工程师占了便宜,其实长远来看,还是吃亏的。据说有些公司还把招聘时压价格作为对招聘者的一个考评指标,想想真是可笑。 

不要考虑招聘“性价比”高的工程师的了,招聘一个“性价比”合适的工程师。

小评《理解Unix进程》

双“十一”期间参加CSDN活动,中了一本《理解Unix进程》,这两天花时间看完了。简单谈一下对这本书的的评价,谨代表个人意见。

这本书很薄,只有100来页,分为20章还有4节附录,这就表明每一章内容不是很多。书中的示例是用ruby语言写的,但是我相信大家都能看懂,不需要对ruby有很深的了解。总体来讲,这本书还是讲解了很多关于Unix的知识点,可以作为参考手册,或者可以在上下班的车上抽空读一读。不管是新手还是老兵,个人觉得都值得一看。价格也还好,20多元,应该不算贵。

另外,如果本身就是ruby程序员的,我非常推荐,应该会给你一些帮助!

提高个人能力的几个小建议

我是一名软件工程师,本文所提到的建议是我个人的一点心得体会,也许并不一定适合每个人,还望大家根据自身情况做出判断。

(1)拥有一个云笔记。两年以前,我还是习惯将日常工作的知识积累记在本上,但是我逐渐发现,随着笔记越积累越厚,想查找想要的内容并不是一件很容易的事,所以我开始把内容分门别类地记在云笔记上,这样查找起来就方便了很多。另外,我也会把搜索到的网页内容直接拷贝到笔记上,而不是只记录一个链接。这样即使将来网站关闭了,内容也被我保存下来了。

(2)创建自己的个人技术博客。当我在工作中遇到技术问题时,经常从别人的技术博客里找到答案。后来,我就想我的经验和知识也能帮助其他的人。于是,我也开始写自己的博客。其实写文章并不是一件很简单的事,很多内容你认为理解了,但真的提笔写下来的时候,才发现要表达清楚不是很容易。而且随着时间的流逝,发现自己写过的文章越来越多时,也是很有成就感的。目前很多人都有自己的域名,如果你嫌申请域名,搭建博客太麻烦,那么就找个口碑好的博客平台,注册个账号就可以了。但是博客一定要有,过个几年,你就知道这是一个多么正确的决定。

(3)多读英文技术文章。对于我们这些母语不是英文的人,坚持读英文技术文章是可以同时提高英文水平和技术能力的。毕竟目前先进的技术文档和书籍都是英文的,所以我们不仅不应该惧怕英文,而且还应该自己试着去写英文文章,这样才能让自己的文章被世界更多人的读到。此外,也可以订阅感兴趣领域专家的博客RSS。比如我对如何调试系统性能比较感兴趣,我就会订阅Brendan Gregg的博客,这样每当Brendan有新的文章发布时,我都会及时收到通知并阅读。

以上是我自己工作的一点心得体会,希望可以给大家一点帮助吧。

往GNU邮件组发邮件要用纯文本格式

昨天遇到gcc使用方面的一个问题,就往gcc-help(gcc-help@gcc.gnu.org)邮件组发了一封求助邮件。但是浏览归档(https://gcc.gnu.org/ml/gcc-help/)找不到我发的邮件,应该是没有发送成功。

今天在hellogcc的IRC里请教了一下,才知道应该用纯文本格式发送。我用的是QQ邮箱,没找到如何设置纯文本发送(后经好心网友发邮件提醒:在邮件编辑区之下的“其他选项”中勾选“纯文本”,就可以了)。于是就改用gmail的邮箱发送,果然一下就成功了。以后记住往GNU组织(包括gcc,gdb等所有的邮件组)发邮件一定要用纯文本格式。
P.S. 关于gmail如何使用纯文本发送邮件,可以参考这个链接:https://support.google.com/mail/answer/2645922?hl=zh-Hans

我心目中理想的软件开发过程

我心目中理想的软件开发过程是这样的:

(1)RD(程序员)写完一段代码后,会review两遍,这样很多基本的问题就都能被发现。在完成整块代码功能后,通过使用gdb等工具,改变程序的执行流程,以保证每个分支,每条语句都能执行一遍。在这个过程中,要检查变量的值和代码逻辑,看看是否和预期的一样。最后写测试用例,执行集成测试,确保不会出现很低级的bug;执行稳定性测试,确保程序可以长时间运行不出问题。在这一过程结束后,提交代码库,准备code review。

(2)QA(测试人员)在RD将代码提交到版本库后,开始review code,记下问题。然后在code review会议上,和RD讨论,把需要修改的地方记下来。接下来,设计测试用例,测试用例除了包含基本的功能测试和稳定性测试外,还要包含通过仔细阅读代码,找到可能出错的地方。最后进入测试阶段。