期中報告回饋

謝謝其他專題生的回饋及指教，以下為對我們期中報告的各篇心得連結：

【阿達】閱讀『用於輔助認知障礙者就業之行動定位社會網路』心得
【駿】"用於輔助認知障礙者就業之行動定位社會網路" 閱讀心得
【秉霖】閱讀『用於輔助認知障礙者就業之行動定位社會網路』心得感想
【Juan】用於輔助認知障礙者就業之行動定位社會網路
【Kinmen】用於輔助認知障礙者就業之行動定位社會網路-讀後看法
【JACK】對於吳國志 張道文 期中報告之評論
【CHI】閱讀"用於輔助認知障礙者就業之行動定位社會網路"心得
【Ilikepie】閱讀"用於輔助認知障礙者就業之行動定位社會網路" 報告心得

在這裡對各位的意見做個整理，大家對我們的報告最主要的問題在於格式，如英文摘要不夠長，或是用字之類的問題；再者是對於本報告未來展望還可以更詳細、更具體。

看到大家的回應之後，發覺真的有很多細節是我們沒有注意到的，果真受益良多。經過同儕之間的互動，能夠看得更多，也希望各位老師或學長姐們，對於我們的報告給予建議。

接下來的時間將進入期末考，專題的進度也暫停，待期末考過後再接再厲！

期末考前的程式碼研究

上週六花了些許時間，將Web Service寫出來。

經過之前學長的仔細指導，以及範例指引，已經將Web Service的雛型做出來。我們使用了Subversion(SVN) 搭配Google Code 進行專案管理，並進行版本控管，我先對這部份先行解釋。

版本控管的好處是在於寫程式時，因為不斷的更新修正，一定會出現很多版本出來，利用版本控管，除了能夠可以作Code Review之外，對於在程式碼寫作時的錯誤，可以立即的回覆最近正常的版本。再者，對於多人合作的專案時，利用版本控管，能夠了解夥伴們之間的編寫狀況，並適時討論。而最重要的，除了在家編譯外，在伺服器端也製作一份做為同步，確保檔案為最新版。版本控管的功能還有很多，如可以參考MaoYang的版本控制圖解指引 。

我們選用的SVN為集中式的版本管理系統，近期比較熱門的分散式版本控管如Git或Google Code支援的Mercurial，但是因為使用需求不大，因此還是以SVN為主。

這次的程式碼（點此 ）有三項功能，一個是系統內建的Hello World，另一個是將傳送回來的值製作成xml的FindHelp，還有計算距離的range三個。FindHelp是將GPS送回來的數值儲存為stu_data.xml，再來告知range所限制的範圍後，依照此檔案來進行距離運算，並送回告知有多少位置在符合距離之內。

Server的部份大致上是完成，之後要製作的部份就是PDA上的程式以及Google Maps這兩部份。

閱讀「認知障礙者自動尋徑室內導航系統」報告心得 by 小志

　

前面提及了章節概要，讓閱讀者馬上知道接下來在各章節會得到什麼資訊，這樣的寫法很棒。

說明圖片豐富，對於環境的設計與架構的設定很清楚的表現出來，而這組也很用心的跟學校申請學校建築設計圖，讓實驗規劃上能夠更加幫助。

他們在PDA上設計前，會在電腦端製作測試程式，之後再轉植在PDA上頭。這樣的方式可以讓開發者能夠先對設計出來的程式碼進行檢測，了解系統演算的狀況是否達到正常，之後再來製作PDA的版本。

本報告是目前實驗室專題報告當中，最完備的一組，這組的程式大多完整，現階段是修正與提昇的設計，相信是我們其他組別的模範。

閱讀「具有『多點出發/走失返回/使命必達』功能的新式認知障礙者室內導航系統」報告心得 by 小志

　

這篇是我最早看過的一篇，因為當初在寫報告時曾參考過，所以先謝謝兩位。

整個實驗的架構不難，就是在區域架設藍牙節點，藉由手機讀取各節點了解所在位置，所以整個實驗部份應該著重在程式部份。而這部份也是比較麻煩的，演算法的設計就是很大的重心。文中提及是接收到藍牙資料後撥對應影片，但是如果遇到了方向性的問題時，我想這樣多少會造成一些困難，或許可以找找有沒有辦法計算出使用者與藍牙的距離，藉由距離移動的狀況應該可以分析出使用者的方向移動狀態。

影片部份，我突然有想到，若是支援播放GIF動畫檔案，因為GIF動畫檔案應該會比影片小吧！再配合提示音效，所以你只需要製作一組音效，音效設計方式可以參考PAPAGO等導航軟體的設計方法，或許這樣設計會變得比較簡單。

另外傳來的報告檔案，追蹤編修紀錄都還在，或許在完稿時要把他核對掉會比較恰當。

這篇報告的標題改過幾次，最後一次的修正我還蠻震驚的，使命必達這四個字放進來，感覺壓力就好大，不過相信這會讓你們能夠將這個專題做到最好的一個動力吧！大家一起加油！

閱讀「應用RFID實現精障者工作辨識」報告心得 by 小志

　

對報告中所提及的三種演算法感覺很棒，除了類神經比較常聽到之外，其他兩種的演算方式就比較陌生，讓我學到更多的演算方式，一直以來都有想要修演算法課程，不過因為學分不夠及時間都卡到沒辦法去選，但是有機會真的很想學學更多的演算法。

而Tag與Reader的角度差異，在本篇中做了詳細的測試紀錄，不過對於裡面的羅馬數字應該是測試次數吧！因為沒有標記出來，一開使我還以為是不同規格的Tag，若可以在表格左上方加入斜線並填上註解會更好。我也建議可以測試不同材質的障礙物下是否可以使用，如紙張、金屬、玻璃之類的，因為在真正的工作環境下，可能會遇到不同的障礙狀態，所以多這一部份資料相信會幫助你們在規劃實驗時，需要避免的狀況。

報告中所提及的實驗運作方式，我覺得還有很大的改善空間，我稍微仔細看過實驗架構，PDA與RFID Reader純粹是作為偵測使用，所以在PDA上並沒有回饋機制，感覺就像是一個超大型的偵測設備綁在使用者身上，感覺有點大材小用。如果只是為了偵測，曾有看過具備無線藍牙功能的RFID讀取晶片，這樣在使用者身上就不必有更多的負擔，可以查查相關的資料。

對於類似的方法，是有看過有人是將偵測器放在物品端，藉由有動過物品來做偵測，當然這樣的方式跟RFID的相關性就小了一些，但是也是達到相當的成效，所以可以再思考看看，以目前現有的設備能夠做到那些較符合一般人所能接受的使用方式。

