by pluskid, on 2009-11-01, in 
一方面现在越来越大类培养了，另一方面我们自己的审视标准也在上升吧，总是有一种现在小课堂参与率不够高的一种“错觉”，反正觉得有些劳民伤财。所以，一方面现在我们开始降低小课堂的成本（比如，省略掉横幅这个较昂贵的宣传方式），另一方面尽量让主题更加大众化一些。
比如上次 quark 的关于 Word 的小课堂，就效果不错。说起来当时听说 MSTC 居然要讲 MS 的技术了，一些老朋友还深表诧异！ :p 而这次我来讲的 C 语言调试的课堂，其实主要是想讲调试的，但是还是在前面加了个“C 语言”就是要显得大众一点，C 语言现在是很多专业都要学的课嘛。
其实这个话题大概是从上个学期就开始酝酿。其实大概从那次（好多年以前了吧？ T_T）被丢了一个 NEO SDK 做的 C 大程让帮忙查为什么会运行出错开始，也是不是会有一些朋友来问我类似的问题，代码有多有少，我当然是很乐意帮忙的，但是特别是对于很复杂的代码，我甚至都没有办法跑起来，但后来我发现其实大多数时候错误都出在一些很明显的地方，比如文件未打开，内存未分配、未初始化等，如果知道一点点基础的调试方法的话，肯定能自己很快查出来了。所以，我觉得这样的东西还是有必要讲一下吧。哪怕是最基本的调试方法，可能也有许多人根本没有去尝试过的——大概觉得调试可能是一件很复杂的事吧。
不过，既然要讲，我也想把各方面都讲了。小册子准备了好久，查阅了各种我能找到的任何相关资料，以及自己以前的一些 blog 、笔记什么的，最后做到我自己都快要吐血不想再继续做了，才停下来，最终版本是 56 页，大概是到目前为止最厚的小册子了吧，最后得知打印工作居然是交给一个新人 mm 独自完成的，封面还用了硬壳纸，印出来发现好厚一本，吓了我一跳。而且 100 份似乎完全不够，虽然我火速抢到了一本在讲的时候用了一下，但是发现在结束后还是不知被谁趁乱 rob 走了…… T_T 所以，现在只剩下电子版了，而且我也是一改自己以前做小册子的风格，不是使用大纲式，而是采用类似于 blog 的语言来写，既然花了那么多心血，还是放到这里来让他有机会能传播得更广一些好了：
除了小册子之外，这次新人 PM 借了一个东二 200 人的教室，而且宣传方式也简化到只有 cc98 和海报了，所以都有点做好冷清的准备了（其实我是很期待能坐满的），但是最后没想到教室居然也坐了大半的人：
大概是小课堂里人来得最多的一次吧，估计已经不能叫“小”课堂了。而我准备的内容似乎也太多了些。其实我发现我大概讲东西有个毛病是讲得太快，本来觉得可以讲一个小时的东西，结果半小时就讲完了。于是在以前几次小课堂中发现了如果有实际演示的话，就不会那么悲剧了。然而这次的问题恰好反过来了，由于有大量的演示，导致进度太慢了，于是 houshui 都跑上来告诉我控制一下时间，于是我不得不跳过了许多实际演示的例子。
原本准备了四个部分（8g 篇、基础篇、实践篇和理论篇），并且打算在两个部分讲完之后来一个中场休息的，也由于时间紧迫省略了中场休息。而省掉了大部分的例子演示也严重偏离了我的初衷，这个时候我似乎有点能体会老师们的那种希望将自己所学倾囊相授的那种焦急了。其实我也预料到时间的问题（虽然没有想到会这么严重），所以临时开了一个 Windows 自带在桌面钟，但是那个钟似乎有 bug ，选了总在最前之后，窗口切换几次（特别是放映幻灯片的窗口）它就跑到后面去了，所以后来几乎没有起什么作用，我只好看旁边教室自带的那台电脑上的时间。最后讲完是差不多花两个多小时（是不是也是时间最长的一次了？），我也比较累，大教室，没有用话筒。
虽然如此，但是感觉还是不错吧，有一点比较欣慰的是，这次我讲笑话的时候下面都是能笑起来的。另外，这次我还精心准备了一个场景，就是最后讲调试必杀技的时候把那个多啦 A 梦玩偶拿出来，在听得很累的时候缓和一下气氛，结果看来还是相当不错的效果啦，可惜 houshui 好像没有帮我拍下来，5555，看来还是应该事先跟他剧透一下的，哈哈。 :p
此外呢，这次和小册子一起发下去的还有一份调查表，因为想要优化宣传方式啊，所以主要调查了下大家是如何得知这次小课堂的以及觉得效果最好的宣传方式，回头统计出来应该是很有用的一份参考了。当然还有关于本次课堂的一些反馈，从一些反馈来看，虽然是从最基本的如何建工程，如何编译开始讲，但是后面的许多东西还是让不少人听不懂，总的来说这次造成这样的结果大概主要还是我试图在一次小课堂的时间把太多的内容讲给大家的缘故吧，有点消化不了。 >_< 大致就是这个样子了，发现自己嘛，虽然讲了这么多次，还是会紧张的，也就这个样子了吧，似乎也不能完全是坏事，开场前还特地打印了一张 GDB cheatsheet 来看，不过其实是心理安慰作用居多。开始之后只要能快速进入状态就比较好了。发现我在讲的时候如果台下有那么几个能给一些反应的听众的话，我就大致能 follow 我原本计划的思路，所以我看观众的时候也大都是快速捕捉听得很入神的人吧，实际上是处于一个精神高度集中的状态了。 总之，做了一些尝试，得到了不少反馈和经验，希望 MSTC 小课堂这个老字号活动以后也越办越好吧！ 😀
下载文件名中的C写成小写了，直接点击不能下载。
re ls
帮人debug绝对是一件吃力不讨好的工作，深有体会……
“有一点比较欣慰的是，这次我讲笑话的时候下面都是能笑起来的”
= =
看来各人幽默的方式确实有差异啊……
@jinguoli
唔，多谢！这是一个大 bug 啊！ =,=!!
只看小册子真不过瘾啊，要是能看到视频就好了！
我觉得这次讲座各方面都好得让人对未来充满了期待，而一个主要的不足就如同你所察觉的，就是试图在一次讲座中讲太多的东西。关于这个问题，内容细致，周全而且还比较有趣，那么从静态的角度来观察，比如小册子和PPT本身是非常优秀的；从动态的角度来看，比如说整个讲座，过大的信息量和较长的时间可能会让不少听众跟不住你的思路，长时间的集中精神对听众来说反而更难，因为他们不像做报告的人那样紧张-,-。我比较能理解为什么为出现这样的问题，有时候好东西太多就是难以取舍，比如我订阅的blog的数量早已超出了我的阅读能力，就是舍不得删。我也在历次你的报告中观察到你在把握内容多寡的上的尝试，以你的性格，相信离掌握到平衡点也不远啦。
我还发现了一个现象，就是当你有极大压力的时候，就必然会讲得非常详细，非常娓娓道来，比如本科毕设答辩的第二场，不想第一场那样相对随意。同理如光哥，光哥在压力很大而又需要当众作报告的时候，就会采用那种我们熟悉的语调和身体微微后仰的体态。这些都是在压力下，大家潜意识地采用自认为相对稳妥的方式来应对吧。我的话，什么场合下当众讲话都会下意识的降低音调…
另外讲两个8g。
#1.本来我不想上台来和你说时间问题的，觉得影响不好。所以我找了纸，写了“注意时间”四个字在上面，还递给了第一排的Staff让他们把这个字给你看。但是，但是这些小朋友难道就没有看过《乱马》，不知道熊猫举牌子么…
#2.你拿出机器猫那会，我坐在最后一排，等反应过来再跑过来就错过最好的时间了。失格啊。
@houshui
是的，其实每次小课堂对我来说都是一次很难得的锻炼机会。看起来似乎是应该已经熟练了的事，但是其实每次压力和期待都是很大的。不过有一点毋庸置疑的是这样的锻炼机会需要更多地向我们下一代的技术主力来转移。
至于压力嘛，只要不超负荷，从来都不是一件坏事，我自己也有过体会，特别是高三一年。
啊！啊啊啊啊！原来那张调查表背面的四个大字是你写的？我事后看到以后还以为是某个听众对时间拖延得太久表示及其愤慨，愤怒之极所以在调查表上留下了这几个字呢，郁闷了好一阵…… T_T
官方消息：据itsuhane说你的那本小册子是被他rob走了。
小课堂的时间确实不容易掌握，我上次也没有想到会讲到1个小时，而且几乎没有停顿的情况下。这也和上次试讲了一下有关吧。
这次小课堂准备得很充分是有目共睹的，最厚实的小册子，桌面右上角的时钟，事先调整好的大字号，准备好的机器猫等等。这样想其实在很多方面还是很好的。
也有一些同学觉得是很容易的，填写不想了解GDB，完全听不懂的大多是大一新生，想想自己大一的这个时候，确实对GDB等等很反感呢（现在也没有太多好感 -.-）…
@quark
GDB 呀，关键是在 Linux 下除了用 GDB 还能用啥？
这么丰富的内容，可以考虑做系列讲座嘛，干嘛非要一次性讲完呢？我在公司里做技术交流的时候也是一大堆内容拆解成几次慢慢讲。听众也要有消化的过程的。
@pluskid
不调试就好了 -.-
@quark
太理想化了，很多问题一调试立即就能发现问题（或者相对容易一些），但是如果用其他方法来找的话，会让工作量增加很多。 :-/
@liancheng
关于小课堂的定位，好像我们有一直在思考，但是想出来的和实际做的总也还有一些差距的样子。
@pluskid
“好的”小课堂的标准会被诸多因素影响，比如新老学生的更迭，大环境的变化等等。所以调整肯定是永远没有止境的，关键是一直要有良好的反馈机制，无论是内部的还是外部的。
可惜是在zjg，去不了
@pluskid
可是很多程序没法调试。。。嗯。。
不过我挺喜欢gdb的。。。。只要回车就好了。。哈哈。。据说现在gdb还能rollback了？有人尝试过么？
[…] **[]这样的数据类型，写完后用pluskid上次在小课堂上介绍的valgrind检查内存发现没有泄漏，比较高兴 […]