补锅匠的小屋

Excerpt from “Computers，People and Programming”，chapter 1 of 《Programming--principles and practice using C++》

2011-12-01T18:37:00.001-08:00

General characteristics of software:
correctness,reliability,relevant,good designed,affordable and maintainability

Keep in mind features which can be appreciated from outside by non-programmers;

The structures of program must be such that other programmers who didn't write it can understand it and make changes to it.To be maintainable,a program must be simple relative to its requirements and code must directly represent the idears expressed.Complexity can be intrinsic to a problem, but can also arise from poor expressions of idear in code.

Programming is understanding. If we can program a task,we fully understand it.Conversely,we can see programming as part of the effort to thoroughly understand a problem.A program is a precise representation of our understanding of a topic.

4 stages of programming

analyze:what's the problem? what does the user want? what does the user need? what can the user afford? what reliability do they need?
design: how to solve the problem? what's the overall structure of the problem? which parts dose it consist of? How do they communicate with each other? How dose the system communicate with its user?
programming: express the solution of the problem in code. Write the code in a way that meet all the constraints(time,space,money,reliability and etc).The code must be correct and maintainable.
testing:make sure the system work correctly under all circumstances required by systematically trying it out.

We learn from experiences and modify our behaviour based on what we learn. So the crucial concept here is feedback.
Try to explain the design ideas to others before coding, no matter weather they know software and business or not.
And while coding, from time to time, to think about the problem, articulate the idears or problems to others.

Much of problem solving is recognizing a known problem and apply a known solution technique.

This book focuse on expressing idears clearly in code.

Structure and Interpretation of Computer Program初探

2011-11-15T00:46:00.001-08:00

本书是麻省理工计算机科学的入门级教材
昨天花了点时间读了序言和作者的两版前言，感觉只能看懂初版的前言，篇幅不长，几乎字字珠玑，摘录如下：

a computerlanguage is not just a way of getting a computer to perform operationsbut rather that it is a novel formal medium for expressing ideas aboutmethodology. Thus, programs must be written for people to read, andonly incidentally for machines to execute.
the essential material to be addressed by a subject at this level isnot the syntax of particular programming-language constructs, norclever algorithms for computing particular functions efficiently, noreven the mathematical analysis of algorithms and the foundations ofcomputing, but rather the techniques used to control the intellectualcomplexity of large software systems.
students should have command of the major techniques for controllingcomplexity in a large system.
``computer science'' is not a science and that its significance haslittle to do with computers. The computer revolution is a revolutionin the way we think and in the way we express what we think. Theessence of this change is the emergence of what might best be calledprocedural epistemology -- the study of the structure ofknowledge from an imperative point of view, as opposed to the moredeclarative point of view taken by classical mathematical subjects.Mathematics provides a framework for dealing precisely with notions of``what is.'' Computation provides a framework for dealing preciselywith notions of ``how to.''

所谓控制复杂度的主要技术包括：

We control complexity by building abstractions that hidedetails when appropriate.
We control complexity by establishingconventional interfaces that enable us to construct systems bycombining standard, well-understood pieces in a ``mix and match'' way.
We control complexity by establishing new languages for describing adesign, each of which emphasizes particular aspects of the design anddeemphasizes others.

几乎与目录中各章对应起来：

过程抽象
数据抽象、
模块、对象及状态
元语言（metalinguistic ？）抽象
用寄存器机器计算

从前言的字里行间，可以看出作者对LISP/Scheme的激赏；只是时至今日，该门课程所使用的语言已经换成了Python，由此可见，理论与现实间的差距还是巨大的。

该门课程的视频在这里。

C++之父的妙论

2011-11-11T00:44:00.001-08:00

因为喜欢pongba博客的缘故，去他csdn上的老巢拜访了一下；看了其中关于c++语言的几篇博文，颇有些旧情复炽。顺手捎带，拜读了Bill Venners对Bjarne Stroustroup的访谈（一共4部分），一读之下，惊为天人。
Bjarne的语言朴实无华，但是味道极深，有时需要慢慢品味，趁自己还记得住，赶紧贴几句：

Just because you don’t need OOP or GP for a project doesn’t imply that C is better for that.
"I wouldn't like to build a tool that could only do what I had been able to imagine for it."
Design tools don't give you much feedback, so therefore I tend towards the view that you should build a smaller system and grow it into a bigger one. There is a rule of thumb that says that every successful large system is a development of a slightly smaller working system. You apply that rule recursively.
"I wouldn't like to build a tool that could only do what I had been able to imagine for it."
To quote Kristen Nygaard, programming is understanding. The meaning is: if you don't understand something, you can't code it, and you gain understading trying to code it.

从访谈内容来看，在兼顾开发效率和运行效率上，c++似乎做得不错。

TAOCP Vol1 3rd Edtion 之蜻蜓点水

2011-11-09T23:48:00.000-08:00

阅读Knuth的书有一种愉悦感，即使是前言，即便仅限于前言；
老先生的技术水准当如泰山北斗，非我辈可以置喙，可贵的是：文笔清晰流畅，态度诚恳，间或还小幽默一句，读之不禁让人莞尔；
本书内容囊括非数值类算法分析中最为经典的部分，计划出7卷，目前出到第四卷（以分册形式）；
老先生写作本书的目的有二：

是对算法各领域的知识进行总结，属参考手册类（reference）
作为教材使用，配备了大量习题和答案（出乎我的意料）

全书总体结构如下

基本算法
半数值算法
排序和搜索
组合算法
句法算法
语言理论
编译器