閱讀「以ZigBee實現發展遲緩兒童如廁訓練應用」報告心得 by 小志

　

當ZigBee剛進實驗室時，我就想到了曾在醫工系看過用來做與定位相關性的實驗，不過現在所訂定的題目也讓我覺得蠻特別的。

ZigBee算是很多人不熟悉的通訊協定，所以本篇報告對於不同的架設狀況做測試，這樣給閱讀者能夠清楚了解不同環境下所使用的狀況，很快的讓人了解ZigBee的功能與實際效能狀況。

藉由播放音樂的方式讓使用者能夠找到如廁的樂趣，進而培養如廁的習慣感覺很不錯，我想小朋友們會比較喜歡這樣的方式。不過會不會造成說小朋友之間，如果說聽到誰去廁所如廁聽到音樂而造成嬉鬧嘲笑的部份，這個可能要請教一下專業人員。

如果將溼度感測器裝置在小朋友身上，這樣會不會造成小朋友的不便？因為除了安裝感測端外，還有資料發送端與供電電池，這樣對小朋友是否合適可能要再考慮。

感覺RFID的設置有點多餘，用途是記錄小朋友如廁的次數或規律，這部份ZigBee就可以完成吧！因為本身ZigBee就是像是網路節點，跟藍牙的設計有點類似，所以在小朋友上只需要配戴感應器就好了。印象中感應器沒有很大，小朋友的狀態就由伺服器端來做處理就好，或許這部份可以向醫工系請益。

2009/06/03 Meeting紀錄

　
時間：2009.06.03(三)　16:00~17:00
地點：電學Lab517
參與人員：馬瑱賢學長、小志

今天還是請學長親自教學，受益良多，不過先提上次的經過吧！（上次沒有寫紀錄......）

在上次的meeting當中，學長將我在使用Google Maps API編寫上遇到的困難，一起做研討並分析解決，學長會先了解我語法的架構後，提點我有哪些可以做修正、哪些地方在未來使用後會遇到哪些問題等，這樣引導的方式讓我對程式上得學習幫助很多。

這次的meeting，我把上週發現Google推出Maps API V3的實驗版本做測試，分享給學長，這次的改版〝改很大〞，最重要的就是去掉取key的限制，可以直接做取用，而程式碼的架構也改變了，因此未來若是現階段的程式要轉移時，需要大改很多，不過目前由於是實驗版本，因此很多的功能尚未開放改寫，所以目前專題的計畫還是以Maps API V2為主要編寫的語法。

而學長這次將Web Service的部份做詳細解說，從最基礎的網頁架構開始解說，然後進一步做簡單的叫用測試，然後到資料庫的取用、遠端呼叫等，雖然學長講得很明白，步驟看起來不難，但是對於程式碼的編寫方式還需要進一步認識才會。這些細節待我幾天後自己實際測試，再做細部介紹。

專題作業，6/8/2009之前繳交

　
同儕學習一直是極為有效的學習方法，看看別人，想想自己。因此請每ㄧ位專題生都閱讀其他組同學專題報告，針對每一組報告給予評論。兩週之後 6/8/2009 提出，寫在部落格上。
　

2009/05/06 Meeting紀錄

　
時間：2009.05.06(三)　11:00~12:00
參加人員：馬瑱賢學長、Arvin、小志

這週我與阿文的主力在於訂定專題的題目，決定為老師建議之：Mobile Location-based Social Networking in Supported Employment for People with Cognitive Impairments.

對於這個題目，跟學長一開始安排我們學習的內容相似：求救系統。求救系統跟題目的主要的架構是一樣的，就是在學員按下求救按鈕時，周遭一定距離內的就輔員可以收到求救訊息。不過一開始做專題時是設定就輔員是固定的位置，但是在本題目之下，就輔員是否需要做定位的部份還要進行討論。

本週我對Google Maps上的時間控制進行了解，而阿文是認識Windows Mobile上的GPS運作模式。另外還有對X800系統的問卷調查，我們將彭學長之前對就輔員的問卷進行改良，將它轉變為對學員的問卷，因此對原始問卷上的問題，將不適之題目做刪減。

希望在訂定題目方向確立之後，能夠激發出更多可以適合本系統的用法。
　

Google Code 繁體中文版

　
其實已經推出一陣子了，只是沒有在這介紹。

大部分的導覽文字都已經有繁體中文的翻譯，若細部的文件可能尚未翻譯完成，但是這已經大大幫助了我們了解Google Code當中，到底提供了哪些服務項目。

若有興趣請自行前往 http://code.google.com/intl/zh-TW/
　

四月份專題生讀書心得作業 by 小志

　
　　時代演變，科技進步，醫療技術的發達， 人類的壽命也逐漸延長。但是在長壽的背後，有個很大的問題，那就是：老化。生物藉由水、陽光、空氣等不斷的成長，到了頂峰後開始逐漸的往下坡，步入死亡，這是因為生物機能的衰退所致。因此人類也是一樣的，年紀越大，身體上的病痛也就越來越多，在行動上需要輔助工具的比例也漸漸提升。

　　但不只是年長者，對於其他有障礙者本身也有使用輔助工具的需要，這些的輔助器材，是否有達到需求是我們探討的重點。本篇論文對於輔助技術分成幾項做討論，如普遍輔助技術、認知輔助技術、康復監測技術等。

　　對於普遍輔助技術談到了環境感測，這讓我想起之前曾經看過的論文，利用監視器畫面判斷是否有人在該場域跌到的偵測系統，這套系統可以協助若發生跌倒卻無法自行求援的人。而偵測技術還有很多，對於被偵測者的各項數值做偵測並累積評估，了解該生裡狀態，做適當的提醒。這樣的相關研發，現今蓬勃發展，因為過去大多專注在研發醫療設備，這是針對已經罹患疾病的人所作的方式，但對於健康者的保健器材較少，藉由這些偵測的研發，讓健康者能夠保持在最佳狀態。

　　而認知輔助技術，是本實驗室現研究項目，利用電腦多媒體設計，達到輔助的效果。這些設計讓使用者在生活當中能夠更具獨立性，完成工作事項。

　　輔具的設計，並不只是協助使用者而已，對於在旁照顧的人，才是真正有幫助。曾聽我一位護專同學說過，很多的護士大多都有憂鬱症，因為工作上的壓力太大，往往無法調適過來。相信不只是護士，其他如就輔員、輔具使用者的家屬等，對他們而言，有了這些科技輔具的協助，分擔了他們很多壓力，降低負擔。

