ComicSurfer 1.3
(圖片版權歸原公司、作者所有)

  老實說,1.4版不在我原始的規劃中,單純是自己看漫畫時,總覺得少了一點UI上的輔助,不太方便,所以做點微幅的修改,說微幅其實也不小,修改了一些bugs外(偏好設定的檔案裡有錯字),也新增跳回,這在要按下一頁卻按成下一集時,特別好用,只要按Ctrl + Z就跳回到前一頁,另外多了一個最近開啟清單,可以直接從清單開啟漫畫且切到上次看的那一頁,最後1.4版也瘦身了,檔案大小只剩下70%左右,過去的版本依賴JDOM完成偏好設定和多國語言的儲存及讀取,但1.4版改成使用J2SE內建的SAX讀取XML檔案,搭配自己寫的XML輸出程式,好處是可以移除JDOM的函示庫、SAX速度比JDOM快且也比較省記憶體,不過為了優雅地使用SAX,不想寫一堆難以維護的if...else if...else,也花了點時間弄了一棵parsing tree的架構,還好這東西之後可以重複利用。

  由於沒時間,自動更新(Auto Update)和預覽選擇面板(File Chooser with Preview)的功能就延到下次1.5版再加入。至於1.5版什麼時候會出呢?只有上天才會知道了。正式版本編號是1.4 Build 20120413 (要怎麼看到版本編號?請用console模式下指令...反正不重要啦!記得更新就對了),又移除了2個跟跳回有關的小bugs,所以還是請大家更新一下囉。

  Comic Surfer 2011下載網址:最新1.4版 (277 kB on Apr. 13, 2012) | 簡易使用手冊PDF版

  舊版連結:
  Comic Surfer 2011 1.3版 (402 kB on Dec. 19, 2011)
  Comic Surfer 2011 1.2版 (327 kB on Oct. 26, 2011)
  Comic Surfer 2011 1.1版 (179 kB on Oct. 25, 2011)
  Comic Surfer 2011 1.0版 (210 kB on Oct. 19, 2011)

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  前言

  這幾天的Facebook湧入大量關於都更的新聞,不過,我不是當事人,即便看了這麼多網路上的文章,大多只有其中一方的說法,無法了解整個個案的來龍去脈,所以接下來的內容不討論爭議的個案,這是因為觀察最近幾個熱門的爭議話題,除了夾帶大量的言語攻擊,也很容易陷入非支持甲方就是支持乙方的二分法,很難更深入的討論。除了不討論個案外,也不碰觸各別都更條例的解讀,說真的,我不是念法律的也不是念都市計畫的,都更條例62條加上實行細則39條,落落長,又是一堆法律文字,我也懶得去搞懂,我想很多網民也不見得願意花時間去搞懂條例,畢竟按『讚』或是讀『懶人包』簡單多了。以下僅是個人對都市更新的看法:

  一、關於都市更新

  之所以要都市更新,主要是城市在發展之初,沒有規畫規畫不善或是早期的規畫已經不符合現今社會所需,為了讓城市能夠繼續成長,因此會對部分區域進行重整,這和開發軟體類似,需求不斷地變化,原先設計的架構無法滿足需求時,會透過重構(Refactoring)的方式進行架構調整,但和軟體的重構相比,在版本控管和大量自動化測試的保護之下,大不了回到之前的版本重新來過,損失的是時程上的延誤。但都市更新牽扯到許多人的權利,而且房子一旦拆了,除非用多啦A夢的放大燈時光布變大,蓋在拆除的瓦礫上,否則已經無法挽回。即便可以透過交換或是補償的方式,盡可能維持既有權利人的利益,但有句話:『金屋銀屋,還不如自己住的狗窩』,也衍生出許多不願意參與都更的例子。

  為了讓都市更新得以進行,都更條例從民國87年頒訂後,到99年修正了8次,其中最有爭議的是以多數決的方式,決定不參與都更住戶的權利,也因為如此,有不少人認為都更條例本身違憲(第10、15條),土地徵收和都市更新侵害人民之權利,『侵害人民之權利』是肯定的,不過這也是憲法有趣的地方,因為政治是『管理眾人之事』,權利必然會出現衝突(版權 vs. 盜版、薪資的勞方 vs. 資方、住家安寧 vs. 商家生意等等),既然權利衝突無法避免,該如何保障『所有』人民之權利呢?實務上很難,所以憲法在人民之權利與義務一章的結尾,給公權力一個介入人民權利衝突的一扇後門(第23條),而公權力的產生確實是多數決。但都更和土徵最大的差異,都更的發起者和執行者往往不是代表公權力的一方,這也是最讓我感到奇怪的地方。

  二、從消失的綠地談起

  暫時離開一下主題,聊一下我之前去澳洲的經驗,因為沒有台北直達Hobart的班機,所以我選擇在西澳第一大城Perth轉機,順便停留玩了幾天,當時飛機抵達Perth已經很晚,加上請旅行社代辦的電子簽證出了點問題,到入住的背包客棧已經累翻了,洗完澡馬上就睡了。隔天早上七點多醒來,光是找買早餐的店,就走了十幾、二十分鐘,那時覺得怎麼這麼不方便啊!在台北沒走個幾步就有24小時的便利商店,就在一邊吃著『1澳元但不怎麼好吃的』包子,一邊看著先前印出來的地圖四處亂晃,不知道是肚子不餓了還是沒走幾步路就有綠地,心情就好很多,甚至走累了,就學當地人直接躺在草地上睡了半小時。在Perth的五天,最讓我印象深刻的是King's Park,那個公園非常的大,大到讓我待了整整一天,它到底有多大呢?我特地在Google Map把Perth和大台北,用同等比例(見左下方比例尺)截圖(圖1圖2),分別用大頭針標示出King's Park和大安森林公園,我想這差距很明顯不用我再多說明,如果再比較圖1圖2,即使在這樣的比例尺之下,感覺圖1的綠色區塊似乎特別多。當時覺得Perth這地方實在太舒服了,空氣又好,習慣自己準備早餐後,其實也沒有怎樣不方便,重點綠地又多,整個人就神清氣爽。

