寫程式這回事

2016年2月下旬,接到一通電話的邀約,於是我得以共襄盛舉,在《遠見雜誌》報導「程式教育列入課綱」的專題中被報導,很感謝陳芳毓副主編的邀請與訪談。除了讓「社區醫療群地圖」再一次的在媒體上曝光 (上一次是 2014年 iThome 的報導),也提醒我重新省視寫程式這項技能的對我的意義。

至今我仍然不敢自詡會寫程式,如果用類似維基百科社群使用的巴別分類來描述我使用最熟練的 R 和 Python 的能力,大概都只有等級1:「可以讀懂用這種語言寫成的文章,並且回答一些簡單的問題。」我仍然會犯一些低級錯誤,偶爾需要翻閱小抄和文件才能分得清 Python 的 list、tuple 和 set 使用上的差異,也非常依賴 Google 和 Stack Overflow。 Coding style 仍然毛病不少,有時會因為習慣不夠好而嘗到苦果。

接到電話時,我腦海想起許多位比我還會寫程式的醫師 (eg: PCman、蔡依達醫師、曾經講解 Excel 巨集語法給我聽的彰化基督教醫院核醫科主任楊光道醫師…)。這樣的我,何德何能在大眾媒體以一個會寫程式的人的角色曝光呢?

不過我還是選擇站出來現身說法了,以一個只會寫一點點程式的人的身份。我想以自己做為例子,表達我對「程式教育列入課綱」這個政策的看法與想像。

我希望給讀者的印象不是「沒有接受過科班訓練也會寫程式」這樣的讚嘆 (我承認反差萌是很討喜的),而是「即使不是以寫程式為業,入門的寫程式的能力對一般人也是有幫助的」。所以我舉了兩個例子:社區醫療群地圖公務人員終身學習積分批次匯入 *.csv 產生器。這兩個例子都是我試圖解決從我這個角度觀察到的問題,難度也正巧是我的程度可以克服。這些問題如果不用自己寫程式的方法解決,也會是「請別人寫程式」來解決。可是如果腦海中沒有跟機器互動的想像,連如何「請別人寫程式」都不一定說得清楚。我希望未來程式教育課綱給學生的第一個收穫:透過做中學的過程,學會抽象化的邏輯性的思考方式,讓機器為你所用。

報導中也提到 (不過限於篇幅較為簡化),我第一次接觸 Python ,是大學五年級、六年級,在高雄醫學大學校園網路研究社的社課。不過因為那時沒有需求,這項技能就荒廢了。後來之所以認真精進這項技能,第一個契機是2013年工作上有統計的需求,這時我已經是個自由軟體的頑固份子,想藉此機會學習裝在電腦好幾年卻從來沒碰的 R。一開始卡關卡了一個月,在社群的指導才走出來。也因為其他需求,才又再認真的學 Python。很多學習過程是任務導向的。這也是我擔心未來程式教育課綱的學生,可能沒有具體的需求,因而再感受到益處之前,先被學習曲線打擊自信心。這是最不容易教的,也很有可能是最痛苦的。

上一段提到的難關突破之後很快就能應付基本的統計需求 (eg: student’s t-test、 Chi-squared test)。也在這段時間接觸 R 和 Python 社群的活動,在社群的分享中,看到許多其他人的點子,因而受到啟發與刺激,我的想法也才一步一步能夠落實。我先前也在一篇文章紀錄社區醫療群地圖發展的過程中是怎麼樣的被啟發。這也是我希望程式教育課綱達成的目標:互相觀摩、互相學習、互相啟發。

如果你看到這裡,我希望你像我一樣,踏出第一步。我也期許各個不同領域的朋友,都可以審視一下自己的專業,是不是可以藉由資訊化更上一層樓。就像我的一位水利背景的朋友所說,「每分每秒都有大量的資料產出,不 coding 怎麼處理啊?」

ps: 去年考完專科考試之後,我想要用 django 來重新改寫社區醫療群地圖,現在還在看 django 的 tutorial。如果你有其他想法也歡迎把這個點子拿去用,我樂見這個資訊被傳播,請不必介意。

廣告

為什麼要 Open Source

最近被問到對「Open Source」的看法為何?為什麼希望自己的專案採取這種方式釋出?我第一時間的答案是「這樣這個專案即使我無力維護了,不再維護了,它也可以永遠的活下去。」我想到的具體例子是蔡志浩老師的中文斷詞演算法,即使經過了那麼久,程式碼已經被一改再改,甚至換了很多個開發環境,演算法依然被採用。這是有點浪漫的說法。

這幾天的沈澱,我想到一個比較現實而且霸道的理由。以前聽說過 email (還是 TCP/IP ,忘了) 在發展的時候,也有類似功能的技術在發展。不過因為它是開放的,容易取得的,所以它逐漸在市場上獲得優勢,取得「標準制裁權」,這個標準經過了三十年還是大同小異。