　　輔助工具的設計，也不只是在外在能夠讓使用者達到協助的程度，而是要從〝心〞開始，設身處地的為使用者著想，才是真正能幫助使用者的輔助工具。
　

智能設備和環境復健科技論文心得 by Arvin

　
　　在未來可預見的高齡化社會，老年人生活起居的照顧，將會需要科技的幫忙；而也有可能與前者以相似速率在增加的身心障礙者，更是需要科技的輔助。所以，對於幫助弱勢者的科技，在未來將會成為一大發展方向。

　　在這篇論文簡介所有幫助弱勢者的方法當中，我覺得比較有趣的是以遊戲機當作復健工具的想法，例如GameCube或Wii。但曾有聽說有人過度使用Wii玩到手臂受傷的例子，這似乎朝向與預想相反的方向。

　　在當中提到的eWatch，是個可以偵測患者復健狀態的行動器具，但這是否會讓患者被標籤化？另外，關於認知輔助技術，之前就從學長的專題介紹中得知，學長是用PDA的行動裝置，利用文字、圖片、聲音與影像等媒介，來幫助身心障礙者的提升工作效率。

　　而在論文中的「Smart Home」的概念，似乎也早已在多年前就於科技雜誌上看過，利用無線技術，將住家的被觀察者的生理資料，隨時傳送到醫院，甚至是有可能處於任何位置的醫生的電腦內，讓醫生隨時都能做出診斷，以減少待診的時間。而經過多年後，不知是科技還是商業化的瓶頸，使得此概念似乎仍無法在現今普及實現。

　　任何人都有成為老年人的一天，也都有可能因為意外、疾病與壓力而成為身心障礙者，所以包含以上所提的這些復健科技，其實與每個人都息息相關。
　

2009/04/29 Meeting紀錄

　
時間：2009.04.29(三)　15:00~16:00
參加人員：馬瑱賢學長、Arvin、小志

內容：
1.交代下次作業。
2.討論問卷內容：將原適用於一般使用者的題目，設計成適用於學員的題目。（本週完成）
3.討論專題進度報告：將之前的進度整理。

作業：
1.Arvin：
寫一個能將GPS的資料傳到server的程式，並將資料存成stu_data.xml，每五秒傳一次並覆寫，每次存檔時讓ID=ID+1，藉以辨認每次資料。

2.小志：
每五秒（或十秒）讀取stu_data.xml的檔案，將經緯度座標顯示於Google Maps上。每更新一次將前後兩個位置連成線，並將第一個標記移到新的位置。另外也要設計防呆，若資料未更新或沒有xml檔案程式暫停運作並於畫面上顯示狀態。
　

2009/04 春假實驗觀察心得 by 小志

　
因為這個春假快跟學長一樣天天跑台北了，因此寫成一篇。

4/6（一）
這一天學長帶阿文跟我一起到了台北，實地帶我們走過一遍實驗的路徑，為正確以及錯誤的共兩條。阿文與我要各坐三趟車程，所以一個人最少要坐六趟車。

我們也分別詢問實驗的相關細節，但是疏忽了一項讓之後的實驗出現了重大狀況，那就是Windows Mobile的上網設定。兩趟結束後，再跟學長跟著學員一起做路徑實驗，之後阿文就先回家，而我留下來跟學長去台北市區與彭學長跟泡麵碰面，一起討論問卷的事項。

對於問卷的設計，其實有些部份真的不是很好理解，關於NASA的設計：時間匆促程度的概念實在不容易懂，而且其實填寫問卷的人都是以X800這台PDA來做回饋，所以在問問題上，有時就會遇到是要問PDA這種產品還是X800這台PDA來問。另外我自己比較喜歡的問卷形式是循序漸進的方式來問，如從拿到產品時看到外觀、開機……等，依照著使用者使用的模式來進行，這樣會比較直覺。

4/7（二）
這天是我自己要做實驗，因為一趟車來回大約需要一小時，所以六趟就需要花費六小時以上，因此跟阿文約好各一天解決六趟車。但是我太晚到台北，又遇上PDA無法連結行動網路的問題，浪費了快兩小時，之後是打電話請中華電信將設定的資料寄給我，我才順利解決。

這天的實驗完成兩趟，而第三趟出現了程式自己停止的狀況，之後回報給學長後，因晚上另有行程決定實驗暫停。

4/8（三）
今天是阿文實驗的日子，也是實驗室月會的日子。我跟阿文一起跟實驗室的學長坐車到台北，我是跟學長們去開月會，而阿文是去做實驗。我將昨日的經驗分享給阿文，並將一些遇到的狀況在往台北的路途上做些處理，如行動網路上網的問題。

到了台北之後，阿文就自行前往實驗，我就跟著學長們去開會。這是第一次參加月會，因為上個月的月會老師有說專題生自由參加，可是剛好上次有行程所以無法前去，趁此春假機會參加，想說了解月會當中的進行方式，而這次月會要跟就服員們介紹iPhone，我本意是打算上去看看學長如何介紹，後來演變的狀況非我初衷……

月會的進行，是實驗室的學長們介紹在這一個月來的進度，提出一些方法來跟老師與就服員們做討論，或是之後實驗所需要配合的地方。因此在月會報告的內容講求簡單明瞭，讓就服員們能夠清楚明白。

iPhone的介紹，是臨時張學長找我討論。報告時，可能是以前在Apple經銷商待過，所以後面的介紹我就直接接下來分享，真是對學長感到抱歉。在報告當中忽略了時間的掌握，延誤大家用餐的時間，但是看到大家對於iPhone的設計有興趣，是蠻開心的。

下午，因為時間倉促，所以沒有多餘的設備能夠做實驗，因此就跟著學長到處去實驗，之後最後一位學員需要實驗的時間太久，學長就叫我先回去了。

4/9（四）
今天是我要補做實驗的日子，由於有了之前的經驗，今天的實驗大致上都很順利，只是遇到之前相同的問題，程式會自行停止的狀況，原因還有待解決。


這個春假很充實，不過車錢也花很兇，尤其我有重複做幾次，果真如學長說是最龐大的實驗。對於程式狀況的問題，學長還在努力當中，期中考之後再跟學長一起研究。
　

對於專題目前的想法

　
　　最近有一直在思考，我跟小志的專題到底要做什麼。

　　老師說要訂出一個目標，但我們現在的專題，就只是在了解學長之前的程式（也差不多理解了）、看論文，還有幫忙學長做實驗，說真的也不太明白我們可以做什麼。說真的要做一個全新的題目這難度似乎有點太大，那從學長的研究裡找一個Block幫忙研究呢？不知道這是否可以成為專題的題目呢？

