当年毛主席号召知识青年要到农村去，那里有广阔的天地，可以大有作为。
昨天到了广州新沙港，开始准备项目验收。
今天小梁说地磅拍照那块会出现照片是绿屏的情况。然后大家开始坐在一起“猜”，到底是怎么回事？
如果是程序的问题，那为什么大多数情况下都是没有问题的呢？而且有时是某一个班次都会出现这种现象，等到一下个班次就好了。lulu说刘老师认为可能是由于显存问题，因为地磅员使用的电脑是集成显卡，这样就可能造成其他程序运行时抢占了共享显存，导致了绿屏。而由于每换一个班次都要重启一次电脑，因此下一个班次就没有这个问题了。我听了也觉得很有道理。
中午吃完饭我去场区散步，不知不觉来到了三号磅，看到里面有人就进去了，这时她正开着我们的系统，我就点了一下“添加地磅单”，结果报错“串口打开失败”，点了“确定”之后，又弹出“初始化DSP失败”。然后弹出了地磅称量的界面。这一块是我开发的，我当然知道出现刚才的错误将会导致视频加载失败，这时点击称量，当然不会拍照成功了。之后我注意到一个细节，就是这个地磅员打开了两个系统，而且另一个也打开了“添加地磅单”这个界面。然后我就叫她把两个系统都关了，然后再把打开两个系统，点击其中一个的添加地磅单按钮，没有报错；打开另一个时，就出现了刚才的错误。我恍然大悟，因为当这个界面load的时候，就执行了ChannelOpen语句，打开了摄像枪对应的信道，就像一扇门不能在打开的时候打开一样，信道也不能在已经打开的情况下再打开了，因此就会报错了。报错之后当然就截取不到图片了。
我心里很高兴，果然不虚此行，到用户那里去，看看他们在做什么，是我喜欢的方式。就像我在毕业论文中写的，经常看到两个程序员对着代码猜需求（我也曾经有这个“爱好”），两位停一停，去问一下用户或业务人员或领域专家到底是怎么回事不好吗？这样才是最有效果的。
我反对Ambler以前提出的“象牙塔架构师”的说法，或许现在投身敏捷阵营的他也不同意这个观点了吧，架构师一定要亲临现场，才会知道到底发生了什么。去年在做这个系统时，我和lulu就为一个业务逻辑对着代码看了一晚上没睡，结果第二天我跑到地磅员那里一问，就马上知道答案了。软件开发完全就是设计，写代码也是在设计，或者说代码也是一种设计视图，那么设计师们就应该亲自看到代码，并且亲自到第一线去，这样才能真正的做到敏捷——而敏捷，则是被我看来最实事求是的做法，而且其效果也是非常让我满意的。