如果期待研究的結果能夠被廣泛的使用,甚至成為 guideline 被依循,除了使用者,也要讓製造商能夠且願意使用,甚至創造一個平台邀請它們共同制定標準。這個道理也逐漸被以前否定 Open source 的商業公司認同與實踐,例如微軟。當然一切的前提都得是,研究本身的方向和價值被肯定。

HTML 簡報使用經驗

從今年一月起,我做了一個挑戰:除非因應特殊需求外,只用 HTML 簡報工具。至此已經歷半年有餘,在工作上、社群活動上都各自累積一些實戰經驗,在此做一些整理。

背景

以下是我歸納一下我的簡報風格、之前累積的簡報工具經驗和我選擇 HTML 簡報工具的原因。若有朋友打算參考我的方法,請先看看以下的敘述,確定我們合不合拍。

我最近幾年的簡報風格大概分成兩種狀況:一是演講內容是原創或是已有相當程度的內化者,例如自己的觀點、開發歷程 [1-2] 或是簡介很久以前習得的知識 [3],這一類的的簡報,我會使用類似 Lessig/Hardt/高橋的風格,用非常大的字體和圖片,搭配我發自內心的口頭或肢體語言,不過遇到一些需要強調結構和脈絡的時候,會用條列式的方式表示樹狀圖的綱要;另一種狀況是,簡報的內容不是我原創,而我是整理其他文獻,甚至直接借花獻佛的,例如在科內的 Journal reading [4] 等等,這種狀況因為我的英文不夠好,沒有足夠的縮寫能力 (此處指擴寫的反義詞,而非 abbreviation),也因為我不希望不正確的傳達原作者的意思 (好比講別人講的笑話就是不夠好笑),我會傾向原汁原味的節錄 (例如整個子句,甚至整個句子)。當然為了比較精簡的傳達,會稍微作些結構上的整理;如果能力許可,盡可能用表格或圖片方式取代文字。

另外我對工具的掌握及期待如下:我偏好跨平台及開源的方案。我自認對 OpenOffice.org Impress、LibreOffice Impress、Apache OpenOffice Impress和 Microsoft PowerPoint 2003版以前 (含)都有中上的掌握,我會製作開放文件格式的簡報範本 (即 OpenOffice.org、LibreOffice、Apache OpenOffice 預設的檔案格式),先前在本部落格也陸續發表過。格式方面,我偏好整份文件很一致 (uniform),習慣透過修改範本或制定格式以達成我的需求。舉例來說,假設我需要在文字中的強調是用紅色粗體,如果可以在範本裡面設定一個格式叫做「強調」,裡面已經設定好為紅色粗體,若是我心血來潮,我希望「強調」的字元除了紅色粗體,還比原來的段落字號大兩號,也可以作這樣的設定。

我選擇的 HTML 簡報工具是 shower.js。原因是預設的風格有兩種 (Ribbon 和 Bright)和已經定義好的配置,都很合我的胃口。因為我看地圖的習慣是某一個方位固定向上 (會隨地區而變,不一定是北方), impress.jssozi 這類座標系統很彈性的工具我覺得沒有發揮它們的優勢,就沒有嘗試過。編輯器是 Vim 或是 Notepad ++

簡報軟體 vs HTML 簡報 的比較

HTML 簡報最大的優勢,也是先前我使用的簡報軟體皆無法取代的優勢,在於它可以直接插入一些網頁的元件,好比 iframe,例如在 Code for Healthcare 的簡報 [1] 中,我插入了 OpenStreetMap 的地圖,可以現場示範如何使用。而先前我使用過的簡報軟體最多只能抓幾張截圖,沒辦法跟截圖互動。

另外一個 HTML 簡報的優勢是,它滿足了我透過修改範本或制定格式滿足需求的偏好。這是先前使用過的簡報軟體不能完全滿足的。有趣的是,它們的姊妹作例如 Apache OpenOffice Writer 或 Microsoft Word 都有這樣的功能,而針對簡報則沒有設計。還有一些優勢包括,跨平台、大多狀況不需額外播放環境安裝程式,因為只要播放的電腦 browser 不要太舊 (例如 IE 8) ,基本上不會出問題,最多就是字型的問題 (若很在意,可以放字型檔到目錄,或是指定遠端甚至雲端的字型)。

而我遇到的 HTML 簡報的最大的缺點是,網路的依賴,例如前面所舉的 OpenStreetMap 的 iframe,如果真的非解決不可的話,可以 clone 一份到 local 端 (當心著作權議題啊)。