perth
圖1 Perth市區附近

taipei
圖2 大台北地區

  不過,這比較並不公平,根據維基百科上的資料,Perth總面積5,386平方公里,人口約170萬人(2010年7月),每平方公里住315人,反觀台北市新北市,261萬人和392萬人(2012年2月)分別住在272和2,053平方公里的面積裡,每平方公里分別住9,764人和1,909人,如果以整個大台北計算,則是每平方公里約住2,812人,更不用說這個數字並沒有反映出新北市人口集中在永和板橋三重蘆洲中和新莊等區的現象這些區每平方公里住超過20,000人。在這麼擁擠的地方能有圖2的成績,老實說實屬不易了,但是否有機會更好呢?大台北合計2,325平方公里,大概是Perth面積的43%,那公園的密度和面積如果有圖1裡40%的表現,我想大家的平時生活的火氣應該不會這麼大了,當初大台北人口急速增加(從外縣市遷入),加上沒有完善的規畫,讓大多數的土地都變成住宅、工業區,綠地也就從地圖上消失了。台灣的都市,逐漸消失的不只是綠地,也扼殺了乾淨的河川,和Perth緊鄰的Swan river相比,我覺得淡水河根本不是條河,反倒像是條臭水溝,此外,每天都會塞車的馬路,糟糕的空氣品質...失去的東西實在太多了。

  三、預期的效果和實際的落差

  我住的板橋,聽說過去有最多公園的『縣轄市』之稱,現在還是不是最多公園的『市轄區』我就不清楚了,但留心注意一下,很像下面這一張圖(我覺得大台北地區的都市都像下面這一張圖),房子很密集,除了幾條大馬路,其餘的路都很小條,公園也都很小,像是萬綠叢中一點紅般四散,這很難說是不好,不過這些公園的機能確實容易因為面積的關係,無法很完善,這跟當初發展時,建商盡可能將空地都蓋成住宅出售有關,就我父母的說法,那時碰上經濟起飛,房子如雨後春筍般不斷地蓋,父母努力賺了點錢有幸買到房子(現在已經買不起了Orz),但當初規畫時沒有規定要保留多少空地,馬路都很小條,房子也沒有車位(那時候誰買車啊),住宅區、工業區和商業區也混合在一起,更不用說當初很多建商蓋房子根本就沒有請建築師設計,以我舊家的公寓來說,樓梯每層的階梯數都不同,樓層高度也不同,我都很懷疑那公寓能夠承受幾級強度的地震?而且緊鄰著傳統市場,假日早上得忍受市場的吵雜,下午經過傳統市場得忍受馬路的油膩、濕滑和骯亂,當然,也可以說緊鄰市場很方便,就看對於上述缺點的容忍度有多高。由於沒有車位,汽機車就停在路邊,原本狹小的馬路被汽機車佔掉後,大型消防車也很難進入。

before
圖3 擁擠的巷道和小小的公園

  但土地就只有這麼多,還能開發的空地越來越少,而且既有的土地上都已經蓋有房子了,怎麼挪出綠地呢?怎麼拓寬馬路?怎麼重新畫定住宅區、商業區和工業區?這時只好透過都市更新,重新規畫區域,並進行綠地的整合和增加,及擴寬馬路,但原有住戶的房子怎麼辦?於是政府以提高容積率的方式,讓原本的土地能蓋更高的樓層,一來可以以地板面積換取土地面積,二來讓原有住戶有房子外,還讓建商有多餘的房子能出售獲利(建商不是慈善團體,沒有獲利,是不會有建商願意參與都更的,但說真的,建商養活不少工人,不該因為建商是較有錢的一方,就認定建商是邪惡的)。理想上的情況有點類似圖4,原本的房子被更高的大樓取代,釋出部分的土地作為馬路、綠地或是其他公共設施。但這只是理想上的,由於政府不是建商,所以真正實行都市更新的是建商,加上沒有完整的都更計畫,建商漸漸主導都更,建商挑的不見得是真正老舊急需都更的地區,而是有好價格的地區,再者,對於空地或公共空間的釋出規定太寬鬆,上述預期的效果並不突出。