　　我跟小志目前已經漸漸趨向不同的方向，我要負責撰寫蒐集資料的C#程式部分，他要負責撰寫把這些資料顯示在Google Map上的JavaScript程式部分。這樣應該算是團隊合作吧。

　　接下來要期中考了，學長說專題的進度還可以，所以可以暫緩一陣子，但是我們到底要做什麼題目呢？目前仍是未知數，只希望這個題目可以漸漸清晰。
　

2009/04/08 實驗觀察心得 by Arvin

　
　　由於今天實驗要坐六趟來回的公車，以蒐集走失的資料，所以早上我就順便跟著要去參加月會的學長與小志，一同搭8:28的區間車前往台北。

　　記得開始要坐第一趟公車時是十點多，到之後做完整個實驗，發覺已經下午五點多了，真的滿花時間的。我一開始便先把預設是走失路線的263號公車坐完三次來回，之後再坐完正確路線的270號公車三次來回。

　　當中有出了一點小問題，第一是由於早上有下點小雨，所以發現GPS一開始連線連不太上去，果然學長說的是真的，後來隨著天氣漸漸晴朗，GPS的連線也愈來愈順了；第二，在後來坐270的第二趟去程時，抵達終點後才發現與GPRS網路的連線，在中途就已經中斷。原本通常會傳300多個筆資料的數量，結果才傳160幾筆，全部六次來回共12趟的車程，只有發生過一次這種情況，之前小志做實驗也發生過相同的狀況，不知道是什麼原因造成的。

　　坐在車上，有一直試著看看可以順便做什麼其他的事情，不然真的滿浪費時間的。不過後來發現什麼都不能做，因為車子太晃了。我發現原因來自於公車司機想要趕路，關門後就加速到最高速，然後到站又馬上急煞，造成整個車程坐起來非常不舒服，而且也十分浪費能源。

　　不知道為什麼司機們要這麼做，是因為制度上規定跑完路程的時間太短呢，還是早點跑完規定的數量就可以早點休息，所以司機們無所不用其極地加速，之前常常聽到機車族在路上最怕的，就是喜歡馬上急煞靠邊停站的公車。

　　第一次一天一下子坐了那麼多趟的公車，才發現其實公車族也很辛苦。這一切到底是什麼原因造成的，有辦法可以解決嗎？我真的不知道他們到底在趕什麼。
　

2009/04/06 實驗觀察心得 by Arvin

　
　　今早搭10:55的區間車，與學長、小志一同前往台北做實驗。

　　這是我第一次做實驗，所以一切都很陌生，我們大約在中午的時候，順利地來到仁愛醫院，此時學長就教導我們，如何使用PDA的GPS功能來蒐集經緯度，並回傳給Web Service。

　　我們今天必須搭乘兩條公車路線，一條是正常的路線：270，一條是假設走失的路線：263。其實這個實驗感覺滿簡單的，只是之後必須要來回坐好幾趟，蒐集大量的資料。

　　而我今天問了學長一個問題：如果我們的程式功能是要偵測學員的走失，那公車270與263其實一開始的路線是重複的。換言之，必須等到公車路線開始不同時，程式才能偵測到學員走失，此時已經失去即時性了。如果今天這個程式是用於行走，那的確可以馬上得知是否走失，如果用於公車，而又遇到這種重複性高的路線時，無法立即得知學員走失，就算得知了也已經走失很遠了。

　　學長回答說，那這樣就必須讓學員有個裝配有RFID的設備，在一上公車的時候就確定搭上了正確的公車。

　　這讓我想到，走失偵測與即時性似乎非常相關。以前常常在電影裡看到，警察追蹤歹徒，都必須在有限的時間內追查到位置，否則查到的時間愈晚，所必須搜索的範圍就愈大，我想走失偵測應該也是相同的道理。

　　下午，就順便跟學長去陪學員回家做實驗，而我是第一次跟學員接觸，其實感覺學員人很好相處，只是表達意見時不太順，一路上我們就跟學員與瑞華姐一邊聊天，一邊回家。坐了很久的捷運與公車，終於到了學員位於新莊市的家，學員的爸爸看到我們這們多人陪學員回來，就很開心地招呼我們進去坐，不過因為時間太晚，所以我們就婉拒了他的盛情了。

　　今天做了一整天的實驗，之後還要自己一個去台北坐車蒐集資料，不過總算有感覺自己有參與到程式的功能了，還滿有成就感的。
　

Google神秘伺服器大公開

　
Google日前公開他們的伺服器設計，除了強調該設計省錢外，也省資源。

他們自行設計將電池直接安裝在主機上，而不是使用現今流行的UPS（不斷電供電系統），這樣技術有申請專利，Google也樂於分享此技術給大家。詳情請參閱下列文章以及YouTube影片。

ZDNet新聞專區：Google神秘伺服器大公開
YouTube：Google Servers

　

上週進度回報

　
由於週三（4/1）本預定的meeting由於一些狀況沒有進行，所以這此補記上週該有的進度資訊。

上上週的meeting 共有兩份作業，第一個作業為讀取一筆學生、四筆其他位置的xml資訊，然後利用程式判別在學生周圍指定半徑範圍內（0.02），其他位置有多少點在其中。

阿文與我分別做出來，但是利用不同的方式來製作。阿文是使用XmlReader的方式來製作，而我是用XmlNode的方式。這兩種方式的差異是XmlReader在執行時，是對xml資料一行行讀取，而XmlNode為搜尋指定標籤。這兩種方式皆是讀取xml的用法，但實際上的運作差異性還需要深入了解才會清楚，如哪種方式比較耗費系統資源之類的。

我的寫法程式碼以及運作結果顯示

第二份作業將以上五份的xml資料顯示於 Google地圖 之上。由於網路上大部分的範例都是讀取標籤內的子項目，如：

<marker lat="24.956070995486776" lng="121.24248594045639"/>

但是學長交付的xml資料是將經緯度分成兩個標籤，如 ：

<longitude>121.240793466568longitude>
<latitude>24.958020047888855latitude>

所以遇到了蠻大的瓶頸，因為找不到適合的範例學習。但經過朋友的協助，以及學長的提點，找到正確的方式做讀取。學長另外說明在編寫JavaScript時，由於程式本身不會自己進行debug，所以自己要藉由加入alert()的寫法來手動debug。這份作業，我另外設計每個標記可以點擊，並顯示出該點的資訊。成果請點此瀏覽 。

以上為上週的進度回報。下週放春假，將進行另外一項實踐，詳情之後補上。
　

困境

　
最近因為家裡的某些因素，所以家裡網路被停了。

