豆豆成长的真快，最近新学会了很多东西。

首先是走路。豆豆严格的讲还不会走路，他踉踉跄跄的走几步还行，站着没人扶就会摔倒。豆豆站在床的另一边，我在这边叫他，他再也不会爬过来了，而是直接就走过来。有一次，大鸟阿姨来看豆豆，她不知道豆豆不会走，直接就把豆豆放在了地上。豆豆居然毫无惧色，自己就走到前面沙发那里去了，倒是把我吓了一跳。很多小孩站不稳的时候，是不敢走的；豆豆可不管，抬腿就走，摔跟头也不怕。这样的小宝尤其容易受伤，我特别担心他这一点。

豆豆说话也比较自如了，尤其是袜袜，爸爸，妈妈这三个词。豆豆最先熟练掌握的词居然是袜袜，每次脱下他的袜子，他都会说一句“袜袜”。他现在还会用“袜袜”指代身上所有的衣服，有时候想出去玩了，他就会说“袜袜”，表示要求穿衣服，然后好出去。爸爸、妈妈是豆豆最近才搞清楚的，他一度把我和老婆都叫做爸爸。

豆豆说话比我晚，据豆豆的爷爷奶奶回忆，我在14个月的时候已经掌握很多单字了。有一次爸妈带我外出去玩，拿了两个梨。一坐到车上，我就对他们说：“梨”，于是爸妈给了我一个梨。我呼噜呼噜啃了几口就把它给扔了，然后又一伸手说：“拿”。于是爸妈又给了我一个梨，我知道这是最后一个，啃到只剩一个小核了也不肯扔。爸妈最后劝我说，扔了吧，咱们一会再买。我一听，就把梨核给扔了。等过了一会，路过一个水果摊，我马上就对爸妈说：“买”。

豆豆虽然只能说几个词，但很多话他都听得懂了。比如我每次一说带他去玩点什么，他马上就会兴奋的扑过来；给他吃完饭，如果他没吃饱，奶奶说去洗碗，他就会大叫表示不满，如果说再去盛一点饭来，他就会欣然同意。我有一次抱着豆豆散步，豆豆妈在一旁，我就对豆豆说，咱们去踢妈妈几脚好不好？豆豆一听，立刻兴奋的咯咯大笑，然后就跃跃欲试的去踢妈妈。

豆豆还在妈妈肚子里的时候，我就每天给他听音乐，也不知道对于培养乐感有没有帮助。最近发现豆豆喜欢旋律简单、节奏欢快的音乐。每次一听到这样的音乐就情不自禁地手舞足蹈。豆豆最爱的歌曲是甩葱歌。

最近豆豆的第二批牙开始冒尖了。豆豆9个月大的时候长全了8颗门牙，之后沉寂了好一段时间，直到这个春节，他其它的大牙开始破土而出了。长大牙明显比门牙还要疼一些，这两天豆豆已经连续因为牙疼哭了两次了。为了帮助豆豆缓解疼痛，爷爷特地准备了冰镇大萝卜给他啃。

我们的长假也给豆豆带来了惊喜，因为他可以出远门了，这个野孩子就喜欢往外跑。豆豆先去了无锡爷爷奶奶家，又去了济南姥爷姥姥家。无锡距离近，来回都方便；济南就相对远了些，要不是去年开通了京沪高铁，我还真不知道如何带豆豆去呢。我特别讨厌飞机，如果没有高铁，济南到上海的路程最快也要8个小时，豆豆坐这么久的车肯定会闹的。高铁把行程缩短到了三个半小时，这样的间隔，豆豆还是可以忍受的。

动身去济南那天是正月初二，火车上根本没有几个乘客。我们所在的车厢就只有两家人，我们和一对台湾夫妻。台湾阿姨一下子就被豆豆吸引住了，豆豆也会讨人喜欢，乖乖得让阿姨抱着玩了一会。豆豆开心，爸爸妈妈就有心情给他拍照了：

除夕那天是在无锡过得，豆豆可不管什么春节，只是夜晚不时升起的烟火吸引了他。豆豆一点都不害怕爆竹声，每次听到了还会兴奋的跟着喊一声“嘣……”。晚上才9点多，豆豆就困了，而我也早就对春晚失去了兴趣，于是把豆豆洗洗干净就陪他一起睡了。快到0点的时候，鞭炮声四起，把我们一家都吵醒了。豆豆倒是也不闹，闭着眼睛“嘣”“嘣”嘟囔了两声便倒头再睡。

这是除夕的晚上，豆豆在和妈妈疯呢：

这次带豆豆出来最大的担心就是怕他到了新地方会不适应，尤其是去济南，离开了每天照顾他的爷爷奶奶，不知道他会不会难过呢？结果我们惊喜的发现，豆豆是个“没心没肺”的家伙，只要有饭吃，有玩具玩，在哪都一样。

豆豆对大车情有独钟，初一带他去散步，看到一辆平板大货车，拗不过他，我只好抱他上去转了几圈：

姥爷家里有一只玩具大老虎，豆豆可以喜欢了，常常扑上去搂住它的脖子又亲又啃：

提起玩，总离不开玩具。豆豆刚出生那会的玩具数量很少，主要都是别人送的。他那会其实不怎么会玩，不管是什么东西，抓到就往嘴里塞。直到他大约10月大的时候，才不那么爱咬东西了。拿到一个新鲜玩意，他会首先拿在手里翻来覆去看，然后甩来甩去或是梆梆敲上一阵子，最后才放嘴里尝尝。

发现豆豆比较会玩了，我最近两个月开始大量采购玩具给他。淘宝是我的主要购买场所，我通常按照玩具的销量排序，一个一个往下看，如果遇到豆豆可能会喜欢的款式，就买来一个玩玩。在所有的玩具中，豆豆对小汽车情有独钟。他最大的享受，就是跟我一起玩小车。豆豆自己也会开小车呢：如果是惯性车，豆豆就自己推着他们在地上爬；如果是发条车，我就把发条上满，让豆豆抓在手里，然后他把小车放在地上，一松手，小车就开出去了。有时候我刚把上好弦的车递给他，他就会开心的“哈”一声；如果是遥控车，豆豆就坐在我怀里看我开。我试图教会豆豆使用遥控器，不过他显然还无法把遥控器和小车的运动联系起来。

我买的玩具里也有豆豆不喜欢的，比如前两天买的一款大鳄鱼。大鳄鱼可以“咬”人的，我琢磨着豆豆也许会喜欢，就买了一个，哪知道豆豆看了鳄鱼并不很感兴趣：递给他，他就往外推。也许鳄鱼长得不好看，又没有轮子吧。我于是想演示一下大鳄鱼的玩法，吸引一下豆豆：我抱着豆豆，把鳄鱼嘴巴掰开放在床上，然后一颗一颗的按下鳄鱼牙齿。突然，鳄鱼咔嚓一声合上了嘴巴，咬住了我的手指。我“哎呦”一声缩回手，一个劲吹气表现出很疼的样子。结果豆豆“哇”一声就大哭起来，我赶紧扔了鳄鱼，哄了他半天他才不害怕了。

豆豆另一项非常喜爱的游戏是捉迷藏。小婴儿时候的豆豆以为他看不见我，我就看不见他。所以他的藏猫猫方法就是把头藏到手绢后面或是埋在我怀里。现在他大了，已经可以理解在什么情况下我才看不见他了：只有把全身都挡住，或者我面向别的方向，才是看不见他的。不过呢，他现在的幼稚想法是：只要我看不见他，我就不知道他在哪了。昨晚，我把豆豆放在他自己的小床里，他就扶着栏杆站起来，然后扯过床边的窗帘，把自己整个罩在窗帘后面。我知道他跟我藏猫猫呢，于是就自言自语：“豆豆哪去了？”他确信我不在看他的时候，就放开窗帘来查看我的状况，而我这时通常在背对着他，一边翻箱倒柜，一边说：“豆豆上哪了？怎么找不着了？”然后慢慢回过头，一把抓住他说：“原来你藏到这儿啦！”豆豆于是得意的哈哈大笑。笑够了再扯过窗帘重来。

我偷偷观察了一下躲在窗帘后面的豆豆：他缩着个身子，尽量隐蔽好；低着头，眼睛盯着小脚丫，生怕一抬起来就会被我发现；抿笼嘴，使劲憋着笑，但有时还是憋不住，会发出噗哧噗哧的声音。我真没想到一个还不会说话和走路的小宝，可以玩藏猫猫玩得这么专业。

这是豆豆在新京杭大运河边看货船：

站在河边的小树林里：

第二天领豆豆去寻访爷爷家老屋“遗址”，顺便游览了无锡古运河。远处那座拱桥是无锡古运河的标志性建筑：清明桥

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 58,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 21 sold-out performances for that many people to see it.

Click here to see the complete report.

