易栈网-膘叔

最近在使用phpQuery处理xml的时候发生了一点小问题。由于xml还算是比较规范，但我又不想用simplexml_load_string，所以就偷懒用phpQuery处理了。
但在处理的时候发现一个问题，比如我要处理的内容是：

请看加红的那一段。
当我用phpQuery处理完后，发现，右边的</link>不见了。其他元素都正常。我的心一下子就碎了。
开始以为页面有问题，但怎么处理都是这样，最终只能将link换成了url来 进行处理。说实话，心是哇凉哇凉的。。

但是，同事在win下面就没有这个问题，我在ubuntu下就有这个问题。（我现在不知道是否我的PHP版本有问题，还是平台的问题，也没有心思深究了）【同事是5.3.9，我是5.3.6】，

结对编程在我们现在的工作中真的没有使用这玩意。极限编程也没有用到，我们还是安稳的在一步一步的开发。。。但不代表我们没有尝试过。
其实，在07年的时候，那时候和一哥们就尝试过结对，效率确实上升了不少，但后来仔细想想，正由于两个人水平相近，这样的结对却没有真正带来了效率上升，反而还不如两个人单独开发，事后合并代码。虽然有一些BUG，但总体代码却多写了很多。再过了一段时间，也是和一朋友结对，但效率更低，因为两个人的水平不一致，水平高的受不了水平低的一些低级错误，水平低的却看不明白水平高的在做什么。痛苦。。。后来就放弃了这种想法。
以下是原文：http://www.cnbeta.com/articles/174866.htm
在过去的几年里，我有过许多结对编程的经历。有时在我的团队里进行，有时在客户那里，有时在coding dojo(一种编程模式，几个程序员一起合作完成一个任务)，有时在我的开源项目里。对于那些知道如何结对编程的程序员来说，这种模式很棒，很高效。
但是你不能指望在两个程序员面前摆台电脑，就指望他们一开始就做得很棒。结对编程需要学习，程序员需要知道实施者（敲键盘的人）和领航员之间的区别。下面来看看些细节。

在结对编程中，我遇到了一些误区，列在下面。
一、领航员误区
1. 发号施令者
喜欢发号施令的人总是对敲键盘的人说：“到末行，加个反括号，然后…”。他不去关注解决方法和下一步该怎么做，而过度关注一些编程细节。
事实上，他希望他自己来掌控键盘。所以当你碰到一个喜欢发号施令的人，那么将键盘交给他吧，转换领航员的角色。
2. 拼写纠错者
拼写纠错者坐在你旁边，纠正你输入的每个错误字符。当然，他没有时间来真正的进行导航。
和纠错者商量一下，当他给你纠错的时候让他请你喝一杯咖啡（或者任何你想要的东西）。
3. 吹毛求疵者
吹毛求疵者会指责你写的每行代码。当他的意见正确时，他会一意孤行，不用你已经写好的代码，而完全照着他的想法。
就如自由爵士音乐人都是复用其他乐队成员的音符，来构造成一首曲子一样，好的结对编程也应基于现有的基础上进行推进。
试着转换角色，也许吹毛求疵者就会变成一个目中无人的人。
4. 默不作声者
默不作声者是那些几乎不发表意见的人。他仅仅坐在那里看着你工作。
试着问下他对你的方法有什么意见，或者问他下一步该写什么测试代码。
5. 心不在焉者
心不在焉的人企图让你分心，而不是提供给你有建设性的意见，帮你解决问题。
那么让他离开吧，比起一个让自己分心的人而言，不如一个人编程。
二、实施者误区
1. 深藏不露者
深藏不露者仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码。关于该用什么方法，该选择哪种设计，领航员和实施者之间完全没有交流。
领航员需要问问深藏不露者关于他的计划或想法。
2. 目中无人的人
目中无人的人通常忽略领航员的所有建议，大多数是因为他们觉得自己的想法或编程技能更胜一筹。
当碰到一个目中无人的人时，立即停止结对编程吧，开始下一个任务吧。自大的人往往也不会是个好的领航员。他们很可能变成发号施令者或是吹毛求疵者。
3. 不知所措的人
不知所措的的人往往不习惯结对编程，非常紧张，不能掌控全局。
确保自己的领航员角色做到最好。小心的提出意见，对于不知所措的人主要给予鼓励。
但是，大多数程序员开始都是这种情况。所以，不要对他们的结对编程期望太高。让他们首先成为一个领航员，或者让能够很好的处理人际交往问题的领航员在他们旁边。
4. 跳跃性很大的人
跳跃很大的人喜欢在代码中进行大范围的跳跃，这样领航员不知道进行到哪里了。
领航员需要让他慢下来，问他关于他的计划，并确保自己比他知道更多的快捷键。
5. 不熟悉工具的人
不熟悉工具的人不知道开发环境的快捷键，效率非常低。
交换角色吧，让他看看你的技巧。或者打印一张印有快捷键的cheat sheet。
我相信还有其他的误区，如果你有什么想法请写在评论留言吧。
原文: planetgeek.ch  编译：伯乐在线
----EOF---
如果上面的事情真的是真的，那证明我们还是有问题，在结对编程的处理上。但我真不敢尝试了。哎

