Browsed by
标签:Unix

对技术的态度

对技术的态度

最近人品爆发,图灵社区,InfoQ,51CTO相继对我做了采访,前两天我把InfoQ对我的采访张贴了出来,今天,图灵社区和51CTO对我的采访发布了(图灵的访谈 ,51CTO的访谈),我是一个有技术焦虑症的人,我的经历比较特殊,对大家来说可能也没有什么意思,这两个采都有一些重叠的部分,不过有些观点我想再加强一些,并放在这里和大家一起分享一下。

对于日新月异的新技术,你是什么态度?

遇到新技术我会去了解,但不会把很大的精力放在这些技术(如:NoSQL,Node.js,等)。这些技术尚不成熟,只需要跟得住就可以了。技术十年以上可能是一个门槛。有人说技术更新换代很快,我一点儿都不觉得是这样想。虽然有不成熟的技术不断地涌出,但是成熟的技术,比如Unix,40多年,C,40多年,C++,30多年,TCP/IP,20多年,Java也有将近20年了……,所以,如果你着眼成熟的技术,其实并不多。

我的观点是——要了解技术就一定需要了解整个计算机的技术历史发展和进化路线。(这个观点,我在《程序员练级攻略》和《C++的坑多吗?》中提到过多次了。)因为,你要朝着球运动的轨迹去,而不是朝着球的位置去,要知道球的运动轨迹,你就需要知道它历史上是怎么跑的

如果要捋一个技术的脉络,70年代Unix的出现,是软件发展方面的一个里程碑,那个时期的C语言,也是语言方面的里程碑。(当时)所有的项目都在Unix/C上,全世界人都在用这两样东西写软件。Linux跟随的是Unix, Windows下的开发也是 C/C++。这时候出现的C++很自然就被大家接受了,企业级的系统很自然就会迁移到这上面,C++虽然接过了C的接力棒,但是它的问题是它没有一个企业方面的架构,而且太随意了,否则也不会有今天的Java。C++和C非常接近,它只不过是C的一个扩展,长年没有一个企业架构的框架。而Java在被发明后,被IBM把企业架构这部分的需求接了过来,J2EE的出现让C/C++捉襟见肘了,在语言进化上,还有Python/Ruby,后面还有了.NET,但可惜的是这只局限在Windows平台上。这些就是企业级软件方面语言层面就是C -> C++ -> Java这条主干,操作系统是Unix -> Linux/Windows这条主干,软件开发中需要了解的网络知识就是Ethernet -> IP -> TCP/UDP 这条主干。另外一条脉络就是互联网方面的(HTML/CSS/JS/LAMP…)。我是一个有技术忧虑症的人,这几条软件开发的主线一定不能放弃。

另外,从架构上来说,我们可以看到,

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (35 人打了分,平均分: 4.91 )
Loading...
一个fork的面试题

一个fork的面试题

前两天有人问了个关于Unix的fork()系统调用的面试题,这个题正好是我大约十年前找工作时某公司问我的一个题,我觉得比较有趣,写篇文章与大家分享一下。这个题是这样的:

题目:请问下面的程序一共输出多少个“-”?

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

int main(void)
{
   int i;
   for(i=0; i<2; i++){
      fork();
      printf("-");
   }

   wait(NULL);
   wait(NULL);

   return 0;
}

如果你对fork()的机制比较熟悉的话,这个题并不难,输出应该是6个“-”,但是,实际上这个程序会很tricky地输出8个“-”。

要讲清这个题,我们首先需要知道fork()系统调用的特性,

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (48 人打了分,平均分: 4.88 )
Loading...
28个Unix/Linux的命令行神器

28个Unix/Linux的命令行神器

下面是Kristóf Kovács收集的28个Unix/Linux下的28个命令行下的工具(原文链接),有一些是大家熟悉的,有一些是非常有用的,有一些是不为人知的。这些工具都非常不错,希望每个人都知道。本篇文章还在Hacker News上被讨论,你可以过去看看。我以作者的原文中加入了官网链接和一些说明。

dstat & sar