平时，爷爷奶奶在上海照顾豆豆，无锡的房子很久没人住了，里面落满了灰。为了迎接豆豆，奶奶特地提前一天找来钟点工打扫了房间。三个钟点工花了4个小时才把房间打扫干净。等我们到达无锡的时候，发现他们干的还挺认真的。地面上几乎没什么灰尘，于是直接让豆豆下地去爬了。

奶奶家的房子比我们现在租住的地方可大多了，豆豆可以尽情玩耍。豆豆首先参观了每一间屋子，然后选定了客厅这块空间最大的地方，开始追他的小水泥车：我把他的小车一推，跑出去几米远，豆豆就蹭蹭蹭爬过去，举起小车给我；我再朝另一个方向一推，豆豆又追过去。豆豆也会自己推着小车爬，把奶奶的地板划的一道一道的。豆豆玩腻了小车，会自己去探索周围的环境。看见有抽屉，就去拉一拉；看见有插座，就去捅一捅。紧张得我赶忙找来封箱带，把所有豆豆够得到的插座全部封起来。

豆豆会自己藏猫猫了。我陪他在客厅里玩的时候，他会突然爬到走廊里我看不到的地方去。我等他不见了，就在客厅里喊：“豆豆哪去了，豆豆怎么找不着了？”他听到我找他就飞快的从走廊出来爬向我。我就故意很惊讶的看着他说：“哎呀，原来豆豆在这儿呢！” 豆豆于是笑得非常得意。

有时候豆豆在前面爬的时候，我故意在后面张牙舞爪的吼：“我来抓豆豆啦，就要抓到了！” 豆豆就会加快速度拼命爬，我如果一把抓起他，他还会兴奋的尖叫，嗷一嗓子把在厨房里的爷爷奶奶都吓一大跳。豆豆逃跑过程中还不时停下来，回头看看我是不是已经很近了。一次，他一回身发现我就在屁股后面，吓得赶忙调头。不料用力过猛，小胳膊没有撑住大脑壳，一嘴巴啃在了地板上，气得他哇哇大哭了好一通。

豆豆食欲旺盛，看见吃的就像从没吃饱过一样。到无锡的第二天，奶奶抱着他去隔壁串门，临走时看见人家在煮红枣。大枣是豆豆最喜爱的食物之一，他看见大枣也顾不得丢人了，叽歪个脸啊啊直叫。到底混了两个枣子吃，才心满意足的回家来。我抱他去逛超市的时候，看到有卖麻辣锅巴的，我很久没吃这东西了，于是装了一小 包，并且掏出一个来尝了尝。本来超市里的物品玲琅满目，豆豆也不知道什么能吃，他也并不特别想要什么。但是看见我吃了锅巴，他的馋虫也被勾起来了，指着锅 巴“嗯嗯”两声，我居然没领会他的意思，把锅巴口袋递给了服务员去称重。豆豆一看好吃的没了，立刻不干了，冲着服务员“啊啊”大喊两声，吓得服务员赶紧把称好的锅巴递给他。无奈豆豆还不能吃这么不健康的东西，我只好又拿了个蛋糕来糊弄他，才算过了这一关。

豆豆每天上下午都要各出去放风一次。在上海的时候，每天去上医，他早就玩腻了，无锡可是个新鲜地方。爷爷家的小区比邻新京杭大运河，下了楼走两步就来到河边。豆豆一看见往来的货船就傻了眼，直勾勾看了半个小时才缓过神。沿河绿化带修得非常漂亮，有浓密的树林，有平缓的草地，有木质的小路。整个绿化带就只有我们一家人，尽管是寒冬时节，走在林间小路上仍然温馨而惬意。

走着走着，我发现路边长着一丛蒲公英，心想豆豆肯定喜欢这东西。我于是摘了一支举到豆豆眼前，豆豆还在好奇的端详着这一簇白毛的时候，我用力一吹，顿时一朵绒球化为漫天飞絮。豆豆一愣，然后立刻开怀大笑。接着就指着地上其它的蒲公英说：“嗯嗯嗯”。于是我又给豆豆采了一大把花束，直吹到我面红耳赤了方才作罢。

平时都要上班，我很少有这样的整段时间陪豆豆玩。豆豆似乎也发觉了这是个难得的机会，整个假期都缠着我不放，出去散步也必须我抱，换个人都不行。豆豆有22斤重了，真沉啊。那天逛完超市，回来的路上我看他困了，就对他说：“趴到爸爸肩膀上”。他往我身上一趴立刻就睡着了。我怕弄醒他，不敢换姿势，就这样抱着他回到家。到家时，两只手臂酸疼酸疼，就快失去知觉了。

趁着回无锡，还带豆豆回老房子的“遗址”参观了一下。无锡的老房子修建于一百年前，坐落于古京杭大运河河畔，现在的南长街附近。我一直觉得周庄、乌镇之类的景点了然无趣，主要就是因为我小时候也曾生活在这种环境中，毫无新鲜感。

为了兴修步行街，老房子几年前就被拆除了。抱着豆豆走在步行街上，我仔细端详了一下两旁的建筑。这些建筑都是仿古风格的，很多建筑并非全新，而是利用了原有房屋修葺而成。请转绿瓦依旧，远处高耸的拱桥也还在，但装着咖啡厅、西餐馆的房屋无论如何都散发不出江南古镇的韵味。记得我小时候，初冬的早上，弄堂里总是烟雾缭绕，徐徐送来无锡小笼特有的甜腻香味。这种感觉也许永远只能是记忆了：眼前煤炉不见了，早点铺子消失了，甚至连弄堂都拆迁了。

步行街眨眼就走到了尽头，这在我儿时的记忆里可是一段相当远的路程呢。那时候吃过晚饭，我率领着弟弟妹妹们出来消化食，最远也只探索至此，就不敢再走，转头回家了。现在看来，那段路程是如此的短暂。

上星期给豆豆买了一套玩具，包括一组7辆工程车。豆豆最喜欢其中的水泥搅拌车，每次一拿到它都会开心的笑起来。豆豆喜欢它的原因大概是因为它的搅拌桶可以旋转吧。

豆豆最初是看我和豆豆妈在地上来回开这辆小车，然就就跃跃欲试的要自己去开。去外面草坪上玩的时候，豆豆就会用手抓着他的小车，撑在地上，推着往前爬，嘴里还要发出呜呜呜的声音。可惜家里的环境不太适合他爬在地上，于是我想出了一个办法：我弯着腰，双手托起他，让他身体与地面水平，一伸手又正好可以碰到地面，于是他就可以拿着他的小车放在地上，然后我往前走，小车就开起来了。豆豆别提多喜欢这个新玩法了，玩起来就不停。不过我可吃不消，几分钟下来腰就酸了。

昨天，豆豆在床上玩他的小车时，又想起了这个玩法。他爬到床边，伸手就要把小车在地上去开。奶奶一不留神，没有看住他，结果他咕咚一声从床上掉了下去。我听到哭声赶忙从里屋出来，发现可怜的豆豆头上被撞了一个大包。幸运的是，经过我的一番检查，发现豆豆没有受伤。也不知道是不是有第六感，我昨天上午陪豆豆玩的时候，就突然非常担心他会从床上掉下来。还一个劲追问我妈，我小时候有没有掉下床过，有没有摔伤。结果下午豆豆就出事故了。

豆豆原本惊魂未定，一看到我又兴奋了。扑到我怀里，然后指着地上的小车还要跟我玩。豆豆妈严厉指责了我：发明的玩法又累人，又危险。所以我再也不敢这么玩了。我现在改进了玩法：抱着豆豆，让他把小车搥在墙上开，虽然娱乐性差了点，但安全很多，我们也轻松不少。

豆豆的小车除了用来开之外，还用来摔和敲，所以寿命都不长。每辆小车的寿命都不超过五天。前两天，他把水泥车的搅拌桶给摔掉了，非常伤心，然后就把断开的桶和车体摊在我面前，用恳求的眼神望着我。看来我无论如何都要修好他最心爱的小车了。我找来一根圆珠笔芯替代原有断裂的滚筒轴承，重新把滚筒装了回去。豆豆看见滚筒又可以转了，高兴的直蹦。

昨天水泥车的轮子掉了一个，这个好办：拔下来一个其它小车的轮子就好了。今早他更是把小车控制轮子转动的机械设备给摔掉了，车轮不能转了。我只好把水泥车和两一辆他不太喜欢的小车的整个底盘都对调了。

豆豆现在认得很多电器了。我问他：空调在哪呢？他就指给我空调；问他：电视在哪呢？他就指给我电视；问他一个他没见过的东西，比如：洗衣机在哪呢？他就会琢磨一会，然后指给我一个发音最接近的东西比如电视机。

傍晚，我拿了个桔子给他。他拿在手里翻来覆去看了一会，然后递给我说：“嗯嗯嗯”，让我给他扒开。我于是扒开皮，他一把抢过里面的瓤，然后掰了一瓣，又递给我说：“嗯嗯嗯”，继续让我扒皮。我于是又扒掉桔子瓣上的革质表皮，豆豆啊呜一口吃掉了里面的肉。