以後要面對眾多需要網路的專題功課，要怎麼適應與解決還是個問題，不過窮則變，變則通，我相信一定會有辦法的，以後只好多跑學校跟實驗室囉。
　

Code Review 代碼檢查

　
前兩週上Java時，老師向我們說明Code Review的作用，而在上週時，實際的帶我們進行Code Review。

在Code Review當中，老師要我們仔細觀察同學寫的程式碼，並提出看法，有哪些細節覺得有問題，還是說有更好的寫法，最後老師再提出老師的觀點及提出建議。

對我來說，是我第一次進行Code Review，讓我有深刻的體驗。在這次進行當中，老師提出在業界工作多年的經驗分享，學到很多東西。如老師非常要求程式的效能，哪些步驟可以精簡並完成該任務。這個細節對我來說是非常不會注意到，因為現在的記憶體都非常大，電腦的效能運作也很快，所以目前在寫的小程式其實運作上差異性在目視下不會很明顯，沒有像老師在當年如此錙銖必較的經歷。但是這樣的小細節，在未來是提升自己競爭力的重要關鍵之一，因為到了一個大型的程式架構下，這樣的方式可能會拖累到整體程式運作的速度。

這學期開始做專題，也開始寫程式，經過幾次的meeting，目前都是完成進度後，經過學長的檢查，這樣就很像是在做Code Review，因此我開始在網路上搜尋關於Code Review的資料。在搜尋的過程當中，發現 Google Code 有提供這樣的功能，所以想當然耳就來研究一番。 Google Code 可以幫使用者儲存每一次的編輯資料，並做比對，這跟 Google文件 很像會記錄每一次的修改，但是在 Google Code 當中更支援了 版本控制 的功能，這又是另外一件事情了。

這學期專題規定要跟同學合作，所以我並不是一個人在完成專題作業。但自己有發覺與專題夥伴間目前都是獨立運作，各寫各的，這樣的問題，之前有詢問過學長，學長是指說我們分派寫的東西不同，但是在共用的東西如全域變數或輸入輸出要用一樣的變數。這跟我剛剛也向以前的同學請教，他跟學長說的差不多。我同學說格式很重要，像是全域變數都要事先商量好來，若要輸出某些資料的話，同樣格式輸出的function也最好使用同一個。這些只要是共用的部份都需要事先討論。

而利用 Google Code ，配合版本控制如 subversion ，依照這樣的模式就可以讓電腦將版本資訊上傳，並在 Google Code 上頭做Code Review。自己已經開始在嘗試做做看，目前感覺還不錯，但是在 Google Code 當中，遇到了Code license代碼授權的問題。因為將程式碼上傳到網路上，你要決定讓你的資料使用哪一種類的授權，而各種不同的授權有不同的條款規定。這部份我比較不清楚之間的差異性，但是這事情攸關權益問題，最近會開始多認識一下各種不同的授權方式。
　

2009/03/25 Meeting紀錄

　
時間：2009.03.18(三)　10:10~12:00
參加人員：馬瑱賢學長、Arvin、小志

內容：
今天檢視上週的程式碼，並研究其中的一些問題。
1.對於讀取xml並顯示的程式無法顯示第一個標籤的狀況尚待解決。
2.而寫入xml的程式將之改成副程式的運作方式，提高應用能力。

新進度：
這次分為兩份作業

作業一
學長交付給我們五筆xml資料，一筆為學員資料，其他四筆為老師或就輔員。將以上資料讀入程式，判斷學員的指定範圍內有多少老師或就輔員，顯示出人數。

作業二
將作業一學員、老師或就輔員之資料顯示在 Google地圖 上。（利用Google Mpas API）

Google Maps API參考資料
1.http://code.google.com/intl/zh-TW/apis/maps/documentation/services.html#XML_Requests
2.http://code.google.com/intl/zh-TW/apis/maps/documentation/overlays.html#Markers
　

2009/03/24 下午程式碼研究

　
本次主要研究xml檔案的讀寫處理方式，一開始我是用網站的模式來編寫，後來詢問過學長知道直接用C#跑Windows主控台應用程式即可。之後花了一些時間將程式碼移植過去，並將本週的作業融合在一起。

我是直接將MSDN的範例轉移上來，對於學長要求的各個參數對應輸入。這是我第一次寫C#，最基本的輸入輸出方式也在這一次學會。

有遇到Console.ReadLine()跟Console.Read()這兩種輸入在同時使用時會出現不正常的狀況，經過跟學長討論之後，全面改用Console.ReadLine()才可以正確執行。另外在寫入xml檔案時，要將各個參數轉換為字串才可以寫入。還有在程式執行畫面結束後會自動關閉的狀況（偵錯並啟動），可以在程式碼最後加入Console.Read()或是Console.ReadLine()讓程式結束前停止運作。

另外也注意到本程式在寫入xml時，會覆蓋掉前一個資料事後問學長才了解這是正常的。學長說明會將每一筆的資料存成單獨的檔案，萬一要作成類似歷史記錄的要另外編寫程式。

這次寫入xml檔案的方式是直接輸入並寫入檔案，若要做多筆檔案輸入尚未研究。

寫入檔案的程式部份有學長、阿文及我共同完成，讀取xml並輸出由阿文獨立完成。

本截圖為將寫入輸出程式碼結合，有部份程式碼、程式執行畫面以及輸出之xml檔案。

　

撰寫第一次作業心得

　
　　今天運動會，下午跑去實驗室跟小志研究一下共同作業，發現跟以前自己摸索程式時的感覺不太相同，感覺很順利，兩人互相補足不足的地方，這種合作的感覺很不錯。

　　後來，終於研究出來了，另外我自己的作業部分也寫出來了，只是還是對Ｃ＃不太熟悉，光是一開始建檔的步驟就花了我不少時間，希望可以愈來愈順手。
　

如何設計精障實驗紀錄表格與問卷內容

　
進入精障實驗場域時，常常會有些混亂，甚至偶爾場面會失去控制，因此如何完成一個實驗，必須做中學，臨機應變，這也是我們在別的地方學不到的。

經驗告訴我們，我們要事先做最好的準備，以及最壞的打算。這些準備包括實驗表格設計，因為使用表格可以協助我們完成標準操作程序(SOP)的要求，遠離混亂，並且確保不會遺漏重要數據的紀錄，因為補做數據成本經常很高，甚至不可能，例如學員事後已離職。

另外對於需要現場詢問學員的問題，應該事先想好，以便臨場對話時不會漏問了重要問題。

以下範本^*，大家可以打開參考。


^*本文轉貼於老師寄信至實驗室網上論壇之文章，範本請參閱信件或實驗室論壇之附件。
　