after
圖4 以都更方式整合及擴充綠地

  另一個現象是,都更的範圍其實都很小,即便都更條例從原先的100%住戶同意,修改至80%住戶同意,小範圍都更依舊困難重重,大範圍都更沒有建商敢碰,也因為小範圍都更,即便容積率提高了,但底數不大,建商怎樣也要100%用完所有的容積率和土地面積,甚至有用一些方法讓原本是公共空間但一般民眾卻無法進入的例子。又或者是,在小範圍都更中,用任何可能的方法取得更多的土地面積換地板面積,即便是一戶或二戶,都會想辦法納入範圍,這些都導致更多的權利衝突。更重要的是,原先都更預期的效果,例如:住宅區、商業區和工業區的重劃,又或者是綠地的整合,這些在小範圍都更都很難達成,從表面看來,只是把一大群低矮的房舍變成大樓,雖然說這底子裡並不是全無優點,例如:更安全的建築設計,但和整體預期的公共利益相比,目前的都更並沒有發揮應有的作用,反而還惹來一身民怨。

  四、都更辦法的改善

  我相信當初設立都更條例的立意是良善的,但很可惜的是歷經8次的修正似乎還是有許多問題,但我覺得也不該因為目前的現況因噎廢食,反對所有的都更計畫,相反的,是修改遊戲規則,讓因都更獲利的一方(獲利不僅只有建商,還有獲得公共利益的人民)和損失的一方都有公平合理的籌碼進行對等的權利競爭。以下是我認為修改都更辦法可以考慮的方向:

  1. 政府主導 曾有候選人在新北市長的公辦辯論會中提到『公辦都更』,我認為是一個好的方向,可能是我疏忽了,我並沒有從辯論會或政策白皮書中,聽到或看到足夠多『如何實施公辦都更』的細節,由於現行的法律容易讓公務員陷入『圖利』的爭議,公務員盡可能不想惹麻煩事,也導致都更條例明明大多數的設計是由公權力主導都更,卻變成由建商主導的原因之一。要避免圖利的爭議,可能的方法是切割:在住宅區、商業區和工業區的重劃上由政府主導,而且這是最重要的,並由政府根據社區老舊程度劃定都更單元,例如超過40年以上的舊社區(街區)優先都更,並以社區為單作規劃,百分之多少的空地先保留下來作為綠地或公共設施,道路應該擴寬為多少公尺,公告後保留給原權利人一同討論的空間,等這些都規劃完後,剩餘的土地再由建商和原權利人協調權利轉換的部分。這樣的切割,建商單純只是承接建案,並從中獲取部分利益(售出剩餘房子),而非主導都更。

  2. 資訊公開 很多政策(不限都更)的爭議,都是資訊不對等所引起,政府有義務將所有的資訊都要『主動地』公開透明化,尤其是當政府主導都更,而且是以社區為單位的大範圍都更,牽涉到的權利人更多更複雜,甚至帶有強迫性(整片社區),包含都市更新的區域劃定、新社區的特色、容積率、空地保留比例、新建築的最高及最低公設比例、住戶的表態及意見等與任何一方的權利有相關的所有資訊都要公開,當民眾向政府請求資訊時,也不能有任何理由拒絕提供資訊。

  3. 更嚴謹的條例 目前的遊戲規則是否有利於任何一方,例如是否依然採用多數決的方式,讓多數人可以去決定少數人的權利,這可以檢討,畢竟牽扯到公共事務與權利競爭時,令全部人都滿意的方案是很少見的。政府公告都更規劃後,應由社區透過民主程序,依照比例選出一定數量之代表,例如每5戶就選出1名代表,且支持與反對兩方都要有代表,由代表團參與社區都更及特色的規劃,如此可以避免由建商單獨與住戶討論,讓住戶變成相對弱勢的情況。此外,加入終止條款或暫緩執行條款,在建商投入之前,任何一方(政府與原權利人)發現權利明顯受侵害時,可以終止計畫或暫緩計畫的執行。至於啟動終止條款或是暫緩條款是否需要前提或但書,暫緩後又該怎麼解決爭議,以保護另一方,可以再討論。

  4. 法條教育及公設律師的參與 剛剛提到的資訊不對等,除了資訊不透明外,還有一個非常重要的原因是對於法條的陌生,與面對落落長的條文,不知該如何解讀法條。與其討論12年國教,不如討論教育該教些什麼?目前國小到高中的教材,我覺得有用的東西沒有很多,把跟人民權利相關的法律條文納入教育還比較實際。用教育讓人民懂得條文好歸好,但緩不濟急,類似人民面對司法程序般,政府應該設立公設律師顧問團,不論是以代表團與政府討論時,或是建商與住戶單獨討論時(政府主導都更以目前的社會民情很難),公設律師都要出席,並代表住戶的一方,爭取與保護住戶的權利,而且規定在沒有律師的陪同下,禁止建商與住戶接洽。

  5. 納入對環境改善的建材與設施 由於都更不只是把老舊建築換掉而已,所以在規劃都更時,除了防火、防震等安全設計外,應盡可能使用環保建材與設計,之前曾看過一集Discovery的《現代工程大觀》,一位建築師將大樓中央空調的部分空氣清淨功能釋出作為公共使用,每日從建築的外部吸入大量空氣,並把空氣中的塵粒隔離後,再將乾淨的空氣排出大樓,並且對廢水管線做分類,增加廢水的回收率,這些都是可以納入考慮的。目前的民情不喜歡花錢買大而無用的公設,若是由政府主導都更時,被畫出去的保留地就該含有綠地、馬路和其他公設,且不納入售價,建商在設計建築時,也應限制建築的公設比上限,讓容積率的利用率達到最大化,以降低地板面積的單位成本,成本下降也意味著建商『可能』比較願意交換權利,此外也能將剩餘的房子售價壓低。

  6. 市容改善與特色保留 都更常常和市容改善劃上等號,但之前在報紙上看到一個外國建築師到台北說的一句話:台北的不斷改變,但整體看起來就是少了『何謂台北』的特色。當初我看到這句話,想法和這篇漫畫如出一轍,台灣本身是多元文化,從原住民開始、經荷蘭與西班牙殖民時期、明鄭時期、清朝統治,再到日本統治時期,台灣各地留下許多具有特色之建築與文化資產,這些特色在都更的過程中應予以保留,拆除一個建築是非常容易的,但一旦失去就再也拿不回來了,即便該建築所在位置影響了都更的進行,都可以使用搬遷的方式,將建築移到預定的保留地,或是變更設計,讓這些有特色的建築融入新的社區規劃。在現代與傳統的融合上,我認為日本相當地成功,即便是每平方公里住超過6,000人的東京(2011年8月),以我在東京遊玩2天的心得,只要留心注意還是會發現各地都還是有傳統的日本風味建築。

  7. 基礎建設的更新 當大家都在抱怨馬路鋪好沒多久又要挖,這跟當初地下基礎建設的規畫有關,這些地下基礎建設雖然埋在地下,卻沒有考慮到如何快速又不用挖開地面的維護方法,也導致A家要新接水管或是B家要維修漏水時,又或是要維修電信網路時,都要挖開馬路,所以,都更時除了地上的建築物,也要考慮地下的基礎建設及電線桿的地下化。

  我相信都更條例還有很多地方可以改善,也希望藉由這次事件能讓公眾能關心法條,也關心如何保護自身的權利,透過修法的方式讓法條更加完善,而不是一陣媒體旋風後又不聞不問,讓憾事再次發生。

  五、結語

  在文章的一開始,我提到Perth,如果哪一天,Perth的人口密度也成長到每平方公里超過2,000人時,Perth目前的都市規劃肯定不敷使用,即使再天才的人,也無法一次規畫上百年的都市計畫,和許多古老的城市相同,某種程度的都市更新是必要的,但都市更新的手段各有不同,這都是可以討論的。我可以理解當事人的情緒語言,但我和大多數的網友相同,不是當事人,所以我在文章中不願意用任何帶歧異的名詞(如釘子戶、惡霸或奸商)替在都市更新過程中的任何一方(立法單位執法單位建商願意參與的住戶不願參與的住戶)扣帽子,因為扣帽子對解決問題沒有任何幫助。我認為要解決問題,還是要透過『修法』,但即便都市更新法再怎麼修,相信我,都無法讓所有人滿意,最後,法要不要執行呢?要!但在執行之前,應盡最大努力協商,參與其中的任何一方,都可以思考一下整體的公益性及人民都想保有自己財產的權利,如果真到協商破局,依法該如何執行就執行吧!

  延伸閱讀

  原則上我並列這二篇文章,看倌自己看吧!我已經說了,這篇文章不討論個案):
  1. Facebook上一位網友關於王家都更案的看法。
  2. Facebook上另一位網友對於上一位網友看法的回應
  3. 網路新聞
  4. 天下雜誌文章:123

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  經過一番的拆解實驗,總算是把Game Framework for Android Programming Guide (暫定)給完工了,還好當初寫Sokoban程式的時候,有想過程式要移到手冊裡當範例,所以每個method都蠻短的蠻獨立的,話雖如此,還是常常會缺某個member data或是method,導致compile error,草稿算是完成了,不過還是希望有人能試讀看看,順便幫我找找書中有沒有臭蟲XD。