这里用一个例子来说明一下。

假设我们要编写这样一个程序，它的界面有一个仪表盘外加两个控制按钮：

当Play按钮按下时，让仪表盘指针旋转。当Stop按下时程序退出。我们假设维持表盘转动是一个持续的任务，并且它不能够阻塞程序的其它任务，比如对Stop按钮的响应。这样我就需要安排一个独立的线程来做维持表盘转动这一任务。

我为这个任务创建了一个VI，这个VI有两个输入参数，分别是表盘和Stop按钮的引用。

维持表盘转动的VI的程序代码如下：

它每隔10毫秒挪动一下表盘指针的位置，没两秒钟让表盘转一周。10秒后程序停止：

维持表盘转动的VI同时检测主程序中Stop按钮是否被按下，如果按下就立刻停止运行。

在LabVIEW2011之前，实现主程序功能的唯一方法是使用VI的“运行”方法，把“维持表盘转动VI”动态调用运行起来。主程序程序框图如下：

在这段代码最不尽人意的地方在于，运行子VI之前先要传递参数。这里只能通过VI的“设置控件值”方法为子VI传递参数。这种方法不但编写复杂，安全性也低。首先，它是通过控件名来找到需要传递参数的控件的，LabVIEW无法在编译时检查参数名字是否正确，子VI中的控件若是改了名字，程序编译时不会有问题，但运行时就会出错；其次，它无法检查需要传递的参数的数据类型，传递一个错误类型的数据进去，LabVIEW也不会在编译时出错。

使用“异步调用”函数，这段程序可以被大大改善：

需要注意的是，在使用“异步调用”函数前，打开VI引用的时候，一定要传递一个值为0×80的“选项”给“打开VI引用”函数。“异步调用”函数的使用方法与“通过引用调用”十分类似，这里就不赘述了。它们的去要区别在于“通过引用调用”是同步的，程序会停在这个函数上直到被它调用的子VI运行结束；而“异步调用”函数是异步的，程序在这里把子VI启动起来后，并不等待，会继续运行后续程序。

昨天睡觉前跟老婆讨论春节回家的事，我提起说现在火车票可以网上订购了，结构就梦到了坐火车。今天早上6点多钟的时候，我一直迷迷糊糊的，并没有睡死。后来爸爸在门口喊我起床，哪知道他一喊我，我立刻就睡熟了，还做了个清晰的梦。

梦中我和几个同事坐火车旅行，我们在网上订购了卧铺票。火车启动后，我们躺在各自的铺位上聊天。火车停靠第一站的时候，我听到路过的乘务员聊天说现在火车厕所改进了，停车时候也可以用。我立刻蹦下来，去上厕所。

进了厕所，我发现这是一大间屋子，类似剧场车站等公共场所的厕所，有两长排的池子。我于是就很开心：以前火车上的厕所就只有一个坑位，现在变得这么气派了！

哪知乐极生悲，从厕所出来回到铺位发现自己铺位上躺着一个陌生人，旁边几个铺位的同事也不见了，都是陌生人，难道我走错车厢了？我于是走到车厢头，掏出车票来比对。我这时候才发现网上打印出来的订购凭据只有一个交易号码，没有写具体的铺位。我好不容易根据这个交易号码查询出了我订购的铺位，没有弄错。再回到位置上，我和同事的铺位还是都被别人占着。

好不容易从距离较远的隔间里找到了另外两个同事，我想他们询问情况。他们说：铁道部的网上订购系统出了问题，我们买的铺位在销售网点又被卖出去一遍。乘务员不认可网上订票，在刚才火车到站的时候把其他几个同事都撵下去了。

我气急败坏的去找乘务员理论，他根本就不理我。于是我掏出手机来威胁说我要投诉，等拨号码的时候我才意识到不知道投诉电话是什么。火车又快到站了，我想先别忙着投诉了，还是趁着火车没开太远，先回家吧，于是收拾行李准备下车。

然后我就醒了。

这段程序的功能是，当鼠标点击在波形图控件的某一条曲线上时，把这条曲线变粗显示。程序框图如下：

这个程序开始先造了两条随机数据的曲线。当用户在波形图上点击时，就调用“Get Plot At Position”方法查看是否有点击在了某条曲线上。如果是，则使用“Plot.LineWidth”这一曲线的属性把曲线宽度设置为2，其他曲线宽度都只有1。

程序运行效果如下：（蓝色曲线被加粗）

比如这个问题“打印出所有的整数”就是一个不可解问题，因为整数是无限的，无论哪种算法都无法将其全部列出。图灵提出的The Halting Problem也是这样一种情况，由于它是一段可能被无限次递归调用的代码，因此无法判断其运行结果。

有一类问题是暂时不可解的，不可解是因为它没有被现有公理所覆盖到。这类问题一旦被发现，人们就会补全公理体系，问题就解决了。比如说哥德巴赫猜想就有可能是这样一个问题。哥德巴赫猜想还没有被证明，所以现在不能确定它是否可解，不过也许有一天人们会发现从现有所有的数学公理都无法证明这个题目，它本身可能就会变成一条公理，被加入到数学体系里去了。

我们给豆豆买了一个生日蛋糕，蛋糕店不肯写字，豆豆妈自己动手写上了豆豆两个字。

我们还特地教豆豆比划出1这个数字。蛋糕店送了个好玩的帽子，不过豆豆不是很喜欢。

中午吃完蛋糕，就带豆豆去外面草坪玩。

豆豆爬得可开心呢。

豆豆是大力士，已经可以把他的大汽车搬起来了。

豆豆看见一个美女，赶紧凑过去亲密一下。

回家前，又跟爸爸疯了一阵。

虽然豆豆只能说一些简单的单词，比如爸爸、妈妈、袜袜等，但是大多数日常用语他都可以理解的。比如问他奶奶在哪呢，他就会去吧奶奶找出来。豆豆其实很爱说话的，只不过他说的话俺们都听不懂。

上午我和豆豆妈领着豆豆去取他的大蛋糕。本来是推着小车出去的，可是豆豆不喜欢坐车，非要让我抱不可，我只好抱着他。一路上，他就指着每一家路过的小店，跟我呜呜哇哇的说话。豆豆可真沉啊，出去取蛋糕，我来回抱了他差不多40分钟的时间，等回到家里胳膊就酸的抬不起来了。

豆豆现在跟爸爸可好了。我每天回家，一进门看见豆豆，他总要先大叫一声，然后就过来让我抱。然后就赖在我身上让我陪他玩。有时候我上个厕所他也要跟进来看看。

关于豆豆的内容，经理倒是提醒了我一个问题，就是豆豆的隐私。也许豆豆将来会很讨厌别人从我博客里看到有关他的内容呢。所以我打算等豆豆上学以后，就把他的内容都隐藏起来了。

豆豆生病这几天，我们怕他的温度太高，每次一旦他的温度达到39C就开始给他吃退烧药。泰诺林和美林两种药轮流吃。发烧比较厉害的时候，吃一次药，药效只能坚持四个多小时。药效一过，豆豆的手脚就开始发凉，然后体温迅速升高。好在豆豆这几天除了发烧没有任何其它症状，还让我们安心一些。

中午量过体温就给豆豆吃了退烧药，泰诺林，对豆豆还是挺灵验的。豆豆深得我的遗传：体温一降到39度之下就立刻恢复淘气本性。他不喜欢奶瓶，为了给他喝水，我们只好把水放在一个大碗里吸引他喝。他喝了没几口就开始玩起来了，用手拼命拍水。看见水溅了我一身，他高兴的咯咯直笑。

由于不晓得豆豆发烧的原因，下午，我还是带豆豆去了医院。医院里的孩子们一个个都蔫了吧唧的，只有豆豆活力不减，在我怀里跟我嬉闹，一会拍拍我的脸，一会又抢我的眼镜。轮到豆豆看病时，他又一把抢过医生的听诊器不肯撒手，搞得医生哭笑不得。

验血的结果和上次发烧时一样，是病毒感染。等我们从医院回来，豆豆又饿又困，豆豆妈喂了他一会，他就睡着了。我一直坐在床头看护着豆豆，看见这张甜美的小脸，心里就会洋溢起幸福。

最近秋高气爽，每个周末都抱着豆豆去绿地上玩。

做个可翻墙的浏览器，在技术上应当不难。我的想法是利用p2p技术。当在国内的A电脑上，用浏览器访问wordpress，发现连不同，浏览器就查找自己保留的其它浏览器的ip地址，然后询问其它浏览器是否可以访问wordpress。假如恰好查询到位处美国的B电脑可以访问这一网址，那么A就把自己的请求加密，发给B，B解密后把请求发给wordpress，B读取了wordpress的网页后，再加密传回给A。

