cgdb,gdb -tui的加强版,非常优秀,中文教程在此:https://github.com/leeyiw/cgdb-manual-in-chinese/blob/master/contents.md,不再赘述。

cgdb有一个问题困扰了我很久:如何方便地进行I/O交互。

虽然cgdb自带了TTY模式,但不太靠谱,调试到某些Unix I/O接口时会卡死,如read函数。

今天我又反复看了下教程,发现了这样一句以前没注意的忠告:

如果被调试的程序需要读取终端用户输入,我们推荐用户在终端中启动被调试程序,然后在另一个终端使用CGDB去attach被调试程序,这是与被调试程序进行I/O交互最简单的方法。

但是教程没有说具体该怎么操作,摸索了下,终于完美解决,以调试redis-cli为例。

  1. 命令行先后启动redis-server和redis-cli;
  2. ps查到redis-cli进程号后直接cgdb -p [pid];
  3. 进入cgdb后不要慌,用bt看下阻塞I/O在哪里;
  4. 然后在阻塞I/O处设置断点,可以看到这里在linenoise.c的312行调用了read(),直接加断点b linenoise.c:312;
  5. cgdb中输入continue,然后再去redis-cli那里输入想调试的命令,比如info,回到cgdb,发现源码已经刷出来了,大功告成。

一步一步打造Geek风格的技术博客

2013-08-17 by lizherui

如梦初醒


Geek是什么

Geek更多的是一种精神,一种态度,一种对技术的理解与信念。他们无法忍受丑陋的代码,拙劣的技术。他们思路开阔,技术娴熟,他们不甘平庸,追求完美。他们不会囿于常识,他们敢于突破。在常人眼中,他们不走寻常路,享受各种非主流的技术。但在他们自己眼中,这些又是那么得自然与优美。他们用自己的行为诠释着自己对于技术的理解,用那份固执传达着自己的信念。

他们掌握并热爱着技术,叛逆、执着,崇尚自由。

为什么不选择CSDN、Wordpress、Jekyll等技术

我在CSDN上发表博文被和谐了一次,就不会允许这种事发生第二次。

Wordpress上手容易、功能强大、插件丰富。但是在我看来,这些优点同时也是它的缺点:太笨重、太无脑、不够酷、无用功能太多、可定制的粒度不够小。我更喜欢简洁快速粗暴的博客系统。

Jekyll非常棒,可惜它基于Ruby。对于Python爱好者而言,基于Python的Pelican显然更加可口。

卧薪尝胆


我在搭建这个博客的过程中学到了很多很多有意思的技术。

搭建环境为Mac OS X/Linux ...

read more

为什么我一直强烈推荐程序员使用Mac OS X

2013-08-11 by lizherui

像绝大多数国内程序员一样,我在相当长的时间里对Mac OS X一无所知,最开始使用Windows进行开发,然后转到Linux。

去年11月我终于攒够钱了,决定试着从Linux转到Mac OS X,于是入手Macbook Pro,从此踏上了Mac OS X的道路,没想到一去不复返。

这一年来使用Mac OS X的经历,不仅极大地开拓了我的视野,而且在很大程度上改变了我对待软件开发的态度。当然了,最重要的是,它使我的开发效率有了质的提升。

Macintosh在国内的现状

Macintosh,即搭载着Mac OS X操作系统的苹果电脑,在国内的市场份额一直少得可怜,甚至在程序员这样的团体中亦是如此。

是因为Macintosh太贵了?还是因为Mac OS X不兼容Windows的一些软件?虽然这两条理由确实会打消广大普通用户购买Macintosh的念头,但是对于国内程序员来讲,这俩显然都不是问题。

那到底是什么原因阻碍了绝大多数国内程序员使用Mac OS X呢?

我仔细观察过这个事情很长时间,后来越来越明晰地发现,最根本的原因是绝大多数国内程序员完全都不知道Mac OS X是什么,更别提使用Mac OS X能给自己带来哪些好处了。

Mac ...

read more

编写可读代码的艺术

2013-08-08 by lizherui

我最早开始重视代码的可读性还是大三在搜狐做Python研发实习生的时候。那会儿我特别嫩,写代码还是学校大作业风格,天天被leader各种批评。现在回忆起来,虽然在搜狐呆的时间特别短,但那段经历能引起我对代码可读性的重视,也算是重量级的收获了。

今天一口气读完了《编写可读性代码的艺术》,感觉非常爽。我一直认为代码的可读性绝对是第一重要的,正如《黑客与画家》所言:"代码写出来是给人看的,附带着能在机器上运行"。

顺手记录了几个重要的原则:

  1. 可读性基本定理:代码的写法应当使别人理解它所需的时间最小化。

  2. 把信息装进名字里。

  3. 清晰和精确比装可爱好。

  4. 在小的作用域内可以使用短的名字。

  5. 不会误解的名字是最好的名字。

  6. 使用一致的布局;让相似的代码看上去相似;把相关的代码行分组,形成代码块。

  7. 一致的风格比正确的风格更重要。

  8. 注释的目的是尽量帮助读者了解得和作者一样多。

  9. 不要为那些从代码本身就能快速推断的事实写注释。

  10. 注释应该有很高的信息/空间率。

  11. 把条件、循环以及其他对控制流的改变做得越“自然”越好,使读者不用停下了重读你的代码。

  12. 默认情况下都用if/else,三目运算符?:只在最简单的情况下使用。

  13. 当你对代码改动时,从全新的角度审视它,把它作为一个整体来看待。

  14. 把超长表达式拆分出易于理解的小块。

  15. 小心“智能”的小代码段,它们往往在以后会让别人读起来很困惑 ...

read more

如何成为一名黑客(转)

2013-08-06 by lizherui

这是一份大名鼎鼎的黑客手册,来自Eric S. Raymond,我忍不住转存下来。

什么是黑客

Jargon File 包含了一大堆关于“hacker”这个词的定义,大部分与技术高超和热衷解决问题 及超越极限有关。但如果你只想知道如何 成为 一名黑客, 那么只有两件事情确实相关。

这可以追溯到几十年前第一台分时小型电脑诞生, ARPAnet 实验也刚展开的 年代,那时有一个由程序设计专家和网络名人所组成的, 具有分享特点的文化社群。 这种文化的成员创造了 “hacker” 这个名词。黑客们建立了 Internet。 黑客们发明出了现在使用的 UNIX 操作系统。黑客们使 Usenet 运作起来, 黑客们让 WWW 运转起来。如果你是这个文化的一部分,如果你对这种文化有所贡献,而且 这个社群的其它成员也认识你并称你为 hacker, 那么你就是一位黑客。

黑客精神并不仅仅局限在软件的黑客文化中。 有人用黑客态度对待其它事情,如电子学和音乐—— 事实上,你可以在任何最高级别的科学和艺术活动中发现它。 精于软件的黑客赞赏这些在其他领域的同类并把他们也称作黑客—— 有人宣称黑客天性是绝对独立于他们工作的特定领域的 ...

read more
Fork me on GitHub