[.... 省略部分 .... ]
我谈到了作为
validation engineer的一些想法，内容不外乎怎样得到develop engineer的一手信息，在多个engineering
release 和formal release 之间怎样减少重复劳动，怎样cover到每个product 的new
feature同时保证每次的routine
test，我想这些都是作为测试人员头痛的问题。但是作为测试人员，你不像开发人员那样只是涉及产品中的某个部分，至于它和其他component之间的
结合，以及integrate之后的问题或者整个产品的性能和功能实现就不是开发人员的职责了。QA更是站在用户的角度看待公司产品，它要求你在维护公司
的产品和作为用户的体验容忍度之间做出抉择。老大都希望一个qa可以做到拍着桌子同时应付好几个开发人员，你不仅仅是发现问题，发log而是透析问题，发
现原因，提出自己的看法，工作之间的信任度和尊重度就是这样建立起来的。我现在很喜欢的一种做事态度是，在和开发人员报bug解决问题的时候，要严肃，实
事求是，吃饭娱乐的时候应该打成一片。呵呵，这就说到测试人员，技术是硬标准，但是与人很好的沟通，大家愿意share自己的经验给你，这其实是一种更大
的财富。当然2者都需要日积月累。
来公司已经有很长一段时间了，但是我自己真正的长进是在最近一段时间里。
首先是一天早上我愣头愣脑地发了封mail告诉大家周末的stress
test的result时，我马上被我的头领到了办公司，进行了一次1：1。老大谈到了做事风格，想大家都和我一样的困惑，我以前的看法是开发给了
release后我再开发test
case，我当时的想法是我不知道release的版本实现了哪些功能，提前design是不是有些盲目。但是老大给我的建议是一个好的
validation engineer，要始终走在release之前，你的报告上永远是develop的进度block你的test
case执行。呵呵，我以前的report中只有pass和fail，现在多了block后，我更加意识到了自己工作的意义。（笑一下）---这是我认识
到自己的工作责任。
其次是我们组有个年轻的女生，她做测试已经了3年了。我观察了一下，她在负责一个新的项目测试的时候，是先根据source
code和feature list列出test要cover的test item，然后发出让develop和其他的team member
review，generate一个quality target。接着是test case的设计和调试阶段，形成test
framework，这是时间最长的阶段。补充test
cases.等到engineering的版后进行port。她会按部就班按照以前设计的qt完成整个test
project。这大致涵盖了一个测试流程。----这是我知道自己的做事流程。
最后一件小事，我昨天forward了封e-mail，大概的意思是告诉developer不光是这个人发现的问题a，我又发现了问题b。3分
钟后，我又被我们老大叫到了身边，说了写e-mail的技巧，告诉别人你的测试环境，你发现这个问题的前因后果。特别是经过了一个周末，可能没人记住上周
的-mail，有必要交待清楚你的确切情况。然后是weekly
report，在突出你的工作量的同时更要体现出你做这件事情的value和impact，这是很重要的。特别是validation
engineer，有时你要在多个项目之间进行测试，务必交待你的测试环境，这对重现bug相当重要。尽量用数字来体现这些，因为它们很直观。把该说的问
题说清楚，不清楚的问题弄清楚再说，免得被别人抓住尾巴。----这是做事的风格。
谈到和develop的合作技巧，我的原则是如果在双方时间许可的前提下，我倾向于采取face2face地交谈，这避免了很多言语上的误解，
特别是如果手头有实践环境还可以当场测试，得到证实。总之作为新人，大胆的同时要谦虚，每个人都有他的专长。我现在都很惧怕报cq，首先我不确定那是不是
bug，其次觉得小bug开发人员可能会不重视，或者这个本就是一个known
bug。我的老大给我的建议是不要害怕，发现问题即使它不是个问题，总比隐瞒他结果他是个问题要好很多很多。不是bug大不了close，没人会笑你。呵
呵，我是这么想的，脸皮厚吧。
记得我再和以前老大1:1的时候老大交给了我很多的技巧，比如猛夸develop,把他的老大add into mail
list，让他看到组员的工作成果，必要的时候也可以起到push的作用，我是这么理解的。你今天发现了很多问题，在不紧急地情况下，不要一股脑都
dump到开发人员的头上，然后拍屁股走人，你可以分批地发根据他解决问题的速度决定你报bug的速度，表现出对问题进展程度的关心，让别人觉得他不是孤
军奋战。还有其他很多。-----这是做事的技巧。
记得我老大1：1的时候告诉我，对我的沟通能力不怀疑，我还是要加强自己的技术能力，让自己说出的话更有底气。呵呵。
以前觉得自己不喜欢这行，现在发现和一群很实在的人为了一个共同的目标，交流合作学习，这件事情本身就让人非常的enjoy。
[... 省略部分 ...]
摘要: unix I/O 系列第2，write()
阅读全文
1 template<typename V,template<typename E, typename A = std::allocator<E>> class F>
2 class MyClass {};
上面这段代码声明了一个模板类MyClass。MyClass有两个类型参数typename V和class F，其中class F又是一个模板类。注意这种声明方式。
函数名：
read - 从文件描述字中读
摘要：
1 #include <unistd.h>
2
3 ssize_t read(int fd, void* buf, size_t cnt);
描述： read()试图从文件描述字fd中读取cnt字节到以buf开始的缓冲区中。
如果cnt为0，read()返回0并且buf中没有结果；如果cnt大于SSIZE_MAX，结果为定义。
返回值： 如果成功，返回读取的字节数`ret'（非负，0代表遇到了文件结束符），并且文件位置前移ret字节。如果ret<cnt并不代表出错；例如，这种情况可能是由于当前只有ret字节可用（可能是因为已经接近文件结束，或者因为我们正从管道或终端中读取），也可能由于read()被信号中断。如果出错，返回-1。在这种情况下，文件位置是否改变是未定义行为。
错误号： EINTR 该调用在读完数据之前被信号中断。
EAGAIN 用O_NONBLOCK选择了非阻塞模式I/O，但是当前没有数据可用。
EIO I/O错误。例如这种情况可能发生在当前进程为后台运行组，试图从它所控制的tty中读取，但是该终端为当前无效或者屏蔽了SIGTTIN信号又或者该终端进程为“孤儿进程”（orphan process)。 当从磁盘中读取数据时遇到底层I/O错误时，也会发生这种情况。
EISDIR fd引用了一个目录。
EBADF fd不是有效文件描述字，或者没有为读打开。
EINVAL fd引用了一个不支持读操作的设备。
EFAULT buf超出了可访问地址空间。
其他错误也会发生，这取决于fd所连接的设备。 POSIX允许read调用在读取部分数据后被信号中断后，或者返回-1（错误号被置为EINTR)，或者返回已经读取的字节数。
规范： SVr4, SVID, AT&T, POSIX, X/OPEN, BSD 4.3
约束：
在NFS文件系统中，读取小量数据只在第一次时更新时间戳，而后续调用不会更新。这是由客户端属性缓存（client side attribute caching)导致的，因为绝大多数NFS客户端让server维护atime（最后访问时间），而客户端read调用所产生的读操作没有造成server端的读操作从而也不会导致server更新atime。可以通过禁用客户端属性缓存以获得UNIX语义，但事实证明大多数情况下这会增加server负载并降低性能。
参考：
close(2), fcntl(2), ioctl(2), lseek(2), readdir(2), readlink(2), select(2), write(2), fread(3), readv(3)