这个方案的缺点是A的私密信息可能会被B截获，为了保证安全，可以做的复杂点，就是在美国设置一个服务器，只有这个服务器可以进行加解密。也就是A的信息传给B，B没有密钥，直接把密文传给服务器，服务器解密后再发给要访问的网站。信息安全取决于提供服务器的组织的信誉。

本人没有制作这个浏览器的能力，希望那些专门开发翻墙软件的公司可以看到这条意见。

我还是挺喜欢使用递归的，因为写起来简单。今天真正调试了别人的程序才发现它缺点也不少，主要是不容易调试，递归层次较深的时候，很难找出错误出现的那一层。相对来说，循环中找出错误出现在哪一次迭代还是比较容易的。

至于递归深度的限制还是个小问题，如果程序正确，很少有递归需要达到那么深的层次。

我仔细阅读了一遍我调试的那段程序，果然发现它有一个逻辑错误，导致了在特定情况下递归永远达不到截止条件，以至于系统出现栈溢出错误。

在大量的已有程序中找出这种搭配关系是一个关联规则挖掘的过程。

LabVIEW程序中每两个节点都有可能搭配在一起，当然只有达到一定支持度和置信度的搭配对于我来说才是有意义的。
支持度是指一种搭配的数量占所有各种搭配数量的比例。比如我收集了LabVIEW程序中，所有搭配数量是10,000个，“Open Config Data.vi”和“Read Key.vi”搭配在一起出现了10次，这种搭配的支持度就是0.001。
“Open Config Data.vi”和“Read Key.vi”搭配除以所有包含“Open Config Data.vi”的搭配就是它的置信度。比如“Open Config Data.vi”除了和“Read Key.vi”搭配还可以和“Write Key.vi”搭配。若“Open Config Data.vi”和“Write Key.vi”搭配的数量也是10，那么“Open Config Data.vi”和“Read Key.vi”搭配的置信度就是0.5。

想调查这件事纯粹是个人好奇，打算看看大家写的程序有无规律可循。我觉得一个好的编程语言是不应当有这种规律的。因为，假如某种搭配的支持度非常高，就应当把这种搭配做成一个子VI，更方便程序员编程。

豆豆早就对徐家汇租的小房子厌烦了，来到无锡别提多开心了。无锡家里大多了，地板上可以随便爬。

豆豆特别喜欢开关和插座，每次爬到那里必然要抓起来玩弄一下。

奶奶的大衣柜也是好地方，豆豆坐进去就不要出来了。

和大衣柜一比，豆豆像个小不点。

豆豆还给爷爷奶奶的房间搞了装修。先是在墙上抹了两个黑手印。然后干脆用手指甲抠了一个小洞。最后用玩具在桌子上砸了一排小坑。

小区的环境也很不错，有很多花花草草。豆豆眼睛都不够使了。在上海的时候，想哄他睡觉，就抱他出去转一圈。在无锡可不行了，外面这么新鲜，豆豆挺着个脑袋就是不肯睡。这个国庆，豆豆都极力抗拒睡觉，不过一旦睡着了，就睡的特别香。

我们领着豆豆去无锡城里逛了一圈，豆豆对所有商品的喜爱程度都差不多，只要是新鲜的，以前没玩过的，他就会上去又摸又抱。

豆豆到无锡走一趟，收获了不少玩具，包括爸爸DIY的“美女猪”

还有姑姑送的积木

豆豆会用声音表达意思了。以前他想要什么东西的时候会身子靠过去，或者抓我的手伸过去。现在方便了，盯着那样东西，“嗯，嗯，嗯……”叫几声就行了。

豆豆似乎有点懂“爸爸”这个词的含义了。有几次他吃奶的时候，他不想吃了，回头一看，我在旁边，于是就叫两声“爸爸”，然后朝我爬过来。

豆豆也终于开始学叫妈妈了：一次他饿的非常难过，哼哼唧唧的叫了一声“姆啊”的音。

豆豆最可爱的是学会了“啊啼”。豆豆在家有个专用的洗澡盆，没有带回无锡来，于是我们俩光溜溜的，我抱着他冲淋浴。豆豆突然打了两个喷嚏，他大概觉得打喷嚏很好玩，打完了还朝我笑笑。我于是很夸张的装作打了喷嚏，朝他“阿嚏”一声。豆豆开心的咯咯直笑，看他这么高兴，我又“阿嚏”了几声。等豆豆妈开门来接他的时候，豆豆朝妈妈“啊啼”了一声，然后就哈哈笑起来。

豆豆的模仿能力还不仅表现在说话上。有一天，我把去把车从停车场开到家门口。很短一段路，于是奶奶就抱着豆豆坐在副驾驶位置上。豆豆一动不动看着我开车。等我我一下车，他就“嗯，嗯，嗯……”表示要做到驾驶位置上去。一坐到驾驶位置上，他就马上学我的样，扳几下排挡再扭一扭方向盘。

关于家谱的一些考证：

我所在的这一支阮姓支系被称为江苏溧阳阮氏，1700年来一直生活在江苏常州，几乎没动过地方。所以家谱里记载的人物关系应当还是比较准确的。家谱中最早的老祖宗是阮裕，再上就没有记载了。辈份中负数的那些是我从其他资料中查到补上的，可信度较低。

阮裕在《晋书》中有记载。据《晋书》列传第十九记载，阮裕年六十二卒，并且他最晚的记录发生在晉穆帝（344~361）晚期，所以我估计他生活的年代大约在290～350前后。《晋书》也提到了阮裕的父亲和爷爷：祖略，齐郡太守。父顗，淮南内史。

《晋书》认为阮裕是阮籍（210～263）的堂弟，我觉得可能不准，因为两个人出生时间差了将近100年了，同辈的可能性比较低。我在网上找到一些其它阮姓分支的族谱，有阮裕之上的记载。我选取了一个至少年代上还靠谱的版本（http://bbs.ruanchina.com/thread-470-1-4.html），按照它的记载向上续上了辈份负号的先人们。

Wait 函数比较好理解：给它个输入参数n，每次程序执行到它的时候，它就停下来，等待n毫秒，再继续运行后续程序。

Wait Until Next 函数稍微复杂一点：给它个输入参数n，每次程序执行到它的时候，会暂停在这里，Wait Until Next 函数每隔n毫秒醒来一次，醒来后再继续运行后续程序。

单纯解释概念比较抽象，还是用程序来演示一下。下图左右两个程序的功能相同吗？

一般情况下，程序并不要求非常精确的计时，这时 Wait 与 Wait Until Next 区别不大，程序员选用哪个函数都可以。

只有在要求很高的时候，才需要考虑他们之间的细微差别。

我们假设上图程序中 Read Data 和 Write Data 函数的运行时间都是n毫秒。若 n<50，在默认情况下，上图的两个程序，循环每迭代一次，所需时间都大约为100毫秒。

精度

但是，两个程序的计时精度是不同的。使用Wait Until Next 函数的程序的精度远高于使用Wait的程序。

在Windows这样的非实时操作系统中，定时函数是非常不精确的，每次执行，误差几毫秒是也是正常的现象。

Wait 函数，每次运行到它才开始计时，因此单次的误差会被累积。假如每次误差四五毫秒，迭代五次误差可能就达到十几毫秒了。

Wait Until Next 并不需要在每次调用的时候计算延时。假设Wait Until Next 函数从0时间开始计时，那么程序一开始运行，它就可以知道自己每一次醒来的时间分别应当是：100ms, 200ms, 300ms……。假如误差是±4毫秒，那么它实际每次醒来的时间就是100±4ms, 200±4ms, 300±4ms……，这个误差不会被累积。

第一次迭代的时间

运行下面两段程序，x-y分别是多少呢？

使用Wait函数那个程序，x-y等于500（忽略误差）：延时了五次，每次100毫秒，那么总和就是500毫秒。

而使用Wait Until Next 函数那个程序，x-y的值则每次都不确定，但是值的变化范围是确定的，在 400+2n 与 500 之间。这是因为Wait Until Next 开始计时的时间并不是根据程序何时运行来确定的，对于程序来说，这个时间是不确定的。虽然 Wait Until Next 函数保证每次醒来的间隔是100ms，但它却不能确定第一次醒来的时间。第一次醒来可能是0~100ms之间任何一个时间。

如果循环第一次迭代就必须是精确的100毫秒，那么该怎么办呢？办法很简单，让Wait Until Next 第一次睡眠时不做任何事情，从第二次才开始使用它就行了。如下图的程序，每次运行，x-y的结果就会是确定的500

并行与串行

在前面看到的程序里，延时函数与循环中其它的代码是并行的，这样，只要其它代码耗时不长，循环每次迭代的时间就是有延时函数的输入参数来决定的。但有时候，延时函数需要与其它代码串行，比如必须在某两个节点之间延时。

当串行的时候，再使用Wait函数计时就不那么准确了。比如上图左面那个程序，它的循环没迭代一次的时间变成了2n+100。n这个时间是不确定的，它会受到电脑的配置，CPU负荷等的影响。因此用这种方式计时非常不准确。