ReadyState

RunningState       

  下載連結:
  1. Game Framework for Android Programming Guide
  2. 書中使用的素材
  3. Game Framework for Android 2.0 載點

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  自從上次在貓空流浪了數小時的經驗後,就在也沒上貓空過了,不過我媽一直說她沒坐過貓空水晶纜車,所以今天特地跑去坐纜車,由於不是要爬山,一到動物園站後,馬上就跑去搭貓纜,拿了水晶纜車的預約券後,在入口處稍微等了一下,不過沒等多久就上車了,坐在我們對面的是來自香港的母女檔,其實外國人不少耶,像跟我們從忠孝復興站一路搭文湖線的日本情侶檔也是手上拿著旅遊指南來搭貓纜的。

DSCN3452

DSCN3455

  水晶纜車,顧名思義就是底下是強化玻璃,可以直接看到纜車的下方,感覺就不太一樣啦。

DSCN3459
感覺腳下空空如也

DSCN3460
都是第一次搭貓纜的我媽和我弟

DSCN3463
辛勤檢查的工作人員

  曾經停駛一段時間,過了三年多再次搭乘,感覺貓空站附近似乎變熱鬧了,上次來好像沒這麼多店說,不過午餐已經另有打算了,所以開始往山下走,去看一下茶推廣中心,然後再到指南宮站搭貓纜下山。