iostat, vmstat, ifstat 三合一的工具,用来查看系统性能(我在《性能调优攻略》中提到过那三个xxstat工具)。

官方网站:http://dag.wieers.com/rpm/packages/dstat/

你可以这样使用:

alias dstat='dstat -cdlmnpsy'

dstat screenshot

slurm

查看网络流量的一个工具

官方网站:  Simple Linux Utility for Resource Management

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (22 人打了分,平均分: 4.64 )
Loading...
少即是极多

少即是极多

感谢网友 @innocentim (Twitter) 投稿

这是一篇翻译练习。力图保留原意。若有不准确处,求速速指出。猛击此处(墙)看原文。作者为Rob Pike,贝尔实验室来的大牛,现在就职于Google。他主导了Go语言的创建工作。下面是正文——

——————————————正文分隔线——————————————

这是我在2012年6月的Go SF上演讲的文本。

这是一个个人演讲。 我承认,虽然面前的团队让Go诞生并延续,但是我的观点并不代表任何其他Go语言小组成员的意见。 我也想感谢Go SF的组织者提供这个和你们交流的机会。

几星期前我被问起:“你在推出Go的过程中遇到的最大的惊奇是什么?”我立即意识到了答案: 虽然我们希望C++程序员意识到Go是个较好的选择,但是令人意外的是,大多数Go程序员来自Python和Ruby这样的动态语言,而很少有来自C++的。

我们——Ken,Robert和我——是C++程序员(译者: Ken也用C++?),当时在为解决我们所写的这类软件产生的问题设计一个新的语言。 这似乎有点自相矛盾,因为别的C++程序员根本不关心这些问题,更不会去设计一个语言。

我今天想说的是关于那些激发我们创造Go的事情,和为什么它本不应令我们如此惊讶。 我保证这些内容更多与Go相关而不是C++,所以即使你不很了解C++你也能跟得上。

回答可以这样归结: 你认为”少即是多”呢,还是”少就是少”?

这里有个比喻,将以真实故事的形式给出。 贝尔实验室中心原来发放3位数号码: 物理研究是111,计算科学研究是127,如此这般。 1980年代早期,一个便笺飞过来说”鉴于你们对研究的理解有所加深,将为你们的号码多加上一位,以便更好地体现你们的工作”。 所以我们中心的号码变成了1127。 Ron Hardin半当真地开玩笑说如果我们真的理解我们的世界更好一点的话,我们将丢掉一位数字,将127变成27。 当然主管没听到这个笑话(这也不是我们希望的),但是我想这里面有点值得思考的东西。 少即是多。 你理解得越好,你将变得越简洁。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (27 人打了分,平均分: 4.67 )
Loading...
用Unix的设计思想来应对多变的需求

用Unix的设计思想来应对多变的需求

之前,@风枫峰 在“这是谁的错?”中说过开发团队对需求来者不拒,而@weidagang 也在“需求变更和IoC”中说过用IoC来最大程度地解决需求变更。今天我也想从Unix设计思想的角度来说说什么是好的软件设计,什么样的设计可以把需求变更对开发的影响降低。(注意:这并不能解决用户或是PM的无理需求,面对无理需求,需要仔细分析需求,而用技术的手段无法搞定这个事,但是可以减轻需求变更带来的痛苦) 我曾经在《Unix传奇》的下篇中写过一些Unix的设计哲学和思想(这里重点推荐大家看一下《The Art of Unix Programming》,我推荐过多次了),以前也发过一篇《一些软件设计的原则》,不过,这些东西都太多了,记不住。其实,这么多年来,我的经验告诉我,无论是Unix设计,还是面向对象设计,还是别的什么如SOA,ECB,消息,事件,MVC,网络七层模型,数据库设计,等等,他们都在干三件事——解耦,解耦,还是解耦所谓解耦,就是让软件的模块和模块间尽量少地依赖起来。

现实当中的例子

让我先举几个现实生活中的例子:

1、现实社会中,制造灯具的工厂完全不关心制造灯泡的工厂,制造灯泡的工厂完全不关心制造灯具的工厂,但是,灯泡和灯饰可以很完美地组合成用户所喜欢的样子(这和@weidagang 在“需求变更和IoC”说到的那个PC的例子相仿)。他们是怎么做到的?