前言特别指出：本书对读者的数学水平要求不高，掌握初等代数即可应付本书的大部分内容；此外，只对编程感兴趣的读者可将数学推导及证明略去不看，但要记住结论；pongba似乎不赞同这一说法；
可将本书第一卷视为3类教材的合集：数据结构、离散数学以及机器语言编程（是描述计算机体系结构、还是介绍MIX编程，还是兼而有之？存疑）

由前言后的流程图可知：本卷为必读卷，是后续各卷的基石，后续各卷则可独立阅读。

此外，本书的独特之处在于：算法描述采用的计算机语言为MIX（后续有MMIX，见第一卷第1分册），以一种虚拟计算机为模型构建，可谓胆大包天、匠心独具；回顾起来，这一抽象还真摆脱了对历史的依附。在其所罗列的6点理由中，我尤其对a与f印象深刻，a充分点出计算机语言在人与机器间所处的两难境地（虽然此处是站在机器和算法的角度来表述的，换言之，在语言的设计中，不是简单的选队、站队问题，而是复杂的折中、权衡问题）；f则是历史更迭的必然产物；

本书习题含有各种标记：0~50的分数、M/HM标记以及箭头

《Introduction to Algorithms 3rd Edition》结构初探

2011-11-02T19:49:00.000-07:00

从前言来看，作者的雄心很大：

自诩为“自助餐”和“大杂烩”，可成为大学任意学习阶段的教材（从本科的算法入门到研究生的算法设计）
算法手册

对读者的要求：

初具编程经验
具备一定数学知识（本书第1和第8部分的数学知识+初等代数知识）

特点：

内容丰富
注重数学证明和算法分析
采用伪代码，但强调：易于以其他计算机语言实现
内容的编排上，将问题域和算法设计技术混排
有专门的网站，同时公布了部分习题的答案
网上还有教学录像(2nd ed)和高手的学习笔记网站

《Algorithms 4th Edition》和《Algorithms in C++ 3rd Edition》结构初探

2011-11-01T20:02:00.000-07:00

以下内容根据两书的前言和目录进行总结
首先谈谈二者的共同点：
1、都声称罗列了计算机科学中最为重要的算法
2、数学内容有限（自含推导或标记为不在本书范围之内进行论述）
3、使用实际代码，而非伪代码
4、均有相关网站
再说说二者间的差异
1、按作者自己的表述，《algorithms》更适合作为入门教程；而《algorithms in C++》则更高级一些，可以适应多种教学(数据结构和算法导论、算法设计、甚至编程)和学习要求（作为参考大全）；
2、从目录上看，前者更聚焦，后者内容更多，范围更广
3、前者以java实现，后者以C++实现

后者前言中过于完美的自诩让我有点怀疑，还是深入以后再说吧。

结论：前者为阅读主线之一，后者作为参考；

《The Algorithm Design Manual》结构初探

2011-11-01T18:20:00.001-07:00

本书是“算法设计”方面的手册，分为两部分：
1、如何分析算法，如何设计算法
2、参考大全：针对现有算法问题按类别给出具体解法，附带的网址链接指向以各种计算机语言对算法的具体实现
作者强调：设计算法最为关键的环节在于建模
描述算法时采用：贴近解题者的思维方式，试错、调整，验证。。。，比之一般教材似乎更易于理解
对数学证明和推导只是非正式的讨论，尽可能多的采用真实代码（这两点似乎与Nutshell相似），另外强化了作业和练习
总结：似乎需要对算法和数学知识有一点了解，并非算法的入门书籍，可作为参考书籍，但不能作为阅读主线。

《algorithms in a nutshell》结构初探

2011-11-01T18:12:00.001-07:00

缘起：为了一偿学习算法的夙愿，把手头以算法为主题的书籍搜罗了一下，准备逐一研读一下各书的序言和目录，再着手制订具体的学习计划——初步的想法还是以各书为主线、相互穿插着进行主题阅读，同时结合读书笔记、习题和实际代码，以期达到好的效果；
具体书单如下：
Introduction to Algorithms 3rd Edition (CLRS)
Algorithms In A Nutshell
Algorithms in C++
Algorithms
The Art of Computer Programming
The Algorithm Design Manual
正文：
昨天阅读了Algorithms in A Nutshell的前言，浏览了其目录，试总结如下：
读者对象应为有经验的程序员，阅读目的有二：
1、发现解决问题的算法，或
2、改善现有算法性能
本书遵循原则有四：
1、本书试图针对程序员每天所面临的实际问题而提供以真实代码实现的真实算法；
2、将算法与实际问题分离
3、对数学点到为止，不做深究
4、提供性能测试方法，为算法性能的数学分析提供感性支持
本书分为4部分：
1、了解算法所需的数学知识导论
2、算法介绍（即本书主体部分）
3、进阶阅读：其它方法失效时的应对策略、方法论
4、性能测试方法

i386体系下Linux系统C语言与汇编的对应关系

2007-11-07T00:03:00.000-08:00

1、intel的i386堆栈在入栈时的栈顶寄存器sp是由高地址向低地址增长
2、c语言函数的局部变量，经过查阅汇编代码，实际是通过sp-x来分配，由基指针寄存器bp-n(n为偏移量)来定位存取的
3、main入口的堆栈排列（从高地址到低地址直至SP分别为：char **env, char **argv和int argc以及main的offset）
4、在c语言调用函数时，参数按从右至左的顺序入栈，即最左边的参数在栈顶（SP）

另外，这里是一篇好文章，gazette了不起！对c语言的main函数怎么在linux下面跑起来说得很透彻。