是的，你没有看错，这次的标准居然是一个URL。
如果尝试在IE下打开，可能你看到的页面都不正常，左下角的感叹号一定会让你震惊。嗯，你还是用Firefox或者Chrome(safari)打开看一下吧。
效果很多哦，很多特效可以让你感觉很爽。有一些效果你也可以尝试用到你的项目里。

---
最后插一个小广告，关于BitCoin(比特币)的事情，内容来自云风的BLOG，URL是：http://blog.codingnow.com/2011/05/bitcoin.html
--------
昨天读到了 Bitcoin 的中文介绍，觉得非常有意思。不过上面这篇文章解释的非常不靠谱，我花了一晚上去Bitcoin的官方网站 仔细研究了一下，总算理解了其原理。感觉非常有启发，尤其是对虚拟货币的流通和发行有许多借鉴意义。今天写这篇 Blog 理一下。
-------------
更多请看云风的BLOG，或者就看上面的链接bitcoin看一下这玩意的由来。

不记得从多久开始，我就在一直使用firefox了。

虽然从为一名WEB开发人员，不得不使用众多浏览器，但FF已经是我的默认浏览器。一般情况下，如果不是为了看网页效果或者使用网银，我是不会打开ie的。

其他的浏览器也纯粹是为了测试而使用。opera更多的是被我用来打开WAP网站，chrome则就是用来体验一下速度。（顺便说一下，chrome for ubuntu，居然不能输中文？好奇怪呀。。。。）

今天看到推送3.5，升级了一下，结果，打不开FF了。。

进程里也没有。。。

目前尚不清楚是因为插件的关系还是什么其他的关系。因为我有很多插件需要使用，暂时不做测试了。。。。

我也来个前言，架构这东西，研究的人越多，我能够做参考的也就越多，哇哈哈哈。不多说，贴copy来的文章，原文见博客园：http://www.cnblogs.com/micronet-lukey/archive/2009/04/14/1435520.html。

当然这个架构和我们传统意义上的WEB架构不太一样，但我想说的是这些问题还是可以作为一定的参考。比如我们在开发的时候，是直接上SVN还是采用传统的目录共享式开发。现在SVN已经成为很多项目开发所必备工具了，但如果我们在部署的时候采用SVN进行分发代码呢？审核关如何过？

程序员->发送到SVN服务器->SVN分发到测试组->测试组分发到正式机

这是一种解决方法，其实也有点象下文的图片。但实际操作中，当然不太会这样操作。不过也差不多是类似的方法。

让我注意的其实是文章的最后一句话。。。

前言：

       目前，公司的呼叫中心程序已经在中国的很多城市运行着。由于受到技术和网络环境的限制，这些呼叫中心程序安装实施完毕后，我们都是采取客户先反映问题，然后我们再安排人员时间进行维护。这种被动的维护机制带了很多问题。

目前存在的问题：

一：客户在描述问题的时候，并不能深入到系统的内部，往往只是描述了一个系统报错的现象。由于公司里已经没有当时的运行环境，在公司内很难做到故障重现，也就很难定位到故障的原因。系统维护和bug修补难度很大。

 二：呼叫中心的程序日志都是分散存放的。哪台计算机中的程序报错，就到那台电脑中找出错日志。这个过程必须人工干预。有时候，有些报错内容非常致命，但由于公司不能及时获取到这些信息，导致很多问题就像一颗定时炸弹一样无法及时排除。

 三：当公司更新了一个版本后，如果不能到现场维护，只能通过远程或者让客户代劳替换新程序。这种更新机制一旦遇到网络中断，或者客户不配合，将给维护工作带来很大障碍。如果由于需求变更较多，需要经常更新版本， 那么面临的问题将很难解决。

 解决的措施：

就第一和第二个问题，可以通过改进目前的日志记录方式来解决。通讯服务器接收客户端程序的错误日志。并且把这些日志内容打包成E_Mail邮件，定时发送到公司指定的邮箱中。

就第三个问题，可以通过自动更新服务来解决。维护人员把最新的软件更新包上传到客户端的通讯服务器中。客户端程序监测到有最新的软件更新包，可以自动更新。

解决问题的核心就是在客户那安装一台通讯服务器。这台通讯服务器既要能能够连接到Internet，同时还要和内部的服务器向连接。这台通讯服务器有两个作用：

1：发送各个程序的错误日志到公司的邮件。

2：接收公司上传的程序更新包，并自动通知各个客户端程序更新。

所有的工作都由服务器自动完成。

 总结：

       任 何一个系统，在现场部署完成，用户正式开始使用后，对于我们开发组来说，那只是万里长征走完了第一步，后期不断地查错，改进，更新，替换也会占用到大量的 人力物力，如果是外省的客户，跑一趟现场还会占用大量的财力。按照现在的技术能力和网络环境，我们完全可以通过技术手段，更高效地对各个系统进行维护。

维护的最高境界是：客户还没有发现问题，我们已经捕捉到bug并在后台悄悄地把程序更新了。