而Wait Until Next 只考虑每次醒来的间隔，至于什么时候进入休眠的，并不影响醒来的时间。因此，对于它来说，并行与串行的效果是完全相同的（2n<100时）。

我最初还真没想到一本LabVIEW书会有这么多读者。开始写这本书的时候，我以为中国LabVIEW用户数量不多，这本书能卖出去三四千本我就满足了。现在看来，中国LabVIEW用户还真不少，LabVIEW影响力蛮大呢。

豆豆是老太太杀手。豆豆出去晒太阳的时候常常会引来老头老太逗他玩，尤其是那些还没孙子的老人们。豆豆比较穿得比较有特点，一般只穿一个小背心，是小宝里穿得最少的。尤其是他不穿袜子，似乎上海人认定小宝是必须穿袜子的，所以他光着脚丫特别显眼。现在，小区周围几个街区的老太太没有不认识豆豆的。

周末我抱着豆豆去菜场，后面一位大婶凑过来逗他玩，然后说小家伙看起来坏坏的。豆豆的坏小子本性早就暴露无疑了。他大约一两个月前学会了借助大人的手去够东西，比如说他想要桌子上的玩具，但够不到，就会抓起我的手，往玩具那里伸。再后来他就学会有别人的手来鉴别危险啦。比如去超市，他看见货架上的商品，他想去抓，又不确定那些东西是否会伤害到他。这时候他就会抓起我的手去碰那些商品，如果我碰一下就缩回来，那他也不会去碰。否则，看我可以安全的触摸某样东西，他就放心了，上去一把就把东西抓过来。

昨晚，我抱着他在屋里溜达，走到电风扇前面。他已经知道电风扇是很危险，不能碰的。但是他盯着电风扇看了一会突然就嘿嘿嘿坏笑起来了，然后就抓起我的手去够电风扇。我知道他在打什么鬼主意，于是轻轻碰了一下电风扇，然后假装被打到了，迅速缩回手，哎呦哎呦叫了几声。豆豆自以为得计，哈哈哈得笑的前仰后合。

豆豆已经学会真正的爬行了，现在在床上够东西再也不用匍匐前进了，而是直接就会用膝盖双手交错爬行前进了，行进效率提高了不少。

豆豆是个火气比较旺的小宝，最近居然有点大便干燥。前几天拉屎的时候大概很疼，还哇哇的哭了一通。这两天改善了豆豆的伙食，吃的全是火龙果，鸭梨这些去火通便的食物，他才终于恢复正常了:)

这个软件目前还是“预览版”，它的功能尚未完善，但基础功能已经有了，想见识一下网络版LabVIEW什么样的，现在就可以去玩一下了。这个软件的网页是：http://www.ni.com/uibuilder/。它的主页上有使用介绍以及一些示例程序的界面。

我们可以直接点击 Try It Now 按钮，启动 LabVIEW Web UI Builder。LabVIEW Web UI Builder是基于Silverlight编写的，如果网络速度较慢，第一次启动它可能需要等待一段时间。

软件起来以后，首先进入登陆界面。LabVIEW Web UI Builder必须登陆后才能使用，若没有账号，可以免费注册一个。

登陆后，就进入了程序的主界面了。大家看得出，这个软件的风格已经完全不像是之前的LabVIEW了，相比之下，他更接近Office的风格。

好在LabVIEW Web UI Builder非常简单，即便换了风格，也可以很快上手。先来点击“New VI”按钮创建一个新VI。

与桌面版LabVIEW不同，LabVIEW Web UI Builder不再采用窗口的方式，而是使用了单一一个集成开发环境，所有的VI都被放在了一个主环境内进行编辑。主窗口的中部是文档区，VI文件都在这里进行编辑；上方是Ribbon，常用的工具按钮；两侧以及下方摆放了其它一些编辑工具或者信息显示窗口。

尽管LabVIEW Web UI Builder的风格变了，但编程方法和原理并没有变化，它仍然还是LabVIEW。以编写一个简单加法运算的程序为例，先编写程序界面，从控件选板上脱下来三个数值型控件用于控制和显示数据：

现在VI的前后面板被和到同一个子窗口中去了，不像以前那样，分属两个窗口。点击VI编辑区，左上角纵向排列的两个按钮中下方那个，就切换到程序框图了。大家看到的程序框图上列出的三个接线端，就是刚才我们放置的三个控件的接线端。

由于程序原理与以前的LabVIEW完全相同，我就不赘述了。不过需要注意的是，LabVIEW Web UI Builder不支持鼠标右键菜单。以前在右键菜单中完成的工作，可以使用Adorner来完成。Adorner是指，当鼠标选中一个对象后，在对象周围浮现出来的一些操作选项。比如下图中，我周在为While循环的停止条件创建一个控件。

下图是编写好的程序：与以前的LabVIEW完全一致吧！

点击Run按钮可以让VI运行起来。

使用网页版LabVIEW的一个好处是，可以直接把编写好的程序存在NI的服务器上。保存时，程序会问你存放的Location的。

当然想把程序存到本地来也是可以的，点击Ribbon上的Export按钮，可以把程序导出到本地，存成后缀名为vix的文件。

如果大家打开这个vix文件看一下，就会发现，它是一个XML格式的文本文件。以后LabVIEW程序编写的时候可视化操作，保存的时候存成文本，图形化编程语言和文本语言的优势可以得兼，前景相当光明啊。

Packed Project Library 并不是手工创建的，他是通过一个项目的生成规范，从 Project Library 编译而来的。比如上图的项目，我创建了一个Packed Library类型的生成规范。我在这个生成规范中指定把“My Algorithm Library.lvlib”编译成Packed Project Library 。

编译的结果是在我指定的路径下生成了一个名为“My Algorithm Library.lvlibp”的文件。它的后缀名仅比Packed Library多了一个字母p。

双击这个文件，可以打开它，看到他里面包含的VI：

如果需要在其它项目中使用到这个Packed Project Library，我们可以直接把它加到另一个项目中去，下图是一个演示项目：

Packed Project Library 看上去和 Project Library 非常相似，用法也完全相同。

Packed Project Library 与 Project Library

• 都是将功能相关的一组VI封装起来的方法；
• 库中的VI可以具有层次机构；
• 库中的VI都带有名字空间，名字空间是带有后缀名的库名；
• 都可以方便的放在项目管理器里使用

尽管它们十分相似，Packed Project Library 与 Project Library 相比，还是有一些明显区别的：

• Packed Project Library 是通过编译生成的；
• Packed Project Library 中的VI是编译后产生的，它们不能被修改；
• Packed Project Library 包含有私有VI，但用户无法看到也不能使用它们；
• Packed Project Library 把VI，.lvlib以及其它用到的文件都打成一个压缩包，用户在磁盘上就只能看到一个.lvlibp文件，看不到VI文件；
• Packed Project Library 很适合作为最终产品发布给用户使用；
• 在项目中使用Packed Project Library 可以缩短编译时间，因为Packed Project Library 中的VI是已编译好的，不会再随项目编译一遍。(这一条先这样写上，但我还需要再深入研究一下)

和同龄小宝比起来，豆豆人高马大，力气也大，但还没有学会控制自己的蛮力。他抓人的时候会死死的抓，咬人的时候拼命咬，搞得家里人人带伤。豆豆爸的胳膊上有好几道伤口，以至于豆豆的暴行都已经传播到爸爸的公司里了。不过，受伤最重的还是爷爷，爷爷的后背都被豆豆给抓烂了。

为了防止他长大以后赖账，我们还特地把豆豆的罪行给拍下来了：

豆豆几个星期前又长了一颗牙，到现在还是总共5颗牙。豆豆总是有一颗牙领先于同伴先出来。

周末，又给豆豆剃了一个光头，然后领着他去逛商场。

豆豆是个“野孩子”，就喜欢往外跑。他现在可以听懂一些简单对话，看明白一些动作了。一旦发现有出去玩的迹象，就兴奋的小腿直蹬。最近天热，我在家喜欢光膀子，出门才穿衣服，这个习惯被豆豆发现了。平时早上都是爷爷抱豆豆出去散步，所以一大早豆豆就抱着爷爷不放。我叫他，他不理。于是我就拿来T恤当着他的面穿上，他立刻就对我改变了态度，伸出小手往我身上扑。等我一抱上他，他就死死抓住我的衣服，说什么都不肯松手了。

豆豆现在太沉了，抱他出远门可吃不消，于是我翻出了豆豆的座驾。这是豆豆的豪华敞篷跑车：

第一次坐上小车的豆豆既紧张又兴奋，在车里东张西望，看得可带劲了。但是到了没风景的地方，他还是不喜欢自己呆在车里的，一定要让人抱。

我们一家人推着豆豆来到了港汇广场，豆豆都看傻眼了。