Learning Python 第2版读后乱谈

2007-08-28T01:31:00.000-07:00

应该说，书的构思还是很精致的，由简入繁，层层深入，对语言各种特点的理解也很准确（从作者的描述可以推断出他们对python实现源码是很熟悉的），描述地很细致，甚至到了琐碎的地步（也许掌握python就是要对这些细节都很了解），但是这也给我造成了一种印象：无聊，不引人入胜；无疑，这不是技术类书籍的必备要素，但一本500多页的书如果味同嚼蜡的话，读起来带来的痛苦可想而知。有时候，我在想python是不是该瘦身了，简化点功能，内涵（语言特性）少一些，外延（模块）大一点，让自己更容易上手、掌握，把繁杂的工作交给模块？也许作为一个通用的计算机语言，语言特性的繁复是不可避免的吧？当然，要不要掌握python所有主流的语言特性还是因人而异的，这也能算是python灵活性的一种体现吧。。。

python中递归import的问题

2007-08-07T08:01:00.000-07:00

见《learning Python》第2版18章288页的描述
个人感觉from在import中最好避免使用，虽然可以少敲几个字符，可是带来麻烦的可能性却非常高：1，递归 2，污染namespace,容易引起混淆
对于下述的例子：
recur1.py:
x=1
import recur2
y=2
print 'hello!'

recur2.py：
from recur1 import x
print 'hello from recur2!'
from recur1 import y

直接import recur1和直接运行recur2.py都会报错
直接import recur2和直接运行recur1.py却不会

记住：

无论import还是from都会触发对尚未执行的该module的执行，python可以容忍一个尚未完整的namespace，却绝对不能容忍对一个不完整namespace中未运行的变量的引用：这就是import和from为什么会因为递归而可能产生冲突的原因
运行一个程序和在该程序里面由于嵌套获递归的原因而重新import它是不同的，后者仍然需要被执行

Applying UML and Patterns 第五章

2007-05-16T00:24:00.000-07:00

演进化的需求
观点一：需求由模糊到清晰是个演进的过程
观点二：需求管理是发现、记录、组织和跟踪需求的系统性的方法
观点三：需求分类 FURPS+方法
观点四：UP的需求制品包括：用例模型、补充说明、术语表（包含数据字典的功能）、愿景描述、业务规则（通指凌驾于本应用系统之上的行业标准或法律法规）

问题：采用迭代的方法在国内的环境下会不会使需求膨胀，项目不受控的迭代下去？对于目前接到的项目可否考虑仅作为一次迭代？

Applying UML and Patterns第四章

2007-05-08T07:52:00.000-07:00

inception不是需求阶段

项目策划阶段要关注的事情：
在inception（初始）阶段，需要以受众（投资方、用户、开发方）为关注对象，对项目的整体愿景、范围、business case（侧重于成本、收益方面以及技术、组织可行性的分析报告）、需求（功能性和非功能性的）、可行性（技术、时间、资源（人、财、物）和市场等诸方面）、潜在风险及应对进行统筹考虑，达成共识，并决定项目是否继续实施；
做什么？需求、范围
为什么要做？愿景和business case
能做好吗？风险
怎么做？下次迭代的计划和对elaboration（细化）阶段时间、成本的粗略估计

本阶段制品（举例）：

共同愿景和business case（描述总体目标和制约）
用例模型（只对其中的%10做详细描述和分析，一般为文字形式）
补充需求说明（针对会影响整体架构的非功能性的需求）
术语（在业务领域与客户达成一致的手段之一）
风险列表和风险管理计划
原型和概念验证目的的代码（澄清需求和验证技术假设）
迭代计划（针对下一次迭代）
阶段计划和软件开发计划（对elaboration（细化）阶段时间、成本的粗略估计）
开发建议（对项目UP阶段和制品定制的描述）

要点：

只选择真正有价值的制品文档
制品在初始阶段是模糊的、粗略的，随着迭代而逐步精化
强调思考的过程而非文档
文档可考虑在项目间重用（为此，制品需采用统一命名）

Applying UML and Patterns 第三章

2007-05-06T00:36:00.000-07:00

Case Studies

本书的重点关注应用软件开发中的应用逻辑层的OOA/D，对UI层主要关注该层和其他层的接口设计；
本书在迭代式开发过程的描述中（三次迭代），层层深入，逐步引入分析和设计的相关主题；
本书的开发案例一个是POS机软件，一个是Monopoly游戏（类似于大富翁）；

Applying UML and Patterns 第二章

2007-05-04T07:54:00.000-07:00

Iterative,Evolutionary and Agile
本章论述了传统瀑布开发模式的严重缺陷，强调了迭代开发、敏捷开发的优势和重要性
为适应软件开发领域充满变数和难以预测的固有特性，迭代式开发出现了；
迭代式开发的每次迭代成果都是以最终实际产品的一个子集为实现目标，通过迭代与迭代之间不断向用户、出资方和设计者，编码人员以及测试人员等这些产品受众处收集反馈信息（诸如需求、设计、编码等方面的变化和改进要求），将这些变化纳入到后续的迭代过程中加以适应和实现；这样，每次迭代都是在上次迭代成果基础上的一次有价值的改进和递增，渐进式地逼近最终的真实需求和产品；
UP(统一过程)是迭代演进式开发的一种，具体分为4个阶段（phrases）,inception,elaboration,construction,transition，每个阶段都包含了由固定时间间隔（一般不超过6周）的多次迭代，每次迭代都涵盖软件开发的几乎每个领域（discipline），如业务建模、分析、设计、编码、测试、部署、配置管理以及项目管理等等；