如何做好精障實驗標準程序

　
精障者實驗必須嚴格控制變因，無論哪一天去做，由哪些同學去做，實驗條件應該一致。話是這麼說，做到很不容易。

麥當勞已經告訴我們，在工讀生進進出出廚房，每天人去人來的場域，要維持穩定的工作品質，唯有依賴標準操作程序，簡稱標準程序(SOP, Standards of Operation)。

萬志的精障者工作提示實驗的SOP寫得很不錯，大家不妨打開觀摩一下^*。


^*本文轉貼於老師寄信至實驗室網上論壇之文章，相關資料請參閱信件或實驗室論壇之附件。
　

如何做好一個精障學員實驗記錄

　
目前實驗室有四組實驗在進行，大家忙得不亦樂乎，不過，人類是遺忘的動物，別忘了實驗紀錄，因為以後必須依靠這些實驗紀錄回想當時。

既然要記錄，就把它做好。一個好的實驗紀錄應該

1. 文字越詳細越好

2. 特別注意有什麼關鍵時刻，關鍵話語，關鍵事件，發生錯誤。

萬志的實驗紀錄做得很好，我建議大家打開附件^*。你們可以看到有些學員發生操作錯誤時，這些錯誤的原因都被詳細紀錄了(用紅筆標示)，這對每次改進輔具有很大的幫助，大家可以跟萬志學習一下。


^*本文轉貼於老師寄信至實驗室網上論壇之文章，附件請參閱信件或實驗室論壇。
　

2009/03/21 下午程式碼研究

　
昨天將之前學長所交付的程式碼給細讀，順便寫上自己的註解。在編寫的過程當中，遇到任何的問題時，自己會另外註明在上頭，以便於下次整理程式時，能夠更加了解所遇到的困難點。以下列出這次研究的一些心得。

這次的程式碼包含兩種的語法：網頁使用的ASP.NET與C#。這兩種語法在編寫上頭自己覺得最大的差異性在於註解的編寫方式。在ASP.NET上頭註解的寫法為＜！﹣﹣註解文字﹣﹣＞（刻意用全形來輸入，不然用正確的寫法就會被當成註解了......），而在C#上為 //註解文字 或是 /*註解文字*/ 。也注意到C#字串語法處理時，若要對應回網頁上，可以在字串上頭直接寫html的語法，在網頁上也能夠執行。



這次的程式碼內包含了Skype的API，但是尚未使用到，而且在編譯時會造成錯誤（因為找不到API的資料，學長沒有給），學長說可以先將該呼叫程式碼註解起來，這部份等主要的程式碼透徹後再來研究。之後遇到的是驗證的相關資料，或是存取一些檔案時無法執行，學長也是說可以先略過驗證直接執行主程式。


另外發現自己對於處理xml檔案不熟悉，這幾天希望能夠找資料研究透徹，完成本週的程式進度。

專題生注意事項

　
　　專題生應有明確的目標，專題生要很清楚期末必須做出什麼，每個月也應該要有小目標。如果無法達成，應該提前說明原因。需要什麼協助，應主動提出。

　　專題部落格建議每週撰寫，做些什麼，讀些什麼，遭遇什麼困難，如何發現解決之道，生活小品都可以。
　

[新聞]微軟、微星與台師大共推電腦無障礙計劃

新聞連結 http://www.ithome.com.tw/itadm/article.php?c=54035

昨天剛好在新聞文章當中看到的，這篇文章對於身心障礙的朋友們，在使用電腦時可能會遇到的問題做了一些解決方案。

這些解決方案並不是設計者空談，是利用一些工具來模擬、體驗身心障礙者的狀況，來作設計與改善，如：筆記型電腦無卡榫開闔設計方便使用、螢幕顯示放大輔助視覺障礙者等狀況，做解決方案。詳細的內容請點擊上方連結。

看到此篇自己的感覺是，唯有設身處地的為服務對象設計，才能真正設計出真正有幫助的東西。

2009/03/18 Meeting紀錄

　
時間：2009.03.18(三)　10:10~12:00
參加人員：馬瑱賢學長、Arvin、小志

內容：
一、講解程式
二、學長交代程式作業
１、共同作業：寫出一個可將輸入參數存成.xml檔的程式。
２、Arvin：寫出一個可讀取上面資料的程式，顯示在console介面上。

補充：
寫一個function，可代入13個參數

1.字串形態-fileID
2.整數-ID
3.double-經度longitude
4.double-緯度latitude
5.字串-時間Date
6.字串-使用者名稱UserName
7.double-hdop(水平向量精準度)
8.double-速度speed
9.整數-sc()
10.double-sa()
11.double-vdob
12.整數-sivc
13.double-pvod

寫出xml檔案

四月份專題生讀書心得作業(2009.4.30截止)

A perspective on intelligent devices and environments in medical rehabilitation☆
Medical Engineering & Physics, Volume 30, Issue 10, Pages 1387-1398
R. Cooper, B. Dicianno, B. Brewer, E. LoPresti, D. Ding, R. Simpson, G. Grindle, H. Wang


文件請參閱實驗室網上論壇信件附加檔

小志的專題生讀書作業（三月份）

這篇論文應用的方式與上一篇心得類似，使用Web 2.0的模式來應用。對於這次的文章，我比較注意的地方是"系統效能壓力測試"這部份。

以前在設計網頁時，往往都沒有注意到這部份，會將功能或特效一直加入網頁上，卻忽略了這樣的方式。

對於不同的使用者來說，可能在閱讀上或是下載時會遇到一些困難。 如一堆的Java程式可能造成使用者瀏覽網頁時容易變慢或當掉；使用Flash需要另外安裝外掛程式才可以執行；網站一堆大型圖檔沒有經過優化，造成下載過慢等等問題。

這些都可能造成使用者端的電腦覆載過大，或是伺服器無法及時運作，浪費資源的做法。所以對於Web 2.0如我上次我提起，各項服務都如同方塊，經過組合後成為強大的功能群組。這樣將各項資源分散，降低設計者的設計門檻，避免單一伺服器運作過載等狀況，這些相信有助於分散系統的壓力。

專題生三月份論文心得

　
　　這次論文的研究方法，感覺跟上次閱讀的論文如出一轍，都是用「行動研究」(Action Researsch)的方式，利用Web2.0的技術，為非營利的組織去量身打造一個適合的系統。

　　比較特別的是，這套系統會考量到各個租屋者的需求與喜好，分別去提供適合的地點供其選擇，這點比起必須在資料庫裡努力尋找的傳統方式好多了，只是不曉得這套系統的人性程度，究竟會聰明到什麼程度。

