Software Cinema

正在看一篇跟 Code Readability 相關的 Paper, 不知怎忽然想起大一剛進成大電機時, 學 Programming 的作業...

當然, 當時我學 Programming 與其說是上計概課學的, 不如說是自己學 + 認識的資工學長作榜樣居多, 但是書本上的練習跟上課的練習還是有差, 特別是你不想端出去的作業比別人差, 而且我們的計概課也不是一般呼嚨用的計概課.

我印象深刻的是一個 Hanoi Tower 的作業. 說到 Hanoi Tower, 其實我國中的時候就用數學的角度解過這個問題了, 但是寫程式是另外一回事. 稍微熟悉的人應該都知道, Hanoi Tower 是練習 Recursion 的基本入門題之一. 但是該作業有趣的是, 附帶了一個額外的加分題: 請用 Non-Recursive 的方式寫出解 Hanoi Tower 的程式 (當然, 要 step-by-step 輸出).

* 其實這題目有些書在 Recursive 章節後面也會加. 只是小大一是不會主動去看後面的練習作業題的 XD


那時候其實還不太會用 Search Engine, 而且 Google 在台灣也還沒有知名度, 很"傻"地就一頭鑽下去想解法, 以及怎樣寫成 Program, 還附帶要寫成 Document.

最後當然是有寫出來 ( 還上台介紹 = = 我大學生涯中第一次上台 ), 利用某些規律可以知道在三個 Towers 處在特定的 State 時, 就應該怎樣做 Transition 來到達下一個 State, 並且達到 Optimization. 也當然啦, 當時小大一是不會知道其實我在畫 State Transition Diagram 的 XD

其實在寫成 Program 以前, 我在找規律以及推導的過程, 本身就是 Programming 最重要的邏輯觀念之一. 可以在憑空找以及運算這些邏輯之中得到樂趣, 是後來可以成為一個積極的 Programmer 最重要的條件之一.

後來的作業印象中就比較偏向 Application 導向, 例如寫簡單的火車訂票系統之類的. 雖然其中也有很重要且複雜的 Scheduling 問題存在, 但是因為整個系統要考慮的 Functions 變多, 反而重要的 Scheduling 問題對於當時只是程式初學者的人來說, 變得不是那麼重要與有趣.

直到現在, 可能因為我們 Lab. 的大家習慣以系統角度通盤思考事情, 因此也反映到出給學生的作業上. 現在的作業寫滿整整兩頁 A4 的說明是基本 ( 一次作業一題而已歐 ), 前兩年甚至出現了高達六頁的說明 ( 印象中, 一樣是一次作業而已 ). 而看這作業說明的學生, 大多只是剛上大學, 剛要開始認真接觸 Programming 而已...

我們不禁應該思考, 這樣的作業美其名可以讓學生提早從整個系統角度思考 Programming, 可以更加貼近真實生活中的應用系統, 但是效果真的有比當初的 Hanoi Tower 好嗎 ? 如果我們並不期許計概課裡的所有學生最後都是一個好的 Software Engineer, 或是都要走 Pure CS 路線, 或許多些 Hanoi Tower 的題目能更引起學生自發的思考, 也更加容易傳遞 Programming 課程每次的教學重點.

剛剛有大一的學生到實驗室問計概助教一個教科書上的問題.該學生對於書上寫了:

要注意 Escape Character 的使用... 例如 "\1234" 會被視為 "\123" 與 "4" (懶得去抄英文原文, 直接用中文寫)

感到很奇怪, 不懂是什麼意思, 為什麼不是 "\1" 與 "234" ?

我覺得會注意到這個問題代表該位學生很認真地在看書, 想我自己剛學 Programming 時根本也沒注意過這個問題. 但是我覺得該位學生的提問方式, 其實曝露出了她在唸書時的習慣, 很可能是延續唸一般科目的方式, 只在書本上思考跟學習.

事實上, 在她已經會基本的 C Programming 情況下, 一個簡單的程式可以為這個問題帶來解答的線索.

<br />void main(){<br /> printf("\1234");<br />}<br /><br />
這個簡單的程式在一般的系統中應該會給出 S4 的列印結果. 再多試一下改成這樣 :

<br />void main(){<br /> printf("\1244");<br />}<br /><br />
會給出 T4 的列印結果.