inception，可行性研究阶段，并最终决定实施还是下马；
elaboration，每次迭代从用例中挑选对整体结构有重要意义的、最具商业价值的以及高风险的少量加以分析，并实现和测试这些用例中的关键部分（场景？），多次迭代后初步形成最终系统的架构雏形，规避了高风险因素，识别了大部分需求和作用范围，同时对项目有了更实际的估计；
construction，通过多次迭代逐步实现用例中其他低风险和相对简单的部分，并准备部署
transition，beta测试和部署

综上所述，UP是风险驱动和客户驱动的迭代式开发过程，首先解决的是软件系统架构性和高风险的部分；另外需要注意的是：

每个阶段中迭代对不同领域的关注程度是不同的，例如：elaboration阶段的迭代会侧重于业务建模、分析、设计，而construction阶段的迭代则会偏重于实现和测试多一些；
前面迭代开发中所强调的对反馈的收集和对变化的适应在上述4个阶段的迭代中是贯彻始终的

本书的结构是基于UP的，侧重于前两个阶段，并且elaboration的迭代为3次，每次侧重于分析设计的一个不同层次（为不同对象分配职责，运用模式设计，架构分析和框架设计）

敏捷建模：

必须建模
强调建模的意义是沟通和理解而非记录；
设计者即实现者；
团队设计
只对最复杂和困难的部分建模，简单直接的设计决定都延迟到编码时
同步设计不同的模型（比如同步设计某类的类图和序列图）

敏捷UP：

强调采用尽可能少但有价值的UP实践和工作制品；
采用敏捷建模；
需求和设计要在迭代和演进的过程中不断基于反馈去适应和实现；
没有详细的项目计划，只有大致的阶段计划（如里程碑，交付日期），但不包含具体演进到某个里程碑的具体步骤；只对下一个迭代做详细计划，且每次都基于上次迭代的反馈作出调整；

思考：

UP中架构性和高风险用例的挑选不好拿捏，书中也不打算给出这方面的实例
敏捷建模对编码人员的要求变高了，要求有设计能力，更多的所谓“简单”设计权力都下放到了编码期间；同时，由于对设计文档角色的弱化和建模覆盖面的缩小，对代码的可读性有了更高的要求，同时是不是需要加强注释的规范化？有没有技术上的可行性？doxygen？
收集反馈在迭代式开发中至关重要，我们的pp和reqm／rd人员需要说服用户去适应这种变化

升级ubuntu 7.04 问题

2007-05-03T01:03:00.000-07:00

我的本本原来跑的是ubuntu 6.06，要直接升级到7.04会有很大的风险，慎重起见，先在一个分区上直接装了7.04体验一下，新系统的速度给了我深刻的印象；不由自主地决定升级；

首先查阅文档，建议都是先升到6.10, 再从6.10升级到7.04；
升到6.10时，（update-manager -c）,升级程序提示删除一些程序包，我居然同意了，没想到删了很多我的最爱：mplayer、azureus、amule等等，很麻烦，害得我又补装了半天
升到7.04时(update-manager -d)，比较棘手的是azureus，总是跑一会就崩，再运行就怎么也起不来了；后来把java设成gcj就好了（ sudo update-alternatives --config java ），我还是倾向于sun的java，所以就改了azureus的shell，把java换成gcj版本的java
另一个问题就是grub，7.04的2.6.20的内核不知道怎么把分区认成/dev/sdax格式，而2.6.15版本则还是认hdx，这个很折腾人（主要是grub命令kernel的root参数设置），升级的时候给了一个uuid好像是为了解决这个问题的，可是在我的机器上面好像不灵，而且即使grub的menu.lst你设对了，还有个问题：checkfs在扫描/etc/fstab的时候会挂掉，因为fstab中分区的设备（hda或者sda）只能适应一种内核，如果下次启动的时候你换个内核就出事了（听起来没必要，是不是？我是因为vmware的缘故）
接着就是vmware了，升到7.04，vmware的module要重新生成，本来还想偷懒（向上面说的）用低版本的内核起，结果发现这个所谓的低版本也是6.10带过来的，对应的头文件在6.10的源里面都没有，而且这个该死的内核是用gcc4.03编译生成的，而目前机器里面只有4.04的gcc，vmware要求编译module和内核的编译器版本要严格匹配,同时头文件版本和内核版本也要完全相同，只好试试2.6.20的内核，编译器是4.10，和我机器上面的gcc版本匹配，头文件在源里面也有，可是vmware似乎还没有正式支持2.6.20的内核，幸亏这篇文章救了我，module顺利编译成功，我的windows虚拟机顺畅运转！

第5点具体做法我转载一下：

You need to -
* Make a backup of /usr/lib/vmware/modules/source/vmmon.tar
* Untar /usr/lib/vmware/modules/source/vmmon.tar into a temporary directory
* Modify vmmon-only/include/compat_kernel.h, and change:

#define __NR_compat_exit __NR_exit
static inline _syscall1(int, compat_exit, int, exit_code);

to:

#define __NR_compat_exit __NR_exit
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
static inline _syscall1(int, compat_exit, int, exit_code);
#endif

* Finally, tar the modified module source back up, and replace the vmmon.tar in /usr/lib/vmware/modules/source/

applying UML and patterns 第一章

2007-04-23T22:32:00.000-07:00