DSCN3466

  可能事隔已久,忘記了原來從貓空走到指南宮站所需要的時間,所以走到半路,我媽就放棄了,還好這次很快就等到公車了,不過路上遇到有廟正在好辦繞境儀式,難怪很多店家都在門口擺上祭品跟香柱。

DSCN3476

DSCN3477

  由於到指南宮站已經是下午一點多了,所以也沒進指南宮逛逛,就搭貓纜下山了,雖然那只是坐在哪邊面對哪邊的問題,但說真的,我覺得下山的風景比較漂亮XD。

DSCN3479

DSCN3482

DSCN3481

  好啦!今日第一個目標:讓老媽體驗貓纜,已經達成,接下來要去第二個目標,在woodstone大吃一頓啦!

  離開前的最後一張照片:還是一堆人等著搭貓纜上去呢!

DSCN3484

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  Well,昨天跑出去玩了一天,不過該作完的東西還是弄完了,只在模擬器裡面測總是怪怪的(哈~手邊沒有任何Android裝置),所以...有人想試玩嗎?歡迎下載試玩版(請用檔案總管的方式安裝到Android裝置上)。目前只有2關,沒有Reset的按鈕,玩的時候要稍微小心一點了XD。有問題請留言跟我反應,等程式碼稍微美化跟bug修完後再開始寫教學文件。

  經測試,2.3.3版的APK是可以在4.0上執行,所以就只留2.3.3版的apk檔給大家下載,這次是完整版(有遊戲說明)。

Welcome

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  老媽真的很喜歡花,一聽到有花展,馬上就說要去看,今天看到的蘭花還真是漂亮。回程幫老媽辦了一張悠遊卡,她說:就算我跟我弟沒空,她也可以自己搭捷運到處走走,這是好事,不然整天待在家也很無聊。

OS:SkyDrive的相簿功能超級爛...

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  今天把圖都貼上去了,當初設計圖片時,每個Block是24 * 24,但第一次顯示時,Android竟然自作聰明把圖顯示成36 * 36,找了一下原因,似乎跟Android裝置現在有多種螢幕尺寸有關,所以把圖片從res/drawable資料夾移到res/drawable-hdpi資料夾就沒事了,意思是這些圖片是專門為高解析度設計的,不需要做縮放的動作,不過24 * 24實際看起來真的有點小,所以後來又重新設計了一次圖片,改成40 * 40,這次看起來就還不錯,剩下的是把搬運工(Android委屈你了,除了讓你安桌椅,還讓你搬箱子)的移動跟搬班箱子的動作加進去,以及判斷是否過關的程式加入,就算完成了。

Welcome

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  有廣告有差喔!以前寫技術類文章根本沒人要看,沒想到經學長的廣告,技術類文章竟然變成痞客邦本日熱門文章,而且單日超過200人閱讀,well,希望大家會喜歡,如果文章有錯也歡迎告知。

Today

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  這又是一篇源自於學長在其『搞笑談軟工』部落格上的關於Design for testability問題,同樣這也引起網友的討論,但總覺得偏向於『對測試程式的修改』或是『使用第三方套件存取私有變數』,而不是修改程式讓程式變好測(Design for testability),所以就野人獻曝,提供一個我覺得比較合適的解法。問題中的WidgetFactoryV2類別同時肩負了Simple FactorySingleton的責任,前者負責針對Windows平台和Motif平台提供不同的factory instance;後者則讓factory在一個JVM只有一個instance。這樣的設計會讓測試不好測試,就如同問題中提到的,但事實上,這問題和Singleton是無關的,更貼切地說應該是『如何測試由平台引起的Simple Factory』,所以我將WidgetFactoryV2改成如圖1的SimpleWidgetFactory,只負責平台相依的問題,Singleton不再是它的責任,此外,我也將『平台』的資訊從程式內部直接呼叫System.getProperty()的方式,換成從參數傳入,如此一來,針對SimpleWidgetFactory就變得很容易測,如圖2所示。

SimpleWidgetFactory.png  
圖1 Simple Factory只負責平台相依問題

SimpleWidgetFactoryTests.png
圖2 SimpleWidgetFactory的測試案例 

  那Singleton變成誰的責任了?答案是由concrete factory自己負責,如圖3和圖4所示,雖然這會導致有些程式碼重複了(duplicated code壞味道),但這還在可以接受的範圍內,以物件生命週期的角度來看,自己管理自己的生命週期還是比較妥當一點。如此一來,Singleton的測試就簡單了:對同一類別呼叫二次getInstance(),檢查回傳的物件是不是同一個物件就結束了(圖5)。