　　似乎已經可以找到一套模式，去為這些類似的需求設計一套解決的辦法，我想這也是科學研究的重點之一：模組化。在以後，或許可以愈來愈降低設計系統所需的成本。
　

2009/03/12 Meeting紀錄

　
　　今日，學長除了瞭解與教導我們的程式進度以外， 另外也告知了我們的下一個任務。

　　簡單說，就是要設計一個方法， 讓GPS在PDA地圖上的顯示，與真實位置的誤差降低， 這利用到之前寒假集訓時所介紹的方塊法， 觀察GPS與真實位置在地圖上的點， 這兩者所形成的兩個方塊的相似度， 但是，必須盡量消除誤差。

　　老師與學長想出的辦法是， 轉換座標軸的角度， 讓兩塊方塊盡量相似， 而我們的任務就是要去設計轉換座標軸角度的程式。

　　其實，對於這整個的功能還不是了解地很透徹， 目前就先看懂學長給我們的程式的功能吧！ 以及要加上還欠缺的部份。 　
　

2009/02/25 meeting記錄

學長在日前已經將求救系統的部份程式碼給了我們，
希望我們能夠補齊不足的地方。

程式的運作架構為按下系統上的求救按鈕，
程式會將GPS訊號以行動網路的方式送至伺服器，
伺服器端分析運算後判斷出周遭較近的有多少位就服員，
再將其資料輸出成xml格式。

2009/03/04 實驗觀察心得

這是我第一次去台北做實驗，其實還蠻緊張的，因為覺得自己不善於做記錄，擔心蒐集的資料不足作為參考。下午坐火車轉捷運再步行到達了仁愛醫院後，就等待著今天的配合實驗的學員下課。

等待下課的時間，就問了學長學員的狀況，以及本次實驗注意的事項。之後就與今天一同實驗的學員碰面，還有瑞華學姐（因為她叫我學弟，所以我在此先這樣稱呼她）一起做實驗。

到了醫院外頭，學長教了學員操作模式，之後將PDA裝入一個透明防水袋掛在學員的脖子上（發現我忘記拍了下來）。其實我不是很喜歡那個東西，因為看起來太像某個監控設備的樣子，但是學長說明因為訊號的問題，所以這樣放置會比較恰當，但是希望之後能找到個像是手機袋的會比較“自然“。

之後我們就走到醫院對面去等公車回學員的家。台北市的公車真的很複雜，一不小心就可能坐錯車，所以對於精障朋友們，回家可能就會有問題，因此才會有這樣的實驗。等公車同時，問了學員之前沒有回家的狀況，他是說坐錯車跑太遠，隔天才回到家。不久車到後我們就上了車。其實從剛見到他到現在，都覺得他非常有禮貌，在公車上會主動讓座。

這時接近黃昏，路上的車潮有漸多的趨勢，學員在他常下車的地點下了車，這是他母親工作的場所附近，但是今天剛好沒有上班。回家的路上一直在鑽小路，學員他很清楚自己該怎麼走，我們其他人早已昏頭轉向，一段時間後就到了他的家，並於他們家小坐一下。

今天的實驗，我覺得學員只要是上對了回家的公車，那接下來應該沒有任何的問題，所以我覺得該學員的狀況應是上錯車到陌生環境時無法應對，才會發生走失的狀況。這次我也用自己手機來測試GPS，發覺在公車上有幾度GPS斷訊，這部份可能是要注意的地方。

小志的精神康復之會所模式研討會心得

這是我第一次參加正式的研討會，所以在出發前問了一些學長該注意哪些事項。到了之後看到會場時，第一個反應就是“餐會“，當下就覺得這次研討會應該是比較輕鬆的方式進行。

這次主軸是“會所模式“對於精障患者所帶來的幫助及影響。上午由兩個台灣團體已經推行此模式的“慈芳關懷中心“及“伊甸活泉之家“來作介紹，介紹他們引進會所模式之後，於台灣社會所推動的方式。下午由澳洲踏腳石Clubhouse的三名代表做介紹，及戲劇演出與綜合座談。

會所模式著重在於群體的運作，參與會所的精障朋友不稱為病人、學員，皆稱為會員，這樣的方式可以消弭標籤化的問題。而在會所當中大大小小的工作，都皆由工作人員及會員共同開會決議，所以澳洲來的代表也有工作人員及會員。但是這樣的方式的確會遇到一些問題，有些事情是要決議幫助會員的，但是會員在場要如何做討論，這部份雖說有提到，但是沒有說明如何處理。

會所模式所要帶給會員的就是增加自我認同，擁有了認同、自信心，可以幫助會員重回正常的生活，重回職場，擁有一份工作是很重要的，因為就現實層面來說，沒有辦法賺錢就無法養活自己，我相信這樣的方式一般人也是會有需要的。

這次參加發覺自己還有很多不足，如精障有哪些的類別、症狀，或是有狀況時要如何協助等，這部份對於在場的大多數人都是身歷其境的，所以不需要在本次研討會當中說明，也非本次議題主軸，這要靠自己花時間去了解。未來要設計幫助他們的相關輔具時，是需要多認識的。



相關連結
伊甸活泉之家
慈芳關懷中心
Stepping Stone Clubhouse

精神康復之會所模式研討會心得

　
　　這次的社區精神康復之會所模式實務交流研討會，是我第一次參與這種類似的活動。在去之前，原以為會有點枯燥乏味，沒想到今日參與後，深深覺得活動辦得真的很棒，與我想像中的研討會相差甚遠，比起來還比較像是營隊的感覺。既充滿歡樂的氣氛，也得到不少的專業知識，更開闊了對於精障者處境的視野。

　　早上一開始，就由伊甸活泉之家與慈芳關懷中心的會員與工作人員，共同表演了兩齣舞蹈，為還未熱絡的現場帶來歡樂的氣氛。雖然有些會員舞蹈動作不是很完整，但是可以感受他們想要完成表演的用心，覺得他們真的是很可愛。

　　接下來就輪到久仰大名的王增勇老師的演講。老師緩緩道出從前求學的歷程，也毫不諱言勇敢地，在全場幾乎都是精障相關工作者的地方，說出自己從討厭，到開始接納精障者這其中心態的轉變，讓我覺得非常敬佩。

　　在之後的慈芳、伊甸活泉與外國的墊腳石會所團體，感覺其實都是走著相同的模式－把精障者視為同仁／會員。先求能夠取得他們的信任，再建立他們的自信心，接著再慢慢讓會員們循序漸進地進入職場，早日融入社會。在他們的自我介紹中，都能感受到他們的用心。不論是工作人員還是會員，每個人的生命故事都歷歷在目，十分令人動容。