本书最重要的学习目标：为软件对象分配职责的技巧
OOA:需求分析，弄清楚需求或者要解决的问题，具体做法：分析和识别现实世界业务领域的对象和概念，do the right thing
OOD:提出满足需求的概念化的解决方案而非具体实现，具体做法：依据现实世界业务领域的对象和概念，识别出软件对象，围绕用例，找出方法和属性，do the thing right

OOA／D的大致步骤：

定义use case
定义业务模型
定义交互图
定义类图

其中，1，2属于OOA，3，4属于OOD;第3步，在初步确定软件类的前提下，围绕着用例找出相关的方法和属性，是行之有效的；

需要指出的是：在OOA和OOD中都可以借助UML来描述类或对象，这是容易引起混淆的地方！
为此，在本书中设定：业务领域内的类称为概念类，设计领域内的类称为软件类，实现代码中的类称为实现类；概念类是软件类产生的依据，但2者没有严格的对应关系，软件类的取舍由设计者基于实现和需求来权衡，但软件类的命名常与现实业务模型中的概念类相同或相近似，这主要是为了便于设计者或编程人员理解业务领域和设计之间的关系。

utf-8 和gbk，code page、显示乱码的思考

2007-02-24T05:47:00.000-08:00

utf-8是unicode的一种实现方式,为ubuntu linux所采用
code page是把非unicode字符和unicode字符集中字符对应起来的一个对照表，mount对vfat的选项就提供了code page
gbk主要是微软对code page的扩展（加入了存在于现实中而又没有被纳入GB2312的字符）
mount命令对vfat分区有一个iocharset选项，将其设置为utf8则意味着将8位字符转换为16位unicode编码时采用utf-8方式来实现
其实，code page和utf-8解决的是正常显示这个问题的两个方面：
iocharset处理的是8位字符编码在unicode环境下正常显示的问题
code page解决的是尚未被unicode纳入的某个区域字符在unicode环境下显示的问题（只是过渡！）
应该说，绝大多数汉字的unicode编码和gbk或者国标编码是重叠和一致的；但是由于实现方式的区别，（比如utf-8）也会影响最终的解码结果，从而会影响最终的显示

ubuntu紧急恢复

2007-02-24T04:51:00.000-08:00

下午在xp下面把本本的一个fat32分区删掉了，希望扩大ubuntu的硬盘空间；结果grub启动时报error code 22
恢复步骤如下：

从ubuntu 6.06 cd启动
在mnt目录下创建目录root，再把/dev/hdan这个原来的根设备mount起来
sudo -s
grub-install --root-directory=/mnt/root /dev/hda
reboot

重启后正常
问题的原因很可能是因为删除了一个分区后引发/dev/hdan的n序号混乱（我的原根分区设备hda8现在就变成hda7），导致grub找不到根目录设备和内核；但是奇怪的是，我的fstab配置文件还是调整前的样子，系统mount后却没有什么问题,至少根目录mount的正确，没有发现像grub那样的惨剧！
另外，Sisyphus建议了更简单的方法，当然是在grub的shell下
解决方法:使用grub的命令,首先 root (hdX,Y),然后 setup (hdX),hdX指的是grub安装的磁盘,一般是hd0,Y表示linux分区的位置,如你安装在hda5,那么Y=4.你还可以通过"cat (hdX,Y)/路径"查看磁盘上的文件.比如"cat (hd0,5)/boot/grub/menu.lst",查看启动配置.

学习unix和linux

2007-02-19T07:16:00.000-08:00

最近一直在学习linux和unix方面的各种工具，这篇准备专门记录这方面的事情，算是流水帐吧！2月19号从这里学到几个工具：strace/ltrace/hexdump

tar的-p开关，-C开关和-c以及-x开关
touch的-t开关与find配合的妙用
xargs 与find -exec的区别在于：前者知道其后的cmd最多可以带多少个参数，而后者一次只能一次操作一个参数,所以xargs可以有效降低命令执行的负载
xargs与find中-exec选项的区别在于前者可以一次操作x个参数（-nx）
处理带空格的文件名时，xargs会产生问题，因为其缺省分割符是空格，但gnu版本的-0选项与gnu版本find的-print0选项配合，可以以'\0'为分隔符，我试验了一下，的确如此，使用xargs的-d'\n'开关和find的-print 配合可以达到同样的目的；
xargs的-i选项指定由find传递过来参数在命令中的位置（缺省是在最后），参数本身由｛｝指代；
find的要点：
find就是一个逻辑表达式（由无数与／或／非组成）无论是筛选文件的一系列条件(如-name,-user,-newer,-inum...)还是相应的动作(-exec,-print,-ls,-xdev...)都是逻辑表达式的一部分，find会把指定路径下的文件逐一交给这一逻辑表达式来校验，遵从短路原则：对与操作，碰到第一个false就返回，否则继续校验；对或操作，碰到第一个true就返回，否则继续校验；对find程序本身而言，它是不区分条件和动作的；

find的-prune参数：
这是比较浑人的一个知识点，主要有两点含义：

总是返回true（当-depth参数存在时，本参数失效）
如果满足条件的文件是目录时，作为一个副作用，find会跳过目录内的内容（即使把-prune取反，如”! -prune“，还是这样！）

find . \! -type d -prune -o -ls这条命令的意图是列出当前目录下除目录外的所有类型，但实际输出为空，原因就是 "."也是个路径，由于prune的副作用，当前路径会被跳过，所以输出为空；
真正要达到愿意，需要这样：
find . -type d \! -name "." -prune -o -ls