Win32WidgetFactory.png
圖3 Win32WidgetFactory自己負責維護單一instance的責任

MotifWidgetFactory.png
圖4 MotifWidgetFactory自己負責維護單一instance的責任

FactorySingletonTests.png
圖5 針對Singleton的測試案例 

  好啦!對原先的設計做了些許的修改,提高了程式的可測性(Testability)大概就是這樣,可能有人會懷疑:『如果SimpleWidgetFactory不是呼叫getInstance(),而是直接new一個instance,這樣就能確保呼叫SimpleWidgetFactory.getFactory()就一定拿到同一個instance嗎?』針對這個問題...ㄜ...來人啊!把問這問題的人抓去讀Singleton 50遍,如果concrete factory真的實作Singleton,而且實作是正確的,那這個情形不可能發生,因為constructor早已被宣告成無法存取的層級(protected或private)。

  附錄:關於Simple FactoryFactory Method的差別,簡單地說,就是有沒有出現繼承,Simple Factory只是將四散在各地或是因平台相異的creation method集中在一個類別中,例如圖1,而Factory Method會有一個繼承架構,由一個介面(本例中的WidgetFactory)或抽象類別定義該有哪些creation methods,然後由繼承的類別(本例中的Win32WidgetFactoryMotifWidgetFactory)提供實作,至於creation methods是不是Template Method中的primitive operations,我個人沒有意見,可以是也可以不是,端看定義creation methods的抽象類別(Java中interface無法有實作)有沒有提供預設的skeleton實作和如何使用這些creation methods (變成Builder?),但個人傾向不使用這方法,原因一樣跟可測性有關,當一個類別承擔越多責任,除了內聚力下降外,也難以測試。

  題外話,如果真要說,WidgetFactoryWin32WidgetFactoryMotifWidgetFactory已經把Abstract Factory的『形』給建構出來了。

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  今天的內容源自於一個學長於Facebook上問的問題:『你的軟體即將於這個sprint結束之後就要準備送給測試部門進行測試,但是軟體還有幾十個open issues (bugs)還沒解完,而其中大部份的issues都只有某一位programmer可解。請問假設你是Scrum Master,你將如何處置?』這問題一出,引來許多人的討論,也有人開玩笑地說在解決完issue後要把那一位唯一能解的programmer開除,因為他程式寫得不好,所以別人才看不懂無法解決問題,真的是這樣嗎?有時候程式看不懂,並不是因為程式寫得不好,而是領域差太遠。如果整個專案都在同一個領域中,大家都是該領域的programmer,還出現這樣的情形,或許那位programmer真的要稍微檢討一下,但如果一個跨領域的專案,而且跨得很遠,如果沒有另外一個領域的知識,寫程式都很難寫了,更別說要解bug了。

  另外,bugs明明是學長放在括號內的補充說明,大家似乎都把open issues跟bugs畫上等號,但有時候open issues不見得是bugs,例如有一個車牌辨識的模組,由團隊中唯一一個影像處理專才A開發,大多數的情況下都能辨識出車牌號碼,但前一個sprint結束後,QA實測後發現當在黃昏接近晚上時,辨識率就很差,甚至比晚上還差,因此QA列出一個issue希望能夠改善辨識率,這是一個issue但不是bug (目前沒有100%辨識率的影像處理技術),問題來了,車牌辨識的過程中,有許多參數可以調整,調整了x參數可能可以提高黃昏時的辨識率,但也降低了白天的辨識率,或者是這個演算法本身就是有在白天到夜晚這之間昏暗不明時辨識率下降的問題,但其他時間辨識率很高,要解決這個issue,沒有影像處理相關知識,短時間內要解決基本上不可能,最後還是交給A來處理。

  雖然大多數Scrum的書都說,當一個Scrum team要組成時,成員的能力必須涵蓋開發整個專案所需要的各種知識,現實狀況中,如果專案沒有跨很大的領域,這可能容易達成,例如幫銀行開發某個行銷活動的配合系統,那大概就是由具database / network / security能力的programmers,加上有處理過金融系統經驗的programmer,這樣的團隊就組成了。不過話說回來,會用database的programmer好找,懂得最佳化database的programmer就不見得好找;直接用network API寫程式的programmer好找,會設計protocol或實作protocol的programmer難找,當網路出現異常,能排除網路問題的programmer也不好找;會用加解密API寫程式的programmer好找,但對流程是否安全、金鑰是否安全等問題清楚的programmer就不見得好找,於是,在公司經費有限或是徵才不順的情況下,可能出現一個團隊裡都是只會用API的programmer,外加一個經驗老到的天才programmer (同時具備上述三種技能的最高等級),如此一來,即使不定期的由經驗老到的programmer和其他人pair programming,當發生問題時,可能還是由經驗老到的programmer處理。

  有人可能會問:為什麼?都已經用pair programming了,知識應該會慢慢傳播給其他人啊!原因很簡單,有些知識很難透過用pair programming的方式傳遞,這個現象當領域跨得越遠越明顯,上述的network / database / security領域,會用API算是programmer的基礎技能,就算不會用,用Google搜尋都能找到一堆API的範例,至於API背後的原理,不重要也沒人想管,程式會動就好,而pair programming最容易傳遞的知識,我個人認為,正好就是從Google能搜尋到的東西,背後的原理...程式都寫不完了,還有空講長篇大論?其實,pair programming確實很容易培養新人,從不會用API到會用API寫程式,但當程式出現問題時,從pair programming中學習到的『零碎』知識,往往派不上用場。

  我還記得之前有入學新生問我:『念資工數學要不要很好啊?』我笑答:『跟那些念數學系的相比,我數學沒有很好耶,但大多數的情況下,確實用不到高深的數學...』,我說的是大多數情況下,但我還是遇到了那些少數案例,慶幸的是當時用的是『偽Scrum of Scrum』,解決跨領域的問題,那是一個將某數位電視協定,從最底層到最上層,含播放器都寫出來的專案,該協定主要有四層,每一層都需要不同的『數學知識』,而我和學弟負責的那一層,數學是最少最簡單的,而我們的上一層,就需要一大堆數學知識在背後,不然資料就解不出來;更上層的網路層,數學可能沒用到很多,但通訊協定要非常熟才行;再更上一層Video/Audio的解碼/同步/錯誤消除都用到相當多數學。說真的,雖然我主導架構設計會議,但跟他們開會,常常是鴨子聽雷,看他們寫程式,每一行都看得懂(都是很簡單的資料搬移、加減乘除),但就是搞不懂這背後的數學和用途,我頂多幫他們找找看有沒有memory leak (該專案是C/C++/Java混和的Android專案)。

  為什麼我會說是『偽Scrum of Scrum』呢?因為領域跨很大,所以由該領域的專家教授帶領的學生組成子Scrum team,然後由總計畫和每個子Scrum master組成Scrum of Scrum,每個子Scrum team實際上都只有1~3不等的組員而已。我是只畫class diagram不寫code的Scrum master,把數位電視協定標準中我們負責的那一層近200頁看完的和寫code的是學弟,其他組如何配置人力我不確定,但大概只有Video/Audio那一組有投入到3人,其他都不足3人,所以呢?整個team其實不過1x個,要視作一個扁平的Scrum也不是不行,因為當某一層出問題時,能解決問題的也只有某一組的某一或二人。話說回來,當初如果不是用Scrum of Scrum的方式組成開發團隊,情況是否會改善呢?我的答案是很難,整個數位電視協定的標準,橫跨1x份文件(我也不清楚為什麼沒有一份完整的文件,而是四散在不同的文件中),全部加起來有一千頁之多,能把每一層都弄懂個有三或四成都很困難了,只有三四成的知識能解bug嗎?

  像這樣跨領域的專案,我還能再舉幾個,例如更早之前我參與的某個號稱下世代無線通訊協定的模擬軟體(emulator),第一代的標準才2xx多頁,第二代的標準也暴增到上千頁,比起剛剛提到的數位電視標準還複雜,總共有七層,但每層大多只有1~2人負責,總計畫最多投入到4人。又例如網路遊戲,需要network、3D graphics、physics、AI、database等技能,但都是蠻相異的領域,以現在『App團隊』的規模,上述技能都能各有一個programmer就算是很不錯了,如果某領域出現問題,雖然還是得等該領域的programmer負責,但總比由一個人承擔二項或更多項技能好,因為當多個領域都發生問題時,卻還是得通通由那一位『天才』負責。

  說了這麼多,但問題已經發生了,身為Scrum Master該怎麼處理?既然是跑Scrum流程,也代表story沒做完並不是不能接受的,因此應先就已發現的open issues跟product owner討論,那些issues的問題可能不大(例如結果是正確的但performance在某些情況下會很糟,但那些情況並不常見),某些issues可能很重要(很常當掉或是某個UI很不好使用),討論後列下priority,並由product owner決定是否要延長專案的時程(學長加上這個sprint是release sprint的限制),或是在不延長專案的情況下,在這個sprint優先處理那些issues,那些issues在release之後以patch的方式發行。

  當要處理的issues決定後,召開一個技術會議,由該名能處理的programmer針對每個issue可能的原因進行說明,如果是bug,先從『取得資訊』的動作下手,取得資訊相較於解決問題容易,可以由其他team member處理,方法可能是在程式中加入printf,ㄟ~身為軟體開發與測試實驗室的成員,應該鼓勵大家用寫單元測試的方式,盡可能將可能發生bug的地方隔離出來,這時候該programmer可以處理非bugs的issues,讓issues和bugs同時處理,當issues處理差不多了,這時bugs應該也已經被隔離出來,該programmer可以節省隔離bugs的時間,至於在解issues/bugs時要不要pair programming呢?我持開放態度,因為就我的經驗,解bugs時,通常碰觸的程式碼都是很侷限的,對傳遞知識有多大幫助我沒什麼看法。

  我想預防還是勝於治療,我知道會想當programmer的人對程式都蠻好學的,但我也認為真正能夠學貫古今、博學多聞在各個領域都專精的天才並不多。如果遇上跨領域的專案,組成開發團隊時,還是盡量讓每個領域都有二個以上的專才,這樣遇上issues時,才不至於都落到只有一個人能負責的局面,雖然學長曾在一個座談會上說:『pair programming能分享知識,雖然不可能轉移100%的能力,但也可能有個三四成或六七成』,但就像有個軟體工程諺語說:『Debugging is twice as hard as writing the code in the first place』,這時候(處理issues),半吊子的人真的能派上用場嗎?不把問題愈挖愈大就不錯了。至於知識傳遞,我相信有其他更好的方法,例如每周一次全員都參加的workshop,由該領域的專才,提供有『系統的』知識傳遞,可以是投影片式的教學或是上機實習式的練習,我相信會比pair programming更有效率,前提是,product owner不介意每周有幾個小時整個Scrum team沒在工作XD。

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  自上次在電影院看完動畫後,一直想找個時間來看原畫展,但由於始終沒有找到人一同前往,只好在展覽快結束前,一個人來看展覽。本來以為今天是非假日,人應該會少一點吧!但買完票進場後就發現我錯了,人還是蠻多的,而且大家都看得很仔細,所以大家都走得很慢,不知道是因為這電影主題的關係,還是小學已經開學了?少了頑皮小孩的嬉鬧聲,這真的是值得高興的事。