從這兩個簡單的程式, "\1234" 會被視為 "\123" 與 "4" 是一個學生自己就可以驗證的事實, 因此真正的好問題應該是,

"\123" 是什麼 ? 為什麼系統會認得它 ? 為什麼會印出 S ? 為什麼它不在我學過的 "\n", "\t" 等等特殊字元裡面 ?

從而該位學生或許有辦法根據以上修改過的問題, 進一步分辨 Control Characters 以及 Printing Characters, 以及更深入了解 ASCII Code Table, 最終得到 "\123" 會被印出 S 是因為 123 是 S 在 ASCII 中的 Octal Representation 之猜測.

當然, 不能期待剛接觸 C Programming 幾個月的學生可以獨立得到最後的結論, 但至少在看書之外, 動手去找尋原因, 嘗試, 猜測以修正問題, 對於 Programming Learning 是很重要的.

News from GamePro : Game design professor beta tests a new grading system ( Prof. Lee Sheldon's project )

It's not a noval idea, but always an interesting practice.

我還記得唸大學時, 聽過成大資工的密碼學課程, 期末的 Final Project 是要各組設計一套 Public Key/Private Key 機制, 然後互相嘗試攻擊, 被攻破的組別會被扣除一定分數, 相對來說攻破其他組則會加一定分數, 當時就覺得這樣作很有趣. 類似的概念我最早接觸到應該是國小時看 MacGyver, 其中有一集是大學生各自設計獨特的門鎖, 也是要設法突破對方的設計. 我們 Lab. 也早在幾年前就開始嘗試 Game-based Programming Learning 給大一學生.


多元的上課跟訓練方式絕對是好事, 但是難免會受到設計品質跟評量標準一致性的限制. 但是話說回來, 出了學校, 哪裡還有一致的評量標準呢...

不過換個角度來想, 如果不要把眼光侷限在傳統學校內, 而是放到更加專業的公司訓練課程, 或許很有發展空間. 許多公司的工作其實充滿大量的 routine work, 有遠見的老闆會設法保持員工的活力, 如果有專門的課程訓練公司, 可以為不同種類的公司及團體設計特殊, 有趣的學習課程, 而不是像目前許多應付了事的電腦職訓課程, 或許意外地有商機 ?

前幾天寫了關於 Audi 的 Travolution,進而想到了兩個相關的題目, 蠻適合給大一學生作 Final Project 的. ( 話說為什麼我會在颱風風雨中騎機車時想到這個呢 = = )

1. 真人版 Travolution

第一個是利用 Wireless Device 直接模擬 Audi Travolution 的運作. 可以在電機系館一樓的空間劃定線格代表街道跟路線, 架設假的紅綠燈, 用不同的 Wireless Device 放置在紅綠燈定點, 就跟 Audi 在真實的紅綠燈上作的一樣.

學生手上拿的是 Notebook 或是 UMPC, 同時學生寫的作業就是要模擬 Audi 在汽車上的 Client Software, 必須時時提醒駕駛員目前的時速應該控制到多少. 整個距離可以用等比例作規劃, 學生就拿著 NB 把自己當作汽車在跑, 感覺有點像大富翁 :p

中間可以加上一些特殊事件, 道路速限, 道路維修, 臨檢等等, 就更像大富翁了. 同時學生之間是需要彼此競爭的. 不過由於這是給大一學生的 Project, 因此基本的環境架設就要由 TA 負責.

2. Travolution 模擬遊戲

跟真人版的一樣, 只是在模擬遊戲中, 學生必須寫出 Strategy 來控制所有的車輛, 從一個既定範圍的四周會不斷的有新的車輛湧入, 要到達特定的出口 ( 一張圖有許多出入口 ), 同樣道路有許多的特性, 中間當然也會有紅綠燈的出現, 而最終目的是要讓所有車輛所使用的平均時間最少.
這樣的模擬遊戲當然也可以讓不同的學生彼此競爭, 只要讓新湧入的車輛分別受不同的 Strategy 控制即可. 同樣的, Strategy 可以執行的 Environment 也需要由 TA 去建構.

這兩個遊戲的目的都是希望透過進行跟業界真實產品類似的作業, 讓學生可以比較容易想像自己的 Programming 可以用在甚麼樣的地方, 發揮甚麼樣的價值.

昨天經過別人的推薦在 YouTube 上看到芬蘭學生利用宿舍大樓玩貪食蛇的影片. 在 YouTube 上利用PIOW 或是 P.I.O.W. 作搜尋可以找到應該是同樣的一群人玩的其他花樣.

這其實不算是甚麼新的東西了, 也常看到夜晚利用商業大樓作同樣的事情, 像是求婚, 假日煙火節慶等等.


雖然不是很清楚背後的工作原理, 不過對於電機資工學生來說應該也不難想像. 比較笨一點的就是在電燈開關上裝設可程式控制的電機裝置, 但是這很麻煩, 也可能會破壞原本的電燈開關設施. 或者我們可以製作簡單的嵌入式設備, 結合電燈以及可程式化的 IC 版作控制. 但是這會有同步的問題, 很可能無法做到影片中那麼完美.

不過呢, 加上個簡單的 Wireless 裝置, 利用一台 PC 作 Server 來發出命令給所有房間內的嵌入式電燈裝置, 應該就差不多可以做到類似的事情. 如果需要不同的顏色, 可以在一個房間內準備多個電燈設備, 或是複雜點利用多顏色的電燈, 一樣透過程式控制.

想起來很複雜, 不過其實只是中間加上了不同的 Components 接起來而已, 基本的控制概念與想法, 其實跟所有電機資工學生大概都會碰過的七段顯示器控制, 其實沒什麼兩樣. ( 圖片取用自這裡 )


不過有多少電機資工大學部學生, 會聯想到七段顯示器呢 ?

不過反過來說, 這也未嘗不是一個好的教材. 可以把簡單的七段顯示器控制, 加上 Wireless 網路概念, 馬上就可以讓學生玩一樣的事情. 去建議系上的微算機實驗課程, 把簡單的七段顯示器控制換成這個好了, 然後期末要利用電機大樓玩一樣的事情 :p

搞不好幾年後會出現學生用這招在學校裡玩告白 XD

就在 Java 成為 C/C++ 之外主流 Programming 課程使用語言沒幾年後, 對於 Java 適用性的討論也逐漸開始, 主要以興起的 Scripting Languages 為挑戰對象, 其中又以 Python [1][2] 以及 Ruby [3][4] 為多.

大部分的 Papers 是以 Languages 的特性去論述改為使用 Scripting Languages 的優點, 以及目前使用 Java 對於學生太過複雜等. 不過通常這些特性與實際學習上的影響之間, 有甚麼樣的連結很難說清楚, 而透過問卷對於學生的調查, 通常又受限於問題內容的表達方式, 使得調查結果是否能反應特定的問題有所疑慮.

相較之下我就喜歡 [1] 的說明方式, 利用範例程式碼本身的資訊來比較. 例如一個簡單的 Java Hello World 程式碼其實就暗藏了相當多的 Programming Concepts ( 以下所有圖片取用自 [1] ),


相對來說 Python 的程式碼就比較不具有學生不容易在短時間內理解的資訊 ( 可惜 Paper 沒有直接用一模一樣的程式碼來比 ),


這是很具體的比較, 就我之前當 T.A. 的教學經驗, 其實學生最困擾問題之一是, 在沒有面對任何 Programming Languages 經驗的情況下, 一下子就要弄清楚一段程式碼文字, 裡面一堆不認識的詞彙. 想像如果我們在學英文時是被要求直接看一段英文段落來學, 即便已經知道單字了, 也會是很痛苦吧.

另外在 [1] 中, 也利用一小段落說明 Java 比較適合作為 Second Programming Language to Learning. 基本上我同意這樣的意見, 但是目前似乎在 Python 到 Java, 或是 Ruby 到 Java 之間, 沒有為 Novice Programmer 去探討在 Syntax 以及 Semantics 之間的銜接, 以降低兩個階段之間轉移的 Learning Curve, 同時讓 Student 知道學習不同的 Programming Languages 之間, 可被轉移 (Transferable) 的學習經驗.


References

[1] A. Radenski, " Python First : A Lab-Based Digital Introduction to Computer Science," Proceedings of the 11th Annual SIGCSE Cconference on Innovation and Technology in Computer Science Education, pp.197-201, 2006

[2] Linda Grandell, Mia Peltomäki, Ralph-Johan Back and Tapio Salakoski, "Why Complicate Things?: Introducing Programming in High School using Python," Proceedings of the 8th Australian Conference on Computing Education, pp.71-80, 2006

[3] Robert J. Sheehan, "Teaching Operating Systems with Ruby," Proceedings of the 12th Annual SIGCSE Conference on Innovation and Technology in Computer Science Education, pp.38-42, 2007

[4] A. Ortiz, "Language Design and Implementation using Ruby and the Interpreter Pattern," Proceedings of the 39th SIGCSE Technical Symposium on Computer Science Education, pp.48-52, 2008

這篇 Paper [1] 介紹了一個以 Completion Strategy 為中心的 Programming Learning System.

Paper 中對於 Completion Strategy 的說明如下 :

The completion strategy uses well-designed programs as basic programs to be completed,modified and extended. The completion strategy suggests that the learning contents or programming skills should exist in the well-designed programs. These model programs may be complete or incomplete, and it is students’duty to modify or extend the original model program.

說白一點其實 Completion Strategy 跟 Fill-In-The-Blanks 有點像. 最單純的一種就是克漏字填充, 讓你清楚知道前後文, 請你填出正確或是合理的句子. 在 Programming Learning 中當然就是特定的語法, 或是變數宣告, Method Call 等等. 當然也會有比較複雜的情況, 例如留下一整個 Method 的內容, 要你根據 Spec. 或是說明, 把特定的演算法在該 Method 中實現. 這又比較像是利用 Design by Contract [2] 先規劃好框框, 再請你完成內容.

再有一種情況則可能是請學生 Extend 特定的 Class 或是 Function. 例如可以利用 Observer Pattern, 請學生建構自己的 Observer, 而教師利用 Subject 送出 State Information 去測試. 我以前給大一學生出作業時也作過類似的事情. 在 Paper 的敘述中也提到 Modification 的情況, 可能請你把某個 Depth 很深的 Loop 利用 Recursive 改掉, 或是修改某個 Function 的運作等等.

不管是哪一種, 基本上都是特過特別的規劃, 使得學生在完成練習的同時, 可以知道 Program 運作的細節, 以及學習到特定的 Programming Skill & Experience. 而在單一題目之外, 需要考量的還有如何安排一系列相關的 Completed/Incompleted Problem 給學生, 同時藉由學生的學習情況, 動態決定下一個題目該如何選擇以及製作. ( 以下圖片均參考取用自 [1] )


如上圖, 此 Paper 所提出的系統中, 具備一個 Problem Database 儲存各種 Problems. 一個 Problem 由主體的文字敘述, 以及相對的 Solution 組成. Solution 通常又是以數個 Templates 依序組成., 如下圖表示 ( 正確來說下圖的例子是 Problem Extension, 不過跟 Problem 的格式是一樣的 ) . Templates 被收納在 Template Library 中. 一個 Template 其實是一個 Code Slice/Fragment, 但是把其中要給學生填入的部分事先作宣告, 而在一個 Templates 中也允許嵌入其他的 Templates. 如下圖所示, 在 Average Template中, 也利用了 Output Template.

由於從 Problem/Solution 到 Templates, 以及 Templates 之間的組成關係, 因此一個給學生的 Completed/Incompleted Problem 的行程事實上是透過數個 Iterations 的 Expansion 所形成的, 例如 Paper 中所舉的例子 :


在第一張圖中央的 Problem Generator 具有一個 Learning Operator, 負責根據 Evaluation 結果決定下一個題目是什麼. 其實這個部分以及 Problem 之間關聯性的設計, 是我覺得整個系統是否有效的關鍵之一, 但是 Paper 並沒有在此著墨太多, 畢竟這應該是屬於 Completion Strategy 本身的問題了. 但我認為如果把問題縮小到Programming Learning 的框框下, 其實還是有探討的空間, 只是可能無法得到一個完美的答案, 就像盧梭無法為愛彌兒設計一個完美的教育流程一樣.


References

[1] Kuo-En Cheng, Bea-Chu Chiao, Sei-Wan Chen, and Rong-Shue Hsiao, "A Programming Learning System for Beginners - A Completion Strategy Approach," IEEE Transactions on Education, vol.43, no.2, May 2000

[2] Bertrand Meyer, "Applying Design by Contract", IEEE Computer, vol.25, no.10, pp.40-51, October 1992