-wholename参数不对"/"和"."作特殊处理，认为这是路径的自然组成部分，和-prune搭配，可以很好的忽略对一些目录层级内容（不包括这些目录本身）的处理！
例如：
find . -xdev -wholename "./download/*/pollini/*" -prune -o -ls |grep -i pollini
只会输出：
./download/Chopin/pollini
而该目录下的文件则被忽略，另外要指出，虽然中间的目录（Chopin）用*替代，但find还是顺利的找到，其实，目录层次再多点，全都用*替换，也没有问题！

code reading 读后小结

2007-02-12T22:29:00.000-08:00

早上终于把code reading看完，头绪很多，先把能想到的写下来，以后可以慢慢补充
看代码方面：

unix的一些工具软件一定要熟，像grep、find、sed、awk、perl，再有就是正则表达式
unix的编辑工具，vi、emacs

开发方面：

熟练掌握开发工具，如gcc／gdb／gprofile／splint／ctag／cvs／make／automake／autoconf。。。
算法：考虑结合算法导论的书／录像和算法c实现以及knuth的巨著好好补补算法和数据结构

从最后一章作者的尝试可以看出，挫折是必然的，想解决问题，平和积极的心态是关键

ubuntu6.06设置中棘手问题的解决方案

2007-02-05T19:49:00.000-08:00

最近在Sisyphus的鼓动下，终于把desktop迁移到linux下面，我选的是Ubuntu 6.06,下面是几个疑难问题的记录：
1、pptpconfig的配置问题,vpn远程拨号，需要两边linux的/etc/ppp下的配置严格匹配，尤其是认证方式，以我当前机器的认证机制，需要加入require chap,而图形界面下在加密的tab面板里面什么都不要选，而在其余面板的pppd选项配置应为mtu 1404，解决大文件传输失败的问题；
2、为解决ubuntu中iptables的配置问题（使用guarddog），nfs中debian系统配置需要固定的侦听端口：在Debian3.1下/etc/default/nfs-kernel-server中加入绑定端口的开关项，"-p xxxx"
3、在gnome图形界面下执行sudo的程序是gksudo
4、psi-translation好像有bug，安装后传输文件，psi就会崩溃
5、解决vfat和ntfs中文乱码的方法：mount -t vfat /dev/xxx /mnt/xxx -o codepage=936,iocharset=utf8，NTFS是mount -t ntfs /dev/xxx /mnt/xxx -o iocharset=utf8

《code reading》阅读笔记之四

2006-12-25T22:26:00.000-08:00

第六章：
大型软件开发项目的关注点：

编码规范
构建过程
测试流程
配置方法
版本控制
文档编写

gcc的-M选项可以产生源文件的详细依赖列表，包括头文件

给出了cvs的一些经典用法

项目特定工具的用法：

生成构建时的配置信息或makefile
生成源代码
生成文档
作为测试产品性能的测试包，还可以集成到makefile里面

待深入研究的有：

错误消息的管理策略：见参考文档
断言的使用：检查输入、输出、前置、后置条件的合法性，编写测试用例
域语言的引入：见参考文档
cvs中关键字的使用

乱花渐欲迷人眼，浅草才能没马蹄！

《code reading》阅读笔记之三

2006-11-27T22:05:00.000-08:00

第四章，C数据结构

警惕for循环体内部对循环条件变量的操作；
使用memset之类的函数时，对所操作内存的字节数最好不使用常量而使用sizeof;
使用memcpy函数时，源和目的内存重叠或者源和目的内存的类型不符时，其结果未定义，使用前必须额外验证已避免此类情况；同时，结合第2点，sizeof的参数应该取目的地址
尽量避免使用gets/strcpy/strcat/sprintf/vsprintf（容易导致缓存溢出的错误），用fgets/strncpy/strncat/snprintf/vsnprintf替换；
在循环的实现中，对范围采用不对称边界的校验策略，即包括下限（＝），小于上限
c语言中指针的一种用法很是让我惊奇：用指针当数组用：struct vcol *pv = malloc(n*sizeof(struct vcol));cnt=pv[xx].cnt;除了在内存中的实际分配机理与数组不同之外，如果在栈中直接声明该结构的数组的话，cnt=pv[xx].cnt;这句在不同的情况下功能完全一样哦！而动态分配的情况下pv+=xx;cnt=pv->cnt;和上面那句话的作用也一样！换言之，动态分配的内存指针所指向的实际结构可以用数组形式来表征和操作（*就用一维数组来表征，**就用二维数组来表征,以此类推...）；
栈，LIFO，经常用来处理语言中的括号匹配／undo命令／中断；
抽象数据类型，ADT，通过提供一组接口将具体实现和使用隔离开来，对栈来说，重要的属性是栈指针：表明下一个要入栈或出栈（注意：二者是不同的！）的元素在栈中的位置，栈操作要注意的一个问题就是上溢出和下溢出；
队列，FIFO，经常用来处理两个软件系统间的交互（如gui应用程序和window系统之间、操作系统和收到的网络数据包之间）以及软硬件系统间的交互（网卡、硬盘、打印机的请求和操作系统之间）；基本操作有两个：出队和入队；基本属性有两个：头指针（指向出队元素）和尾指针（指向入队元素）；出队和入队时需要防止两种溢出：入队时的上溢出（队列满状态，针对数组实现，即尾指针＋1＝头指针），出队时的下溢出（队列空，即头尾指针相同）
maps：在能预先确定内容和数量的前提下，map可以用基于下标的数组来实现，以追求高的存取效率；提到了表格驱动编程，来避免大量的if；如用包含key和函数指针的数据结构数组来作字典，通过key的匹配来调用不同的函数（简单一点的可以省略函数指针，但一样是流程化的操作）；另外，数组包含元素的数量可以用sizeof(x)/sizeof(x[0])来表示，这是一个编译时已经确定的常量；
hash:对一动态集合，要求支持三种操作：插入、删除和搜索；当集合内元素少时，可直接采用数组实现；当集合的可能元素数量相当巨大时，需要运用hash函数产生键，去确定相应值；这样做的目的是用经济的空间以较小的代价来存取元素；hash要避免或者解决的问题是碰撞：即两个元素产生同一个键；
C语言的隐喻：a>>3等同于a/8; a<<3等同于a*8;a & 7等同于a%8;
对图而言，一直没有统一的实现，经常的实现方式有指针数组、链表等;鉴于在遍历图的元素时可能会出现循环，一个避免的手段时对已经访问过的节点置“已访问”的标志；