DSCN3216.JPG

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  其實我是來當間諜的,ㄟ...開玩笑的,免得人家把我當成拒絕往來戶,以後不能參加產品發表會,不過確實是因為實驗室最近的研究跟雲端儲存有點關係,想來看看他們賣什麼葫蘆。之前有注意過Synology的產品,覺得他們公司的ID做得還不錯,至少產品外觀比很多廠商的要簡潔清爽許多,官方網站也做得不錯(蠻有apple.com的味道),不過身為窮學生一個,買iPhone都存了好久才下手,所以也遲遲沒買他們家的產品,只能說可惜今晚DS212j沒抽中我。以一個硬體廠來說,肯為軟體(Disk Station Manager)辦發表會我覺得是好事一件,也看的出來他們確實花不少心思在軟體上,UI的改善幅度頗大(從網站上可以找到過去版本的圖片),有看我部落格的都知道,對於硬體廠的軟體開發抱怨頗久的我來說,我覺得Synology似乎是頗有『軟』味的公司。

IMG_0054.JPG

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  說道尺寸,每個人的喜好都不太一樣,有人喜歡粗一點,有人喜歡長一點,也有人喜歡瘦一點,當然也有人喜歡大一點,但如果是虛擬機器的硬碟映像檔(Virtual Disk Image),我想大概沒有人喜歡它無限制大下去,特別是要傳送映像檔給另外一個人的時候,不管用網路傳,還是用隨身碟傳,都要傳上好一陣子,小一點3、4 GB,大一點1x GB,有時候隨身碟不夠大還塞不下去。