另外一個缺點則是因為我選擇的編輯器不是圖形化介面的 (graphic user interface, GUI),而是純文字的 Vim 或 Notepad ++,所以編輯的時候會同時需要開編輯器和 browser 確認排版的狀況 (其實只是要確認字或圖片塞不塞得下,會不會太大),總會覺得螢幕永遠不夠大。有時候會需要處理截圖,那又需要開啟圖源、檔案管理和圖片編輯程式  (我用的是 GIMP),程式切換的問題更加雪上加霜。

有些時候會需要用到簡報軟體提供的一些預設圖形,例如流程圖等等,我會選擇幾個方法來處理:1.製作成點陣圖 (eg: png, jpg format)或向量圖 (eg: svg format) 2. 使用一些 javascript 工具 (例如: flowcharts.js),現在 javascript 在網頁前端的社群非常活躍,只要充分的 survey ,應該都可以找到夠用的工具。至於有些人覺得 HTML 簡報的頁面配置很單調,我想只要抄襲熟悉 CSS 的語法就可以克服,對我而言不是真正的問題。

一些比較雞毛蒜皮的優缺點這裡不特別提出討論。總而言之,HTML 簡報因應我目前的大多數需求,是利大於弊的,我想我會繼續用下去。

附註

[1] http://mcdlee.github.io/20140418_CfH @Code for Healthcare

[2] http://mcdlee.github.io/gisVisualization/ @COSCUP

[3] http://mcdlee.github.io/phase-analysis-tutorial/ Phase analysis 簡介 (對科內實習醫師及其他同仁)

[4] http://mcdlee.github.io/Ra-223/ Ra-223 therapy for metastatic prostate cancer (簡介 Ra-223 治療,對科內同仁,節錄原文者,屬合理使用)

社區醫療群地圖:寫在媒體曝光之後

今天因為這篇 iThome 的報導獲得很多注目。其實我也有點驚訝,因為寫稿的記者在這之前沒有採訪我或是跟我聯繫。不過值得欣慰的是,報導的內容和我的本意沒有太嚴重的偏差,在這裡感謝這位記者朋友為我提高能見度。

這個專案的發想大約是去年底今年初,一開始的目標就是在夏天的 COSCUP 能夠有初步的成果可以發表,至少是閃電秀。過程中,很幸運的接受到很多朋友的啟發,比較直接的有林育漢分享的 Python 套件 lxml 和陳奎銘分享的 R套件 rCharts,當然還有發起和主持 Kaohsiung.py 和 Kaohsiung R user Group 的陳嘉葳和 Victor Gao 以及參與並構成整個氛圍的其他參與朋友。大約在四月初清明假期就累積到了現在的成果。我也陸續在三個不同的場合向不同的對象發表過,演講的重點也略有不同,分別是4月18日的 Code for Healthcare (15分鐘,活動頁面投影片)、4月22日的台灣開放街圖社群 Webinar (30分鐘,活動頁面投影片錄影) 和 7月19日的 COSCUP (40分鐘,活動頁面投影片錄影)。若是對這個專案有興趣的朋友,歡迎在 github 上找到它, fork 或是提供 patch 都非常歡迎。

在 COSCUP 的演講,時間上有點沒掌握好,遺漏了一些哏,講的內容也沒有擊中聽眾的甜蜜點,講這種撈過界的題目,自己的體悟也不夠深入 (上台前還很擔心會被問倒),能夠獲得如此迴響,實在很感謝各位朋友的抬愛。政策更透明的被看見,我想才能夠讓它被實踐的更完善,不論是利用率或是施行細節。很高興能夠有這樣的成果,希望只是起頭。

對我而言,自己寫程式就像自己下廚一樣,雖然無法成為名廚,但至少能讓自己免於餓死;雖然沒辦法煮出華麗的菜色,至少可以帶自己認識食材的風味。學習寫程式就從解決自己的問題開始。

開放的地理圖資,更好的地圖

在日常生活中,地圖常常扮演不可或缺的角色,例如在觀光景點遊覽、在機關行號內的各個單位移動、公路地圖、森林步道、鐵道、歷史建物,地圖總是比起其他的表示方式更直觀。近幾年,隨著行動裝置的發展,電子導航也很快的攻佔汽車內裝市場。

雖然地圖對很多人來說是理所當然的存在。但是收集可信的地理圖資所耗人力物力是相當龐大的,好比如果要做到可以導航的資料,必須先知道每個路口的左右轉限制,每條路的車道數量及設計;商店則要蒐集其名稱、類型還有營業時間。