《code reading》阅读笔记之二

2006-11-26T22:02:00.000-08:00

第三章：

volatile：表示该变量会被本程序之外的实体所使用，避免编译器对其存取操作做优化
char* a和char p[]的区别，p即代表该字符串的首地址，没有为其分配内存，只是一种表征；而a是被分配的一个内存单元，其内容是一个指向某字符串的指针；
gdb中x后跟的参数是地址，即后面所跟表达式的内容被当作地址，打印的是内存中该地址处包含的内容（视格式不同）
struct中对bit field的应用，多半与硬件有关，还需要考虑大小编码的问题，即在内存中分布的问题：intel为小编码（little endian），高位在高地址（8位一个单位），低位在低地址，例如：0x12345678在内存中按地址从低到高排列的顺序应该是78 56 34 12；反之，大编码（big endian）如ibm power risc和motorola的cpu，则是高位在低地址，低位在高地址，在内存中按地址由低地址到高地址的排列应该是12 34 56 78
union的应用之一：对同一组数据用两种方式来解释

《code reading》阅读笔记之一

2006-11-23T17:22:00.000-08:00

开始读第二章了，值得关注的有：

编译器的告警开关全部打开，且对告警信息按照错误处理（gcc还有些告警选项是在优化开关打开后才能生效，如警告使用了未初始化的变量就是这种情况，即使使用了-Wall也没用；我暂时得出的结论是打开-Wall -Wuninitialized -Werror -O1 -g会比较严谨；注意，gcc允许既带调试信息，同时加以优化！intel的编译器没有上述问题）
使用支持语言语法加亮的编辑器，更早的暴露代码的问题
代码的排版很重要，可以采用indent之类的工具，但对一些具体问题（如8个？的解决方案），可考虑手工排版:越是复杂的语句，越要使语句的主干得到清晰的展现
变量的命名能反映其实际含义
熟悉了一下gdb的使用，常用命令file,run,info breakpint,breakpoint n,print v,watch v,list,enable n（断点号）,clear n(行号)，next，step，x;
不理解为什么netbsd的二分法查询这么别扭，下面的代码可读性更好（参考R Sedgewick Algorithms in C，被注释掉的是原来的实现）

int main(int argc, char *argv[])
{
int * pi,pl,pr;
int * pbase;
int i[10]={0,1,2,3,4,5,6,7,8,9};
int lim=10;
int key;
pl=pbase=i;
pr=lim-1;

key=atoi(argv[1]);

while (pr>=pl){
int m=(pr+pl)/2;
int cur_value=*(i+m);
if (key == cur_value){
printf("at index %d found value %d\n",m,key);
return 0;
}
if (key > cur_value)
pl=m+1;
else
pr=m-1;
}
/*for (;lim!=0;lim>>=1)
{
pi=pbase+(lim>>1);
printf("lim value is %d\n",lim);
if (*pi==key){
printf("at index %d got %d!\n",(pi-i),key);
return;
}
if (key>*pi){
pbase=pi+1; 虽然结果正确，可惜看不懂
lim--;
}

}*/
printf("not got u!\n");
return 0;
}

大师的召唤

2006-10-13T02:03:00.000-07:00

在slashdot上偶然听说了位老兄的blog，这位仁兄给大师们发了份mail，上面是些他感兴趣的问题。居然都回了：虽然有的回复有些心不在焉，可绝大部分答案还是保持了高水准，我把回答简单翻译了一下，做了个表格在这里，有兴趣的可以去看看。
从这份答案里，我总结了些成为优秀程序员的必备素质，虽然我的理解不一定准确，也不一定能做到，但这毕竟是目标：

有热情，投入、专注
掌握离散数学
良好的沟通技巧（书面和口头）
思维清晰；强烈的价值观，分清事情的轻重缓急，洞悉事务的关键所在，并能简化复杂的问题

推荐的好书：
SCIP
K&R C编程语言
编程珠玑
目前使用的工具：
操作系统：Unix
解释型语言：ruby、python、perl、LISP、TCL、Lua、Awk、Bash、make
开发语言：Java
编辑器：Emacs vim Netbeans
版本控制：svn/cvs
数据库：mysql postgre
浏览器：firefox
排版工具：TextMate/TEX

自我感觉需要掌握的还有：算法、数据结构、C/C++

O_APPEND/lseek/pwrite

2006-09-27T00:57:00.000-07:00

在读Marc Rochkind的Advanced Unix Programming(AUP),2.14节在描述pwrite和O_APPEND的时候，觉得简单了一点:
如果以O_APPEND打开文件，pwrite的行为和write完全一致，offset参数完全被忽略
但是，文件描述符指向的文件描述中的实际偏移呢？由于参数offset和实际偏移都用了英文offset表述，我产生了混淆，写了个程序e，测试了一下：
#include < unistd.h >
#include < sys/types.h >
#include < fcntl.h >
#include < errno.h >
#include < sys/stat.h >
#include < stdlib.h >