到了吃饭时间，我们打算在港汇5楼找一家饭店吃一顿。没想到这里生意极好，除了两家店，其它饭馆都需要排队。这里最清闲的饭馆是肯德基，门可罗雀。我还从来没见过肯德基在用餐时间可以不排队的。看来这种快餐店就适合开在商场底楼，我估计人们选快餐店的一个重要原因是顺路，开在楼顶肯定影响客源。我们不想浪费时间，于是选了另一家不需排队的餐馆，一个叫什么蕉叶的东南亚风味餐馆。吃上之后，发现这里不用排队是有他的道理的，真难吃，我是再也不会来了。

豆豆的表现真乖，一家人吃饭的时候，他不哭也不闹，自己在那啃勺子玩。

吃完了饭，下楼来到儿童专区。这里有一小块供儿童娱乐的区域。里面的小朋友不算很多，于是我把豆豆也抱了进去。这里地面宽阔，比家里适合练习爬行。豆豆已经可以比较自如的往前爬了，但他的腿脚还是不听使唤。他只能依靠胳膊的力量，慢慢匍匐前进。

旁边一个十个多月的小宝也在练爬行，他已经非常熟练了，腿脚十分协调，嗞溜嗞溜爬的飞快。尽管他比豆豆大了两个多月，但外形还比豆豆小了一大圈，所以爬起来比较轻便。

豆豆追着一个红色的皮球爬了十多米，这是豆豆爬的最开心的一回了。晚上回到家里，兴奋劲都还没过，吃饭都不好好吃，一个劲在床上爬。

大概豆豆这一天玩的太累了，第二天居然病倒了。早上妈妈给豆豆喂奶的时候，发现豆豆头很热，于是给豆豆量了一下体温，37.9℃，不算太高。豆豆吃完奶后，体温又稍有下降，我猜想可能是昨天太累了，或是水喝少了引起的，也许过一会就好了。哪想到过了才一个小时，豆豆的体温就升到39.1℃了。一家人这时候都急坏了。

从查到的资料来看，豆豆有可能是得了幼儿急疹，或者叫玫瑰疹：一种没有太大危险的传染病，不需要治疗，三天后自然就会退烧痊愈。但是，联想到豆豆前一天跟一大堆小朋友疯了半天，我就怕他染上某种儿童间传染的炎症一类的病，于是还是决定送豆豆到医院检查一下。验血的结果是白血球偏低，排除炎症的可能，基本上可以确定就是玫瑰疹一类的病了。大家总算放了心。

到晚上的时候，豆豆仍然还有点发烧，但温度已经降下来了。大家本来担心豆豆晚上会闹的，结果他睡的还挺香，一点都没哭闹。早上醒来，我一摸他脑袋，原来已经退烧了，病好啦。没想到豆豆这么强壮，一下子就战胜了病毒。

豆豆第一次发烧，但是表现的非常勇敢。除了体温超过39℃那段时间，他有点发蔫，其它时候，吃喝玩乐都不影响。尽管非常难受，但是豆豆还是会被逗的呵呵乐。只不过乐的时候还带着点哼哼唧唧的腔调，看着非常招人怜惜。

LabVIEW的“项目”这个概念都是最近几年才有的，因此在这方面没有Visual Studio强大。在LabVIEW中，只有Project这一级，而没有Solution。这在开发大型程序时是有一些不便的。我觉得最严重的问题是程序模块划分不好做：所有的VI都只能放在一个Project中。最终生成的可执行文件是一个比较大的EXE文件；每次编译都有编译项目中所有的文件，很耗时；所有代码都混在一起，不容易彻底分隔开。

有些公司发布的产品不是可执行文件而是一个功能库，供其它程序调用的。他们或者以VI的形式发布，这样他们的VI源程序会被放置到用户的工程中去，很不合理；或者以DLL文件的形式发布，LabVIEW中调用DLL又很麻烦。

这个问题一直到 LabVIEW 2010 发布后才有所改善。LabVIEW 2010 增加了一种新的文件格式 Packed Project Libraries (*.lvlibp)。这种文件格式兼有原来lvlib和llb文件格式的一些优点，再模块化程序的时候，可以考虑使用Packed Project Libraries 。

LabVIEW中并非所有的控件都大小可调。大多数尺寸固定的控件都是用来给子VI输入输出参数的，不会用到用户界面上。但也有一些会用于界面，尤其是一些系统风格的控件，比如单选框、复选框控件等。

有些控件必须保持长宽比

大多数LabVIEW控件可以分别设置它们的高度和宽度。但有一些控件，比如仪表盘、旋钮等，它们的形状是固定的，只能是正圆。也就是无论大小如何，长宽始终保持一比一。

对于这样的控件是不能使用“Scale Object with Pane”，“Fit Control to Pane”的，LabVIEW对于这类控件大小的自动调整存在bug。对于它们，只能使用编程的方式调整尺寸。

界面最小尺寸

无论采用哪种方式调整界面布局，最好都为界面设置一个最小尺寸。因为任何控件都不可能无限小，所以整个界面缩的太小对于用户也是没有意义的。

这个界面包含五个控件，假设界面要求如下：水箱、油箱、波形图三个控件需按比例随界面尺寸调整，但他们三个控件之间的距离，以及它们距离界面边框的距离不能变化；信息框的长度随界面调整，但高度不变；停止按钮尺寸保持不变，且始终在界面右下角。

我们可以使用分隔栏来定位每个控件的位置。我为了方便在编辑时调整控件尺寸，以及确保控件尺寸和位置在多次调整界面大小后仍然准确，设置了较多的分隔栏。原则是让每个需调整尺寸的控件都有一个可以撑满的窗格。 之后，在控件的右键菜单中选择“Fit Control to Pane”，让它们的尺寸始终与窗格保持一致。

水箱、油箱、波形图、信息四个控件都需要设置为撑满窗格，而停止按钮由于大小不变，不需要有此设置。

我做的例子是比较极端的情况，一般来说不设置这么多分隔栏也可以，只要能保持每个窗格内只有一个跟随界面调整的控件就可以了。

界面上各个控件变化方式不同，全在于分隔栏对齐方式的设置。下图是分隔栏对齐方式的设置：

实际用户的界面一般不会希望显示这么多的分隔栏，可以参考前文介绍的分隔栏隐藏方法将其隐藏。

比如对于有一个波形图控件和一个停止按钮控件组成的界面，我们只需要波形图随界面尺寸的调整而变化。那么我们只要在这个控件右键菜单中选中它的“随方格缩放”属性就可以了。每个界面方格只能有一个控件被设置成随方格缩放。

被设置成这一属性的控件四个边沿的延长线都被深色标注出来了。当界面尺寸被调整时，控件四边到相应的VI前面板四边的距离是不变的，只有被这个四条深色实现包裹出来的矩形区域的尺寸会随界面一起变化。这样一来，可以保证程序的主控件随界面尺寸变化，而其它的控件位置保持稳定。

若主控件有多个，比如说界面上有两个同等重要的波形控件，那么只要把两个主控件Group在一起。由多个控件绑成的组，在外观布局上的行为属性与单个的控件是类似的。把这个组设为“随窗格缩放”，组里的控件就都可以随界面尺寸一起变化了。

当界面尺寸发生变化，上图中的“开始”和“停止”按钮之间的距离也会变动，因为他们一个靠近边界线左端，另一个靠近右端。若需要这两个按钮的相对距离保持不变，也把它们绑成一组就可以了。

俺们坐的是地铁

从肇嘉浜路出发，一站就到徐家汇了。

玩具店里好东西真多啊。豆豆看上了一个“歌唱小精灵”，可惜这个玩具不适合小小宝。后来豆豆又看上人家的小钢琴了：

商店逛累了，豆豆跑去下馆子。饭馆名叫麦当劳，可惜里面没有豆豆能吃的东西。豆豆休淘气了一会儿就走了。

豆豆玩了一天，浑身是汗。回家赶快洗澡

洗完澡睡一觉，豆豆最近喜欢趴着睡

最近天热，豆豆在家里穿上肚兜了。

这样设置之后的效果是整个界面按比例缩放，所有的控件都一同变化。但是它并不太精确，反复调整界面尺寸几次，再回复到最初的大小，可能会发现有些控件尺寸有少许改变。这是因为前面板的尺寸和控件的尺寸都只能是整数，这样每次调整界面后，控件与前面板尺寸的比例都会有所变化。也就是说每次界面调整都会引入误差，累积误差还是比较明显的。

比如下面这个程序界面包含一个波形图控件和一个停止按钮。

当用户改变界面尺寸时，我们希望停止按钮始终停靠在界面右下角，而波形图控件则撑满剩下的界面空间。这些变化都可以通过编程来设置，示例程序如下：

使用编程的方式使控件布局符合变化的界面尺寸，其优点是调整精确稳定。有些控件，比如仪表盘控件，只能通过这种编程的方式才能准确调整其大小。编程的缺点是较为繁琐。对于比较简单的界面，可以考虑使用分隔栏帮助界面布局，省去编程的繁琐。

