昨天接获通知，到出国前的日子，有四天必须出差外训，而且四天
外训结束后的隔天就要出国，等于我一下子少掉了四天时间可用。
外训的重点跟我这次负责检测的设备有关，所以那四天我也必须专
心上课(可能要做大量笔记)没办法干嘛。这次的设备是第二代，我
以前职务调动到目前的单位是在第一代设备安装完之后，所以我等
于没受过完整的正规训练就直接投入了第一代设备的维运工作，只
不过这也刚好适合我─先实际进行设备维运，再慢慢补足设备相关
知识，对我来说比较方便，因为单位急需的是一个协助维运的人力
，而不是一个什么都要先懂的人力。因此这次的外训对我来说蛮重
要的，因为我已经有实际先摸过一二代的设备了。
那我在sanc其实也是这么做的，我一开始当 wiz，我先做的事就是
cp 其它 wiz 写好的 code 去做增改，所以我很快就写好我的第一
个区域跟其它物件，之后再借由对照 code vs 实际执行的结果,快
速了解了写区域所需的许多必要物件的写法。
但是这有缺点:
一、因为实际上不了解 code 所以使用了非常多错误的语法，在之
后都必须花很长的时间修正。
ex: for(i=0;i<sizeof(users());i++)
一些没什么效率的写法也都是在之后才慢慢重构，例如家族系
统就因此重写过一次(从 write_file 改 save_object())。
二、初期抓 bug 的技术很差，这是因为我对于 mud 源头函数的呼
叫流程并不清楚的关系，如果我清楚函数呼叫流程，对抓 bug
最有利的一点就是我会比较容易判断 bug 发生点。
那因为不了解，只好每次都用试误的方式去抓 bug，因此之前
只要 sanc 发生 bug，运气好的话可以很快找出 bug，运气不
好的话就会拖长 bug 改掉的时间。
三、核心的 mud code 因为很少接触，所以我完全不了解那些code
是做什么的，事实也证明不了解那些东西还是可以 coding 及
做管理甚至写出各种系统(我在公司也有写设备维运系统)，但
是，不懂这些，就不能称得上是一个称职的 mud 管理者。
从上面亦可知道，可以让我当 semi-administrator & operator，
其环境必然是“有真正的主力人员在”以及“可允许维运人员犯错
”，以sanc来说主力人员就是 nobu 及 satin，以公司来说就是职
阶比我高的同事。
然后随着我实际接触及维运的时间越久，我才能渐渐了解更多我以
前所不了解的东西，从而使理论与实际顺利 merge，这时间通常很
漫长。
讲这么多，主要是想说明“所以这次的外训对我很重要”，这是第
一次真正有机会从设备维运的最源头，开始了解整个系统架构及运
作原理。
我这礼拜就要将设备测完，光是测之前看完那些测项的细节就会耗
去今天一整天的时间，那因为在我之前的其它人的进度有落后，原
订明天一整天测完我的部份，可能也会因此延后到星期六下班前才
测得完(说不定还测不完)，因此从我看完那些细节后，到实际进行
测试前，以及整个星期日，我都会拿来编完游日行程手册的初稿。
下礼拜则是设备的完测，行程手册完稿印出，准备公司月底报告，
只会有零碎的时间。再下礼拜就是外训＋出国，要到回国后才会再
开始有空。(但平常工作量也会变多，要同时维运新旧两套设备)
laechan