int main(int argc,char* argv[])
{
int fd;
off_t where;
ssize_t size;
if ((fd=open("tt",O_WRONLY|O_APPEND))==-1){
perror("open failed!");
exit(-1);
}
if ((where=lseek(fd,0,SEEK_CUR))==-1){
perror("lseek failed!");
exit(-1);
}
printf("current pos is %ld\n",where);
if ((size=pwrite(fd,"0123456789",10,0))==-1){
perror("write failed!");
exit(-1);
}
if ((where=lseek(fd,0,SEEK_CUR))==-1){
perror("lseek failed!");
exit(-1);
}
printf("current pos is %ld\n",where);
exit(0);
}
设tt是个含0123456789\n的字符文件，在linux和aix环境中其结果如下
#cat tt
0123456789
#./e
current pos is 0
current pos is 0
#cat tt
0123456789
0123456789#
据此得出的结论：
1、即使以O_APPEND方式打开文件，文件描述符指向的当前偏移位置仍为0，只是write在操作这种文件时隐含调用了lseek将文件偏移位置移至文件尾部
2、pwrite在操作以O_APPEND方式打开的文件时，与write一样，从尾部开始写，同时，pwrite的offset参数不起任何作用，且文件描述符指向的当前偏移位置也不受任何影响
如果将
if ((size=pwrite(fd,"0123456789",10,0))==-1){
改成
if ((size=write(fd,"0123456789",10))==-1){
起结果为
#cat tt
0123456789
#./e
current pos is 0
current pos is 21
#cat tt
0123456789
0123456789#
印证了结论1

EOF是什么？

2006-09-25T05:26:00.000-07:00

和同事讨论起一个问题：什么是EOF？
也许你会说：表示文件结束呗！是的，可是它是什么，一个状态？一个文件尾部的特殊字符？或者一个控制符？（不管在unix还是dos下，大家都有输入时按Ctrl+d或者Ctrl+z的经历吧？）
维基给的定义如下：In computing, end-of-file, commonly abbreviated EOF, is a condition in a computer operating system where no more data can be read from a data source. The data source is usually called a file or stream.－－是种情况或者状态，操作系统不能从文件或者流里再读出数据；
是附着在文件尾部的一个特殊字符嘛？应该不是：
unix下创建个小文件t，包含数字0～9，ls -l 看到字节长度为11，od -ch t,结果如下：
0000000 0 1 2 3 4 5 6 7 8 9 \n \0
3130 3332 3534 3736 3938 000a
0000013
dos下的copy con也是一样，ultraeditor二进制看一下，也没有多余的其他字符。

问题是：谁通知的？EOF是谁提出的概念呢？
我的理解：EOF是C Standard Library提出的，对系统调用来说，不存在这一概念，是标准c库对系统调用的封装，用来通知应用程序；比如：当输入中出现EOF的时候，就通知程序已经到达了文件的尾部；EOF本身不会被看作文件的最后一个字节而被写入文件本身或者读到内存中；
至于ctrl+d和ctrl+z不过是shell和cmd对输入中流结束的约定罢了（glibc对EOF的定义为“-1”）

SUS3在对系统调用read的规范里描述说：
No data transfer shall occur past the current end-of-file. If the starting position is at or after the end-of-file, 0 shall be returned.
在glibc2.4对fread的实现里，有如下代码（摘自glibc-2.4/libio/fileops.c中1452行函数_IO_file_xsgetn）：
count = _IO_SYSREAD (fp, s, count);
if (count <= 0) { if (count == 0) fp->_flags |= _IO_EOF_SEEN;
else
fp->_flags |= _IO_ERR_SEEN;

break;
}
其中的_IO_SYSREAD可以理解为系统调用read，与SUS3的规范相互印证，EOF是种状态，无数据可读了，就把fp的状态置成_IO_EOF_SEEN，即到达文件尾部。

（）的厉害！

2006-09-24T19:41:00.000-07:00

昨天用C语言写了个程序，老是报错，程序是这样的

2 #include < unistd.h >
3 #include < sys/types.h >
4 #include < fcntl.h >
5 #include < errno.h >
6 #include < sys/stat.h >
7 #include < stdlib.h >

9 int main(int argc, char* argv[])
10 {
11 int fd;
12 off_t where;
13 char c;
15 if ((fd=open("tt",O_RDONLY)==-1))
16 {
17 printf("sth wrong while opening file!\n");
18 exit(-1);
19 }
25 if ((where = lseek(fd, 1, SEEK_CUR)==-1))
26 {
27 perror("lseek failed!");
28 exit(-1);
29 }
30 printf("current pos is %ld\n",where);
31 exit(0);
32 }

编译好运行的时候输出从25行的分支出去了，老是“lseek failed！”顺便声明，文件是存在的哦，用gdb调试，15行的fd打开后为0，就是stdin，看来看去，才发现是==比＝的优先级高，而我的括号又打错了地方，实际上是15行和25行都写错了，正确的写法是：
15 if ((fd=open("tt",O_RDONLY))==-1)
25 if ((where = lseek(fd, 1, SEEK_CUR))==-1)

c语言总是认为你是正确的，而往往你不是这样 :)

开张手记

2006-09-04T23:28:00.000-07:00

折腾了好长时间，决定在这给自己安个小窝，记录一下自己学习和生活的一些事情，希望一切会更好！