VirtualHDImage.png
圖1 肥胖的映像檔(4.43 GB)

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()

  最近在幫老師弄下周三要去X策會上課的教材,上課的內容是單元測試、整合測試、Mock object等,我準備的教材裡都要涵蓋這些東西,為了盡可能達到100%的statement coverage和branch coverage,所以,只要有>、>=、=、<和<=等二元符號,測試案例都要考慮到boundary test,最後,因無法在測試案例裡製造發生IOException的case,導致某些catch block測不到外,教材裡model的程式碼都測到了,這樣弄下來還蠻累的。

  沒想到回家的路上,就出現了某位總統候選人的輔選志工在測驗我的boundary,到底是怎麼回事呢?從府中站的電扶梯要出去捷運站回家時,門口站著一大票志工,沒看到候選人本人(在攝影棚準備政見發表會),平時下班時間就很多人的捷運站出口這時又更擠了,我往我的左邊看去,電扶梯旁明明還寫著:「捷運站區域內禁止競選活動」,不知道那些志工們有沒有看到那個標語,還是說他們認為門口不算是捷運站區域內呢?他們心中那條切割捷運站區域內或外的boundary在哪裡?

  或許有人覺得我雞蛋裡挑骨頭,那我再說另外一件事吧!幾天前又是一個下雨的早上,無法騎腳踏車的我,又走到捷運站搭車,在還沒到捷運站前的板橋農會門口前,也是一位跟剛剛那位總統候選人同黨的立委候選人,親自站在那裡拜票,板橋農會和捷運站門口隔著一條馬路,說近很近,但在我的眼中,她不是在捷運站區域內從事競選活動,至少她不會妨礙到要進出捷運站的人,那麼冷的天氣,要在哪裡站上好幾個鐘頭,跟沿路經過的民眾拜託,我還蠻佩服她的。

  隔著一條馬路,我覺得那些志工是在游走規定(法律?印象中,在捷運站區域內從事競選活動有罰款)邊緣。如果法律是那些搞政治的人弄出來的,那我更不接受政治人物自己在游走法律邊緣。離投票日沒剩下幾天了,說真的,我還沒決定要投給誰,不過,今天的事件,也許可以當作一個參考。

  p.s. 別問我那位候選人是誰。

Posted by dbi1463 at 痞客邦 PIXNET 留言(0) 引用(0) 人氣()