2、互联网上,做网站的人完全不用关心用户在用什么样的操作系统,什么样的客户端浏览器(当然事实上,浏览器的不标准让网站那边很头痛,这里只是举个例),反过来,上网的人也不关心做网站的人在用什么的技术开发网站。但是大家在完全不关心对方的情况下,可以很正常地协同工作在一起。为什么?

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (31 人打了分,平均分: 4.87 )
Loading...
程序员技术练级攻略

程序员技术练级攻略

注:该文最新的版本在这里程序员技术练级攻略(2018版)(需要付费阅读)

月光博客6月12日发表了《写给新手程序员的一封信》,翻译自《An open letter to those who want to start programming》,我的朋友(他在本站的id是Mailper)告诉我,他希望在酷壳上看到一篇更具操作性的文章。因为他也是喜欢编程和技术的家伙,于是,我让他把他的一些学习Python和Web编程的一些点滴总结一下。于是他给我发来了一些他的心得和经历,我在把他的心得做了不多的增改,并根据我的经历增加了“进阶”一节。这是一篇由新手和我这个老家伙根据我们的经历完成的文章

我的这个朋友把这篇文章取名叫Build Your Programming Technical Skills,我实在不知道用中文怎么翻译,但我在写的过程中,我觉得这很像一个打网游做任务升级的一个过程,所以取名叫“技术练级攻略”,题目有点大,呵呵,这个标题纯粹是为了好玩这里仅仅是在分享Mailper和我个人的学习经历。(注:省去了我作为一个初学者曾经学习过的一些技术(今天明显过时了),如:Delphi/Power builder,也省去了我学过的一些我觉得没意思的技术Lotus Notes/ActiveX/COM/ADO/ATL/.NET ……)

前言

你是否觉得自己从学校毕业的时候只做过小玩具一样的程序?走入职场后哪怕没有什么经验也可以把以下这些课外练习走一遍(朋友的抱怨:学校课程总是从理论出发,作业项目都看不出有什么实际作用,不如从工作中的需求出发)

建议:

  • 不要乱买书,不要乱追新技术新名词,基础的东西经过很长时间积累而且还会在未来至少10年通用。
  • 回顾一下历史,看看历史上时间线上技术的发展,你才能明白明天会是什么样。
  • 一定要动手,例子不管多么简单,建议至少自己手敲一遍看看是否理解了里头的细枝末节。
  • 一定要学会思考,思考为什么要这样,而不是那样。还要举一反三地思考。

:你也许会很奇怪为什么下面的东西很偏Unix/Linux,这是因为我觉得Windows下的编程可能会在未来很没有前途,原因如下:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (283 人打了分,平均分: 4.81 )
Loading...
一些软件设计的原则

一些软件设计的原则

以前本站向大家介绍过一些软件开发的原则,比如优质代码的十诫Unix传奇(下篇)中所以说的UNIX的设计原则。相信大家从中能够从中学了解到一些设计原理方面的知识,正如我在《再谈“我是怎么招聘程序”》中所说的,一个好的程序员通常由其操作技能、知识水平,经验层力和能力四个方面组成。在这里想和大家说说设计中的一些原则,我认为这些东西属于长期经验总结出来的知识。这些原则,每一个程序员都应该了解。但是请不要教条主义,在使用的时候还是要多多考虑实际情况。其实,下面这些原则,不单单只是软件开发,可以推广到其它生产活动中,甚至我们的生活中

Don’t Repeat Yourself (DRY)

DRY 是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

参考http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Keep It Simple, Stupid (KISS)

KISS原则在设计上可能最被推崇的,在家装设计,界面设计 ,操作设计上,复杂的东西越来越被众人所BS了,而简单的东西越来越被人所认可,比如这些UI的设计和我们中国网页(尤其是新浪的网页)者是负面的例子。“宜家”(IKEA)简约、效率的家居设计、生产思路;“微软”(Microsoft)“所见即所得”的理念;“谷歌”(Google)简约、直接的商业风格,无一例外的遵循了“kiss”原则,也正是“kiss”原则,成就了这些看似神奇的商业经典。而苹果公司的iPhone/iPad将这个原则实践到了极至。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (26 人打了分,平均分: 5.00 )
Loading...
如何学好C语言

