标签：技术杂谈

与*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现在不再发行纸质版了，只提供电子版。该杂志这段时间有一项促销活动：即截至到今年3月28日前，你只需花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年已经拆分成HP和HPE两家独立运营公司，且拆分后是由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/HPE在Linux上的工作重心侧重在同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）扫尾

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

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

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

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

所谓“性价比”，顾名思义，就是“性能”和“价格”的比值。“性能”越高，“价格”越低，性价比就越高。如果一个人每月工资是5000元，但他每个月为公司创造的价值相当于工资是8000或10000元的人创造的，那么这个人“性价比”就很高了。但是且慢，这样是不是对这个人不公平呢？当然，人就应该拿到和他能力匹配的工资。为什么公司非要招聘“性价比”高的工程师呢？“性价比”是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讨论，把需要修改的地方记下来。接下来，设计测试用例，测试用例除了包含基本的功能测试和稳定性测试外，还要包含通过仔细阅读代码，找到可能出错的地方。最后进入测试阶段。

关于知乎话题“程序员有哪些借口可以让自己写出低质量的代码？”的一点想法

以下是知乎上一个有趣话题：“程序员有哪些借口可以让自己写出低质量的代码？”得票最多的回答（原帖请参考这里：http://www.zhihu.com/question/24665029）：


关于这件事，网上有很多讨论，感兴趣的同学可以搜一下。我感兴趣的一点是：“离职之前老板大夸我厚道，最后一个月还给公司做了这么多的事情，别人走都是删代码，我居然还毫无保留的为公司做出贡献。”。我理解这个公司离职的员工删代码应该不是一个正常的代码维护，而是为了报复公司去删除有用的代码，否则老板也不会这样说。我好奇这个公司的员工为什么离职都会有报复公司的举动，我也经历了几家公司，但从来没有听说过这种行为。我没在这家公司工作过，所以不知道具体原因是什么。是不是所有经历过这家公司的人都应该反思一下，为什么会出现这种情况呢？也许答案并不简单。