　　其中從澳洲來的三位外籍人士，非常熱心地分享自我的經驗，也很耐心地回答現場聽眾的問題。雖然有些人的問題充滿了攻擊性或尷尬性，但他們還是充滿風度，並幽默地回答。讓我覺得在專業知識之外，例如情緒處理的能力，他們也有我們值得學習的地方。

　　當然不可不提的，就是話劇的表演了。老實說我一邊看，一邊笑得很開心，可能有股反差的無厘頭感，讓我忍俊不住。但是看完後我深深覺得，用話劇的方式來表現精障者的心境，比起用文字、圖片解說，還真是一目暸然！尤其是當「阿好」穿上一件件充滿標籤的「外衣」的這個表演，那真是非常好的比喻，馬上讓外人對於精障者感同身受。我不得不頒給「阿好」今日MVP的獎座了。

　　讚美操的時間也很有趣，看著伊甸活泉的老太太很「努力」地跳著舞，老實說我又不禮貌地笑出來了，也許這是他們故意設計的「笑果」？看著會員們努力地跳著排練許久的舞蹈，心裡也漸漸從玩樂轉變成崇敬的心態，誰能想像在不久之前，他們還是為世人所排斥的群體呢？只要努力，他們也有做得到的事情。

　　會所模式，的確是提供了不同於傳統精障醫療模式的另一條路，而看來成效還十分不錯。雖然台灣政府對於精障輔助團體的補助，無法像澳洲政府一樣那麼豐富，但千里之行始於足下，儘管未能盡善盡美，但總是要有個起頭，才能期待接下去未來的發展。

　　今天一大早坐上火車，浩浩蕩蕩地前往到台北，參加這個活動直到下午五點，一路回想，覺得還滿值得的。理想與現實的老戰爭一樣在上演著，而在今天，我看到了「雖千萬人，吾往矣」的熱情，讓我心頭直到現在仍震撼不已。
　

專題生讀書作業（三月份）

專題生請於(3/15)以前，完成閱讀以下論文，並且於個人部落格撰寫心得。列入專題平時成績。
http://groups.google.com/group/lab-517/browse_thread/thread/5dffe3dac5038a5e?hl=zh-TW
　

小志的寒假作業：論文閱讀心得

　
現今Web 2.0的許多服務大多都可以模組化，各項性質的服務皆可以互相搭配。如堆疊積木般，每項服務可視為積木，而不同的群體有不同的需求，依所需堆疊出屬於各團體最適合之架構。

本論文以非營利組織使用Web 2.0來作探討，非營利組織最常面對的問題就是經費，使用Web 2.0的成本較為低廉，又可以達到輔助的效果，是可以好好研究的園地。但很多工程師在設計工作模式時，都是以功能取向，其實預設更多的功能，不見得每位使用者都適用或接受。

在設計當中，有時會忽略掉真正需求，以及附加功能的差異性。所以在思考時，不可一味的把功能加上去。論文當中，很清楚的告訴我們應該實地的去參與，了解使用者的族群類別、需求等，並共同研究討論之後再做規劃。

專題生寒假作業－JAE論文閱讀心得

　
　　弱勢者在社會中，總是屬於被遺忘的一群，既得利益者很少會關注到這些問題，又因為在民主社會中多數的意見才是主流，而那些少數的聲音，似乎設立一些專門的措施來保護，就可以讓政府避免道德上的非議。問題是，這些保護措施真的有發揮功能，還是這只是政府用來敷衍的手段？

　　從這篇論文可以觀察到，政府許多對於精障者的幫助，事實上並沒有那麼設身處地地為他們著想。天高皇帝遠，好像歷史總是如此，只要編了預算，做了計畫，這些就成為所謂的政績，但真正的幫助，並不能只是如此膚淺地執行。

　　看到這篇論文裡對於實驗者許多精細與分門別類的研究，才發覺原來人類才是最難研究的對象。人不是死物，人是活的，每個人都有不同的反應，尤其是要用於精障者的研究，更是馬虎不得。

　　Web2.0的好處之一，就是可以用極小的花費，來達成極大的效果。平常就在接觸Web2.0裡的眾多服務如Blog、相簿、論壇的我，深知在網路使用上的成本愈來愈低時，發表上的內容廣度與深度也就會愈來愈大，因為再也不需要花費多餘的心力去撰寫、維護網路上的功能。而這點對於精障者的服務似乎也是助力。

　　自從接觸了Google後，發覺這家網路公司所提供的服務相當地有潛力，尤其是最為被推崇的整合功能。雖然在Blog方面，在使用介面上還未像他家業者般親切，而從建立到適合使用後，所花費的時間成本也較他家業者高，而這些都有待Google去改進。

　　科技與人文的交野，似乎不是那麼涇渭分明。「科技始終來自於人性」，我想我們永遠都不能忘記，科技的最終目的是要用來改善全人類的生活的，而在社會上的弱勢者，更是需要科技去幫助他們，也許在未來，可以找出一條在商業與公義上平衡的路，讓人們幫助弱勢者不用只靠那可遇不可求的良心。

專題生寒假作業

於開學後一週(2/23)以前，完成閱讀以下論文，並且於個人部落格撰寫心得。列入專題平時成績。
http://groups.google.com/group/lab-517/browse_thread/thread/a0412c79a43f2d33?hl=zh-TW#
　

Google 2008 台北程式開發日簡報

2008年Google在台北開程式開發日的活動
為了是讓大家更能夠了解Google提供了哪些技術給開發者應用
擴展網頁上的應用技術
而關於Maps的部份有兩場簡報

Maps API - 羅永杰

Maps API Case Study - 鄭依桓、郭家齊、廖泫銘

網站內均含簡報檔案跟現場錄影
對於了解Maps運作的模式
以及應用方法有深刻的了解
若對於其他場次的簡報有興趣
可在該網頁下找尋其他的簡報資料

專題成績計算方式

meeting 出席率: 20%
報告成績: 30%
平時成績: 50% (部落格每月至少兩篇，口頭呈現，半成品，程式，其他)

Google's AJAX APIs Playground

http://code.google.com/apis/ajax/playground/

圖片來源：Google Code Blog

這是在Google Code上找到的一個網頁
裡頭已經搭載了170個Google's AJAX APIs範例
可以直接在上頭編輯
是一個非常好的服務
讓大家能夠藉由各式的Google範例來練習
推薦給大家

熱身習題

這是老師交代的第一個習題
http://140.135.8.176/WayDetect/map.html
點出bubble以後，可否直接從一個bubble 上傳圖片