如何学好C语言

有人在酷壳的留言版上询问下面的问题

keep_walker :
今天晚上我看到这篇文章。
http://programmers.stackexchange.com/questions/62502/small-c-projects

我也遇到了和提问的老外一样的问题。。能给像遇到这样烦恼的程序员一点建议嘛?谢谢!

我相信,这可能是很多朋友的问题,我以前也有这样的感觉,编程编到一定的时候,发现能力到了瓶颈,既不深,也不扎实,半吊子。比如:你长期地使用Java和.NET ,这些有虚拟机的语言对于开发便利是便利,但是对于程序员来说可能并不太好,原因有两个:

  1. 虚拟机屏蔽了操作系统的系统调用,以及很多底层机制。
  2. 大量的封装好的类库也屏蔽了很多实现细节。

一段时间后,你会发现你知其然,不知所以然。。我以前在CSDN上写过一篇《Java NIO类库Selector机制解析(》,在那篇文章中我说提到过(有讥讽的语气)Java的程序员不懂底层实现,所以很难把技术学得更扎实。此时,一部分程序员会不自然地想学学底层的技术,很自然的,C语言就被提了上来。

下面是我给这位朋友的一些建议:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (123 人打了分,平均分: 4.86 )
Loading...
纯文本配置还是注册表

纯文本配置还是注册表

我们知道Unix/Linux下的程序配置文件从来都是纯文本的,你可以自由地修改和查看,他们也没有什么什么XML之类的玩意(参看XML的这两篇文章:),这个最重要的Unix文化(参看Unix传奇下篇)40多年来就这么沿续下来了。我很佩服Microsoft的创新能力,一会儿用INI,一会儿用注册表,一会又是用XML,这就是Windows的编程中那“强大”的创新。在网上又看到有人在争论为什么用注册表而不是纯文本,所以,写下这篇文章。

引入注册表所谓的原因

首先,让我们来看一下为什么微软觉得要使用注册表而不是ini文件,下面是一些其列出来的ini方面的毛病:

  • ini文件不支持Unicode
  • ini文件的安全权限不够
  • ini文件在多进程下存取会有问题
  • 如果一个进程锁上了这个文件,另一个进程就无法获得,只能出错。
  • ini文件只能包含字符串,无法使用二进制
  • 解析ini文件相对来说性能比较慢,第一次读写都需要把整个文件读入内存,然后再写回去。
  • ini文件最大只有32K
  • ini文件的默认目录在Windows系统目录下,只能这个目录只能Windows管理员才能访问
  • ini只能包含了两层,对于多层不支持。
  • 把ini文件放在中央服务器上管理很困难。

而微软说,注册表可以完美地解决这些问题。居然微软只说到了ini文件,但我觉得不单单是ini,所有的以纯文本方式保存配置文件的方法都会出现上述这样的问题。

我的观点

那么,当你在看到这些言论时,你是怎么想的?你有没有经过自己的独立思考?还是你觉得注册表完美地解决了所有的一切?下面是我的一些观点:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 4.35 )
Loading...
几篇技术文章

几篇技术文章

The Art of Unix

http://www.faqs.org/docs/artu/

Perl for Impatient Developer

http://blob.perl.org/books/impatient-perl/iperl.pdf

Game Development with Javascript

http://www.brighthub.com/hubfolio/matthew-casperson/blog/archive/2009/06/29/game-development-with-javascript-and-the-canvas-element.aspx

Introduction to x64 Assembly

http://software.intel.com/en-us/articles/introduction-to-x64-assembly/

Database Fundamental

https://www.ibm.com/developerworks/wikis/display/db2oncampus/FREE+ebook+-+Database+fundamentals

好烂啊有点差凑合看看还不错很精彩 (9 人打了分,平均分: 4.33 )
Loading...