使用分隔栏可以在前面板上分割出更多的窗格来。分隔栏在控件选板“[xx风格]->Containers”中。分隔栏有横竖之分，可以把原有的方块按照不同方向分成两块。控件无论被放在哪个窗格里，对程序功能都没有影响，只对程序外观有影响。

当前面板的大小改变时，分隔栏也可以跟着移动。在分隔栏的鼠标右键菜单中可以设置一个状态栏跟随面板的哪个边沿一起移动，或者是按比例移动。

在分隔栏的右键菜单最后两项用来设置分隔栏两侧窗格的一些属性。比如，界面划分成窗格后通常不需要显示窗格内的拖动条，在这里可以在这里找到相应设置的子菜单禁止其显示。

在分隔栏的属性也可以通过程序在运行状态下通过程序来设置。它算然不像控件那样在程序框图上有个接线端，但却仍然可以使用右键菜单创建它的属性节点和调用节点。有了这些属性和方法，就可以在程序中调整分隔栏的位置等属性了。比如下面这段程序可以从左到右挪动上图状态栏的位置。

在程序运行时，用户仍然可以再界面上移动分隔栏。若不希望用户改变分隔栏位置，可以在分隔栏的右键菜单中选中“Lock”，这样分隔栏的位置就被锁定了。

分隔栏没有隐藏属性。若希望程序运行时看不到分隔栏，可以通过改变分隔栏颜色来达到“隐藏”的目的。首先，把分隔栏的风格改为经典“Classic”，然后把它的颜色染成与程序框图相同，这样就程序运行时就看不到分割栏了。顺便提一句，分隔栏两侧的窗格是可以有不同背景色的。

窗格也是没有隐藏属性的。在程序运行时需要隐藏某个窗格，只要调整它周围分隔栏的位置，把这个窗格缩起来就行了。

程序界面尺寸发生变化，界面上的控件也必须随之调整。控件跟随界面尺寸变化有两种方式：

一种是控件尺寸需要跟随调整的。数据量较大的控件，比如波形显示控件，表格，大文本框等，常常需要调整尺寸以获得尽量大的显示区域。

而有些控件的尺寸最好是固定的，比如按钮，选择框等控件。它们虽然不需要调整尺寸，但是当界面尺寸变化时，它们的位置可能需要调整以获得最佳界面布局。

我打算接下来几天比较一下各种动态调整界面布局的方法，帮助程序员选择最适合当前程序的方法。

我看的是这本书的英文原版《Country Driving: A Journey Through China form Farm to Factory》，作者：Peter Hessler，这是我读过的第一部非科技类的英文原版书。科技类的书侧重介绍内容，词汇和语法都比较基础，即便英语水平不高，也较容易读懂。文艺类的书，语言本身也是看点之一，通常都比写得比较花哨，读起来难度就大了。还记得我大学那会，刚考过4级就以为自己可以阅读英文原著了，于是去书店随手买了一本，不幸却是《基督山伯爵》。回到寝室读了一页，一半的单词都不认识。我一下子就伤到了，从此再没读过英文原版小说。不过这本《Country Driving》属于纪实文学，比小说的语言朴素，没有太多文邹邹的修饰。而所写的故事又是发生在中国的，不存在文化差异，所以我读得还算比较顺畅。

《Country Driving》写的是一位美国作家在中国真实经历，就连书中的人物都是实名的。全书分三个部分：第一部分是作者两次沿着长城走向自驾游的见闻；第二部分记录了北京附近一户村民几年里的生活变化；最后一部分记录的是浙江一家民营工厂里工人们的生活。

书中翔实记载了村民和工人们的生活环境，经济收入，每日作息，乃至他们的心理活动，思想斗争等。我虽然生在中国，但也不曾接触过村民和农民工们的生活，所以读起来很有新鲜感。比如说中描述了一次村基层换届选举的过程：这种选举普通村民是没份参加的，但即便是党员也对现任的无能又腐败的村支书表示不满，企图另选他人。镇政府了解到这一情况后，派人到村里找党员逐个谈话，要求他们投票给现任支书。实际结果就是选举形同虚设。

外国人写中国的事，一大优点就是能够发现那些我们早已习以为常的不合理的地方吧。纵观全书，我不觉得作者对中国有偏见，但是他对于一些落后思想和制度的嘲讽还是非常辛辣的，不知道这些意味是否会在中文译本中体现出来。

关于人类起源，世界公认的观点是单一起源说，也就是：目前世界上所有的人类都起源自非洲，并在不太久远之前（大约7万年前），人类才从非洲走出来，扩散到世界各地。唯一与此矛盾的是中国官方的观点，也就是目前中国教科书上采用的理论，他们认为：世界上其他人种都是非洲猴子变的，唯独中国人是中国猴子变的。若中国人的祖宗独树一帜，很多问题会变得容易解释一些，比如：为什么别国百姓可以走在康庄大桥上，而中国百姓必须在河里摸石头？因为别人是旱猴子变的，而中国人是水猴子变的呗。

我个人还是更相信世界主流的观点，因为这一理论有一个坚实的证据，就是DNA的比对结果。对比两个人DNA的差距，可以计算出他们最近的共同祖先生活在什么年代；综合世界各地人类DNA的比对结果还可以推算出人类迁徙的路径。前些天看了BBC的一个科教节目，其中介绍了中国人的起源。历史上，先后有两批人类祖先先后迁徙到了中国境内，中国人种南北的差异巨大，很可能是因为他们的祖先在7万年前就分化开了。

7万年前，人类离开非洲，踏上亚洲这片土地后，就立刻分散开来，向各个不同的方向开拓。其中的一支，顺着印度洋沿岸，一路向东迁移。直到大陆的最东头，然后折向北方进入中国，这是大约5万年前的事。这一支人的皮肤颜色较深，颧骨较高。

另一路从非洲出来的原始人一直向北走，直达西伯利亚，然后就在那定居了。直到2万年前地球气候开始变冷，西伯利亚变成终年不化的冰川，这一支原始人只得南下求生，从北方进入中国境内。北方寒冷的气候使得这一群人皮肤颜色变浅，脸变扁平，眼睛变小了。这就是蒙古人种的由来。

虽然南方原始人进入中国早了几万年，但看今天中国人的外貌，还是北方来的基因占了主导地位。

豆豆体力超好，每天上串下跳，一刻不停。前两天给他洗澡的时候，他又开始疯狂的踢水。我说咱们这回就让他玩个够，看看他到底能坚持踢多久。于是，他考在我手臂上，两腿交替蹬水蹬了七八分钟，终于累了。我想，这下累到你了吧，可以歇下来好好洗澡了。结果他脚累了玩手：身子往前一倾，开始用手扑腾水。一会手累了，再往后一靠，开始踢水。如此往复几次，地板上水漫金山，爷爷实在受不了了，一把按住他的脚丫，开始强行给他洗澡。

豆豆现在狂爱举高高，只要我朝他伸开双臂说一句“举高高”，他马上就会兴奋的尖叫，然后俩腿猛蹬。由于举高高哄的他很开心，他现在跟老爸感情极好，常常抱着我又啃又亲。

豆豆学会玩手了。现在如果让他“挠”一个，他就会举起小手握拳，张开，握拳再张开。豆豆是个右撇子，目前还只会挠右手。

豆豆抱着爸爸的大腿：

天黑了以后给我租住的房屋窗外照了张像，上海的夜晚亮如白昼

这是子VI：

这是主VI：

程序运行结果如下：

看来它们是分享了同一个移位寄存器。

甚至子VI在不同的循环中被调用，它们也还是共用同一个顶层移位寄存器。比如下图这个程序：

运行结果：

只有把子VI设置成为每个实例都生成副本的可重入运行方式时，不同的子VI实例才会有独立的移位寄存器。

之前介绍的反馈节点内容：http://ruanqizhen.wordpress.com/2008/08/20/循环结构的反馈节点，http://ruanqizhen.wordpress.com/2011/05/22/反馈节点。

网上对这些附加的模块的介绍比较少，我最近自己研究了一下它们的功能。用于我工作中使用的是Lucene.net，所以我只查看了.net版Lucene所带的功能，可能比java版得要少。

• Analyzers\Lucene.Net.Analyzers\AR
  阿拉伯语 Analyzer
• Analyzers\Lucene.Net.Analyzers\BR
  巴西语 Analyzer
• Contrib.Net
  提供了一个按字母分词的分析器，可以用于子字符串搜索
• DistributedSearch
  这个项目居然连个工程文件也没提供，所以我也没实验它。从名字来看，大概可以做分布式搜索的。
• FastVectorHighlighter.Net
  这是一个用于在目标文档中高亮关键词的库。它的功能较Highlighter.Net更为复杂。但是在我所实验的 Lucene.net 2.9.2版本中，它存在严重bug，根本无法使用。