當牽扯到商業利益的時候,問題會很複雜。首先,地圖取材自現實的地貌、地物,若有抄襲等侵犯著作權之情事,受侵權的一方很難舉證,於是有了在自己出版的地圖裡故意放些小錯誤的應對方法,而且直言不晦。此外,一些人口較稀少或是經濟較不發展的地區,因為市場需求較少,比較少有供應商願意投資如此龐大的資源去建立當地的地圖,例如台灣的鄉間。比較有名的例子是,2010年海地發生地震的時候,最新的地圖已經是30年前出版的。有商業考量的供應商,也常常只注意到他們想要討好的群眾,例如 Google 地圖沒有標示各河流的名稱,在衛星空照圖上對鐵路的標示較簡陋。另外,即便是財力雄厚的公司不計成本的維護地圖,其即時性往往差強人意。

此外多數的地圖釋出的格式都是不開放的格式,例如紙本地圖是印刷的出版物,公路總局提供的行車指南是圖片,即便破除版權的限制,要設計一套應用程式來做進一步的利用困難重重。

OpenStreetMap 是一個以類似 Wikipedia 的機制運作的全球地圖,只要註冊帳號,所有使用者都可以自由的編輯。由在地人編輯在地地圖,除了實用,也注意到很多風吹草動。此外,他的資料格式是開放的 xml ,授權也是開放的 (截至目前為止是 CC-BY-SA 2.0 ,預計之後會全面改為 ODbL),第三方的應用程式多元而且跨平台,而且允許其他出版品的再利用。試想假若結合政府的大眾運輸即時動態資料,對於發展觀光或推動環保都有如虎添翼之效。

有人質疑依賴志願者運作的計劃真的可以信任嗎?也有人質疑沒有審核機制的編輯會不會有故意或無意的錯誤?然自由軟體運動發展 20 年,已有很多方法可以預防或是善後,OpenStreetMap 亦同 (例如:undo)。看看歐美各國的地圖多麼詳盡,台灣何以不能呢?

OpenStreetMap

長久以來,我們已經習於這樣的概念,「供應商相互的競爭可以提高商品的素質、降低售價,成為世界進步的動力。」然而我們生活周遭,卻有個血淋淋的反例:地圖,甚至連供應商都直言不諱

如果有個可信的公共地理圖資,相信是完全不同的光景。這就是我為什麼投入 OpenStreetMap 的原因。這或許也是促成公部門以更便捷的方式釋出公共資訊的運動。不期待這是世界大同的門戶,但願推倒公民和政府之間資訊不平衡的圍籬。

在台灣,OpenStreetMap的資料仰賴鄉民的熱血和先知高瞻遠矚制定一定的標準。目前主要城市(至少年底要選舉的五個直轄市)都頗有建樹,但仍離「實用」有些差距。除了地理圖資的供應之外,台灣社群還需要更完整的中文文件。國外有許多成功的案例,好比海地地震Crisis Commons利用這個平台整合救災相關地理圖資、每個星期的Featured images,這些都讓人鼓舞,然而完全仰賴熱血和義氣的故事,註定有段痛苦的過程,例如:行政區域的邊界便是個棘手的問題。當然技術上仍有許多挑戰,除了資料來源(鄉民主要的工具是 GPS)的準確度以外,目前似乎沒有相似於Wikipedia沙盒(sandbox)的機制可以讓新手練習又看到實際作用;若有小白來鬧場,也沒辦法直接撤銷,而是要重新畫(現在的API已克服)。這都是目前我所觀察到的難題,有待各界克服。

OpenOffice.org Impress簡報範本(4)

DSC_3183

以往,在醫院的時間,因為動線的設計,常是不見天日的。只有在忙碌告一段落,刻意走到窗邊,才能享受晴雨,或是跟著主治醫師查房時,在病房驚鴻一瞥,當然這會讓我分心的。以高醫附設醫院的新棟為例,每一層樓的公共空間中只有在兩側的走道底端有視野比較寬闊的窗臺。然而在比較低的樓層,即使視野再好,也不過發現自己身處車水馬龍的水泥叢林底層;更有甚者,部份的護理站還將這個空間規劃為輪椅的停車場,有些時候看著輪椅的剪影,我會聯想到「逃出醫院」這樣的標題 。

今年1月中旬至2月中旬,一個月左右的時間,我連續在小港醫院的兒科和婦產科實習。當初會想這樣安排自己的實習課程,是因為想在這兩科體驗醫學中心以外的醫療環境和病人生態。可是最讓我驚豔的是10樓中庭,在正對著西邊的方向有扇大窗。從這裡望出去,可以看到天空的各種表情,在地平線可以看到港區裝卸貨櫃的起重機,夜裡還有港區的燈光閃爍,偶爾在某些角度的陽光照射下,我想我看到的是海上淋漓的波光。以及夕陽!雖說「夕陽無限好,只是近黃昏」,但若時間停留在此刻,夕陽和朝日是無從分辨的。

預覽畫面
檔案下載 sunset.otp (736 KB 適用於OpenOffice.org 2.x以上 Impress,以創用CC姓名標示-非商業性 3.0台灣版授權)