• Highlighter.Net
  具备简单的高亮关键词的功能。可以把索引中保存的文本拿出来，然后把搜索词从中挑出来。
• Queries.Net
  这个工具包由多个功能组成：
• MoreLikeThis
  输入一段文字，然后它可以根据输入的文本生成一个查询语句，在索引库中查找与输入文本类似的文档。它可以用来制作推荐系统：用户找到了一个文档之后，我根据这个文档的内容给用户推荐一些类似的文档。
• FuzzyLikeThis
  一个用于模糊查找的查询解析器，与lucene自带的FuzzyQuery功能类似，但是使用起来更加简便。
• BoostingQuery
  允许在查询的时候，设置“上下文词”和提升分数。若搜到的目标文档中包含有“上下文词”，则对目标文档的得分做相应提升（也可以使降低）。
• TermsFilter
  可以设定一组词作为过滤器，把包含了任意一个词的文档滤出来。
• Similarity.Net
  包含了MoreLikeThis这一功能。与Queries.Net中那个MoreLikeThis一摸一样。
• Snowball.Net
  用于词根搜索。西方语言，一个词义会有名词动词等不同词性，在做词根搜索，忽略一个词语的词性和时态，把包含这个词任何一种变换形式的文档都搜出来。
• Spatial.Net
  为搜索加入距离限制。可以用于地理信息搜索，比如搜索当前位置一公里范围内的加油站。
• SpellChecker.Net
  如果用户查询的词找不到答案，很可能是拼写错了。这个模块可以给出正确拼写建议。
• WordNet.Net
  实现同义词搜索。WordNet也是一个开源软件，它是一个字典，也包含了查同义词的功能。

Scratch是由麻省理工开发的一款图形化编程语言，针对儿童，专用于编程实现简单动画效果。我在Scratch的社区下载了几个小朋友们编写的动画游戏，还是非常有趣的。这让我想起了我小时候曾经看到过的LOGO编程语言，从计算机刚刚开始普及，人们就没有忽视如何帮助儿童来学习编写程序。

我猜专为儿童设计的编程语言，短期经济效益不会很高。毕竟除了厂商，愿意为软件开发工具付费的个人不会太多。但这项投资的长期回报是不可忽略的，学生们长大毕业之后，会把曾经的编程经验带入工作中。Modit作为一个纯工业领域的行业软件，完全采纳了Scratch的语法，可见说Scratch的影响力已经从教育迈向了商业领域。

LabVIEW也有针对学生使用的版本，还有和乐高合作生产的专供儿童编程玩乐高玩具的LabVIEW版本。但我觉得不足的是，即便是为学生们使用的LabVIEW依然保持着强烈的测控背景，依然在强调数据采集、测量、控制等功能。如果学生们一提到LabVIEW就想到测控，无疑会限制他们使用LabVIEW的热情和创新。而Scratch这种用来做动画的工具肯定会比做测控的软件更受孩子们欢迎。其实LabVIEW也可以搞个专门编写动画的版本给小朋友们的，让孩子们从小就习惯LabVIEW的语法，以后就离不开它了。

豆豆淘的要命，不睡觉的时候，浑身乱动，没有一刻停歇的。不过睡着的时候，还是蛮安静的:)

今天，我试着把豆豆快速举起来再放下再举起来，玩了几次。哪知道他一下子就喜欢上这个新玩法：一听见“高高”两个字就兴奋，整天搂着我的脖子，不停的撅起他的小屁股表示还要玩。但是据说小宝不适合剧烈晃动，我也不敢跟他玩的太疯。

豆豆现在的主要辅食是米粉和蒸熟了的香蕉。香蕉蒸熟以后闻起来酸溜溜的，我看着就没食欲，豆豆却视若珍馐。所以家里总少不了摆着几串香蕉。

早上，爷爷抱着豆豆出去散步，回来兴冲冲的说找到原因了。爷爷给豆豆擦口水的时候，一眼看到豆豆上牙床露出了两个白色的小尖尖，原来昨晚是冒头的小牙弄疼了豆豆。

一般小宝长牙都是一对一对的长，可是豆豆第一波只长出了左下方一颗门牙。一个月时间过去了，那颗小牙已经高高耸立于牙床之上，但它旁边的伙伴还是一点动静都没有。最后还是两颗上门牙占了先。豆豆现在有三颗牙啦！

不过台风也带来了意外的好处：由于短途的渡船都已停航，来参观的游客比较稀少，不会因为太过拥挤而影响旅游的心情。

普陀山这里自然风光很有限，所谓旅游就是看庙。我对烧香拜佛不感兴趣，所以我很少进入室内，每到一处就在庙外面练练摄影。

有些庙宇藏在深山里，安闲宁静。

有些寺庙临海而建，惊涛拍岸，颇有气势。

岛上最显眼的还是这尊铜制观音像，还没去参观她的时候，远远的就看到了。

台风只持续了一天就过去了，天气突然就从狂风暴雨转为风和日丽。

第二天的行程还是以看庙为主，首先去的是岛上规格最高的那座寺庙（庙太多，名字都没记住）。果然富丽堂皇，远远看去，和宫殿也可媲美。

除去寺庙，我们玩的唯一一处景点是千步沙，景色不错，唯一缺憾是海不够蓝。

我借用大家看庙的时间，脱离队伍去周围走了走，岛上颇有点幽静的田园气息，要是能生活在这里就爽了。

行程的最后一站是岛上最高的那座寺庙。寺庙都是大同小异的，然而登山途中的风光还是值得一看的。

按照广义相对论的解释：万有引力是不存在的，它只是时空扭曲的一种表象。如果时空扭曲可以产生加速度，我就可以按照下面的思路推断出有“绝对静止”的存在，而直觉上，我觉得又不应当有绝对静止。

“质量会引起时空的扭曲，一个在高维空间直线运动的物体，在扭曲了的四维时空中的投影是弯曲的，在只能观测到四维时空的我们看来，它似乎是受到了引力的作用而改变了运动方向。”这是广义相对论对于万有引力的的大致解释。对这一解释，我可以有个模糊的理解，但细节上却并不清楚。

首先，它没有很好的解释原本相对静止的两个物体如何可以在扭曲的时空中相对运动起来。比如：树上的苹果和地球本来是相对静止的，若不受力，苹果是如何掉落到地面上的呢？我自己能够想到的解释有两种：一是仍然有力的存在，也许万有引力是不存在的，但质量却可以引起另一种类似的力，导致物体的相对加速度，但相对论是认为这里不存在任何力的；另一种解释是，地球和苹果都在更高维的空间中，相对于这个“空间”在运动（也就是说有绝对的运动或静止），而它们在运动过程中在四维时空中的投影趋向于汇聚在一起，除非有外力不停改变它们的运动。按照这第二种解释方式：四维时空里相对静止的物体在高维空间中是相对运动的；而四维空间里相对运动的物体在高维中却又是相静止的。直觉告诉我这样的解释很别扭。

其次，相对论认为物质会扭曲周围的时空，但没有解释为什么会扭曲。既然质量可以扭曲时空，为啥不能认为是通过是加了力来扭曲的呢，还非要断言引力不存在。

最后，按照相对论的说法，质量引起时空的扭曲，那么运动的质量会导致时空扭曲的波动。这种波动以光速传播，也就是所谓的“引力波”。引力波是带有能量的，因此物质在运动时，即便不受任何外力，也会因为发射了引力波而损失能量。若物质可以将一部分能量传递给周围的时空，那么这个时空岂不是也就具备了能量（质量）。这样一来，时空和物质又有什么区别呢。宇宙根本就不存在所谓的“时空”，它只有物质的不同运动形式。

时空若是无限的，所有运动的物体都会因为引力波辐射而损耗能量，其动能越来越小，最终损失殆尽而达到“绝对的静止”状态。若宇宙有限，引力波可能会达到一个平衡的状态，类似黑体辐射。

EnableFrameRateCounter被设置为真时，Silverlight界面左上角会显示出几个和GPU相关的数据，其中包括动画刷新帧数。但是我搜索了一下，Silverlight似乎没有提供函数，可以在程序中把这个帧数读出来。MSDN中提供了一个间接方法来计算帧数，利用CompositionTarget.Rendering这个事件。Silverlight没刷新一帧，都会抛出一个CompositionTarget.Rendering事件，对这个事件计数，就可以算出每秒帧数了。不过，用这个方法计算出来的帧数，与EnableFrameRateCounter设置显示的帧数居然是不同的。

CompositionTarget.Rendering事件的发生次数与用户设置的MaxFrameRate和系统繁忙程度相关。而EnableFrameRateCounter显示出来的那个帧数还与Silverlight动画是否需要刷新相关。比如对于一个界面不怎么活跃的Silverlight程序，当Silverlight觉得不需要刷新界面时，它就不刷新，显示出来的帧数很可能是个位数，甚至为0。