February, 2005 > 所有文章列表
剛貼完上一篇後，就在msn與irc與朋友展開討論，先速記幾點結論：
-沒有這種習慣 或 國情不同 似乎是大部份人對這件事共同的結論
-我覺得主要是看生活步調, 很少有地方像日本的都市的步調那麼快
大陸型國家(北美、歐洲)應該也都沒有這種市場因為他們都開車 而不做電車
-通常i-mode這類型的服務稱為 數據服務，與一般純講電話的語音服務是兩碼子事，因此雖然台灣有上千萬支手機，但裏面會用到數據服務的比例可能不高。
-手機的數據服務一般會拿來跟 wifi 無線網路比較，也就是 手機 vs PDA/Notebook 的局面
-台灣無線網路普及率越來越高，且價格遠低於手機，更別提易用性(大畫面等)
-所以就是要比誰在內容的轉換成手機/PDA大小的畫面，容易吸引人, 慢慢的要看應用誰勝利
(現在連上去螢幕都要拉來來去，誰能轉換的好，他就贏)
-我覺得什麼都會有人願意付錢，但重點在於經濟規模，而經濟規模要靠良好的服務來創造
-從數量看，手機有千萬支的量，但裏面真正會用數據服務的人可能只有幾萬人，這些人可說是早期採用者(玩家)，但這些玩家也非常可能同時有pda/notebook等其它可上網設備，overlap率非常高，因此不能單從「數量」這個因素來比較；假設一個玩家在同時有wifi與i-mode的環境下，手邊有pda/note 與 手機，他/她會選擇用什麼上網呢？(我猜是便宜的那個，也就是wifi)
所以今晚的結論是，問題不在於有沒有能力用 wap/gprs/phs/3g做出一個 i-mode的系統 clone, 問題在於平台做出來後有多大的市場？而這個平台前/後整合資源(手機業者、技術細節、內容供應….)要付出的成本可能高到讓電信業者駐足不前。
這讓我回想起去年某3g業者與我們恰談flashcom整合入手機時的情況，當時對方一直在問的就是：為何i-mode會成功？3g有什麼killer app 可開發嗎？當然那時還沒有flashlite，flashcast也才剛起步，而flashcom連在手機上連線都不行，因此當然是沒談出什麼結果。只是現在再回頭來看，這很可能根本不是技術層面的問題，而是國情、生活習慣與競爭因素的大集合。
alright, that’s enough for one night. 
| by admin
1、如果i-mode只是一通訊介面，而手機只是一個上網的裝置(internet accessor)，那為何同類型的技術如wap、gprs 不會紅？(假設同樣放在日本這個封閉市場來比較)
2、based on first question, 日本還會有第二個i-mode出現嗎？
如果我的理解沒錯，i-mode本身是一個架構在電信網路上的通訊層，這個電信網提供了 電信封包 < -> 網路封包 的轉換服務，也就是將i-mode手機傳出的 TL, PDC-P 轉譯成標準的 TCP/IP 再傳達給一般的網站，反向也是一樣的運作。然後再加上i-mode手機內建browser，透過這個browser去存取網路上無限的服務提供者/網站，這也是i-mode最引以為傲之 豐富服務 的電來。
如果這個理解為真，那為何沒有人用 WAP/GPRS玩同樣的事？只要電信業者建構了WAP/GPRS通訊層轉換為TCP/IP通訊層的服務，那任何一個支援WAP/GPRS的手機也就俱備存取網路的能力，然後只要再加上一個手機可用的browser，那每個手機的用家就一樣可隨地使用網際網路上的服務。
這裏面到底是那裏出了問題？
1、是通訊層轉換太困難(例如無共通標準，如非像i-mode以一家之力獨幹)？
2、還是手機要塞一個browser進去太困難？(沒人寫？或是每支手機 的os都不同，很難寫一個給大家用？但java現在這麼普及，有jvm可玩java game的手機也挺多，用這個vm寫一個browser再透過底層wap/gprs去上網應該沒這麼難吧？)
3、雞生蛋、蛋生雞問的循環，或許上述兩件事都能解決，但業者擔心根本沒這麼多內容提供者或killer app可用，所以不願意投入成本？
4、其實前述幾件事早就有人做了，只是我孤陋寡聞不知道而已？
另外幾個延申的思考方向為：
1、flashlite在這整件事裏的位置在那裏？它想吃技術服務提供app這塊嗎？或是成為另一個 MIDP寫game跟java game一較高下？
2、505i之後的手機(以及nokia等越來越多手機)都有flashlite player了，然後下一步呢？目前看到台灣的玩家似乎都熱情的在寫flashlite game，但這就是一切了嗎？flashlite有可能再創一次i-mode的奇績，由flashlite起頭重新帶動wap/gprs/3g 的應用嗎？
3、wifi無線網路的普及對i-mode/3g 的衝擊有多大？如果i-mode本質上真如我所設想的只是 internet accessor，那一旦wifi普及，pda/notebook/smartphone等都可扮演 accessor角色，此時手機該何去何從？而內容業者又會願意提供多種不同版本的內容嗎？< 是否為swf應用的好切入點？>
note to self:
1、找phs、i-mode與3g的朋友聊聊，聽聽他們的意見。
| by admin
新聞稿
似乎沒有太吸引人，大概不用升級。
其實是怕既有的一堆plugins又失效，還是遵從 if it’s not broken, don’t fix it.
| by admin
用flash開發ria 的人越來越多，而隨者flex的推出，現在大部份flash coder都已經聽過或大致瞭解 mvc/mvp 這幾種pattern的意義，甚至可能也實作過一些範例。
但最近越思考如何用flash實現真正完整的OO程式規畫，就越發現實際上目前大部份人在flash裏採的mvc並不是那麼的純正(當然有人會接者argue說為何一定要管純正與否？能work不就好了？這是個好問題，等日後有空再討論)。
簡單先整理一下目前的結論：
1、mvc是個pattern，就跟其它所有的pattern一樣也只是個方法論，因為要用何種技術去實作都是ok的，只是大部份pattern都是以物件導向技術為基礎做討論，因此讓人覺得pattern = oo (也就是說 mvc = oo)。
2、mvc 中的 view-controller 這一段是可以很合理的與model 切開分離的，這樣做可以保持彈性。
3、而model這一段，也就是oo分析裏面說的domain models (或三階架構用的 business objects)要如何實作，就不一定要是oo了，目前90%的書、網站範例與教學都是採用data-driven的方式來處理，例如將database傳回的資料放進recordset(或更極端的放進datagrid裏當容器)，而不是依照java/net的手法，將這些recordset再建構成適當的object instance。
所以可以得知 model 這塊裏面，可以用 data-driven直接做掉(dirty and quick法)，也可以乖乖的cast成適當的物件，而這裏採取的手法，就直接反應了程式師的編程風格與邏輯，是否要走物件導向，從這裏也就看得出來。
因此目前在使用mvc的flash開發者應該要清楚的知道，使用mvc不代表已經是物件導向，就像會用actionscript 2.0 也不代表就懂物件導向編程(試者問自已，上一次用interface是何時？真的瞭解為何需要 interface而不是inheritence就好？)
而至於OO這樣的方法對flash開發來說是不是 too overkill 這個問題(很巧的在flashcoder list上有一串精彩的討論，另外有一串 mvc what ? 也值得一看)，大底上來說是永遠不會有答案的，只能說這是選擇的哲學，oo有它明顯的好處(你知道的，不外乎就是彈性、維護、重覆使用….)，但也有為人垢病的地方(廢時、廢工…)，但我認為全程採用oo是一個 trade-off 的選擇，的確選擇oo一開始要付出的學習成本非常高，甚至生產力會大幅降低，但一旦完全上手成熟後，可以確保往後十幾二十年的開發品質，因為這段學oo的過程，不但會完全改變一個人的coding方式與技巧，連思考一個問題的方式也會改變，變的更條理、模組化，因此自然比較有可能一開始就將事情做好。
當然我也不否認寫了十年的 C(或任何其它非oo語言)高手，也一樣有辦法規畫出結構良好，簡單易懂的程式，只要將程式段落分清楚、切乾淨，這一切也是有可能做到的，只是考量目前常見的語言(java, c#, as2, perl, python…)都已經物件化，而oo本身所提供的思考方式與功能，不用似乎太可惜，再加上如果將來真的想將flash做為開發大型企業應用程式(不論是用flash或flex)，擁有完整且成熟的oo經驗已經是不可或缺的了。
所以，是該時後開始學啦。
ps. 經常被問到如果想學好flash 00的開發該看什麼書，過陣子我會試者列出清單，如果有電子書的部份也會想辦法放上網路。不過可以先給大家一個基本方向，以我的感覺，目前flash的進階書中，真正講到完整oo的並不多，colin moock那本EAS2.0(趙英傑先生已經完成翻譯並出版)可以提供學習 as2.0這個語言的完整教材，但對於用oo實作專案則明顯不足(書中那兩個例子都太單純不足以呈現實務中必然面對的挑戰)。
如果真要找書，我建議朝 java/.net 的方向去看，找一本從頭介紹 OOAD 與 code實作的書來看完，或許你看不懂書中的語法，但介紹概念的部份仍然非常值得學習，邊看邊想怎麼用actionscript去實作，並且結合flash的某些特性，就會覺得大獲啟發了。
| by admin
flashORB 大約在兩年前(約略是flashcom 1.0發表後幾個月)出來，當時因為他號稱提供某些 xml socket server功能，因此吸引大批想做連線運用(聊天、線上遊戲等)的開發者的注意，當然它較mm牌便宜一半的價格(當時賣二萬元台幣，mm牌 .net/java 約四萬五)也是重要因素之一。
但當時因為剛出來，到底公司能活多久也不知道，規格也還不穩定，加上只有java版，所以玩過幾次後就以“反正還有 openamf 可選擇“為由，直接放棄追蹤這項產品。
沒想到事隔兩年，它可已是翻兩翻變個樣兒，不但已成為成熟的 1.0版(1.5正beta中)，並且還兼有 java/.net 兩版本，而這還不是最重要的，真正另人興奮的部份在於java版有所謂的 standalone mode, 它內附了 jetty web server與 servlet engine, 也就是說它本身是個小型的 web server + application server，因此，它可以完全獨立運作，這代表什麼意義呢？
請看下圖：
(Flash UI) < --(Standalone ORB)--> (Embedded Database + Domain Objects)
[來源]
flashorb standalone版的出現，代表要用flash做為win32/desktop app的前端介面越來越有可能，
以往在win32環境下，要用flash寫單機程式，大概只能自已用 C++/C#硬幹(我們已經用這玩意實作過一些案子了)或是用 MDM的flash studio pro或其它類似的軟體來包住swf檔。
但現在有了真正的remoting能力，flash 接上 system 這段就變的更輕鬆，可以用更 native 的 code來運作，實際上這也是 .net remoting等 remoting系列正常該有的做法。
之前跟gush作者聊天時得知，他們為了達成類似的目地，自已用 phyton寫了個xml socket server來當remoting用，那晚差點當場上三柱香遙拜 orz，好家在現在有這flashorb，大家都可以很輕鬆的寫單機版的flash程式了。
幾個附註：
1、Flashorb的出現並不會代表flash studio pro(最近改名zinc)這類的產品會沒前途，因為它們還真是好用，如果只是簡單的system API 服務或資料庫存取，其實這樣就夠了，它們唯一會讓人覺得不足的地方就是當要玩內定api不支援的東西時，就比較麻煩，而且單機與網路版得寫兩次。用flashorb就可以畢其功於一役。
2、將flash做為單機程式的gui介面其實還有許多方法，例如 xaml 這樣的產品就可以用tag的方式來生成swf(聽起來跟flex很像吧？其實laszlo也是一樣的東西)，也有人試者用xml檔加上as2 compiler去生成swf，所以路途千百種，路死誰手還不知道。
3、mm做為技術的擁有者，確實能挺快速的掌握走向，例如flashcom與flex就分別代表兩種完全不同的未來，但可惜的地方在於，mm做為一個上市公司(而且是挺龐大的公司)，最終還是在商業行為顯的太緩慢，例如flashcom的授權策略(限制人頭/頻寬)與flex的高昂價格。這些都讓mm原本可以更快速推展flash這樣利基產品並成為此領域龍頭老大的機會轉身而過，所以變成現在flex有laszlo追在後面打，remoting有phpamf, flashorb與其它一狗票的相容軟體可取代，就連flashcom也被許多home-grown socket server給取代掉了。我想mm的ceo晚上大概很難睡的好吧。
4、flashorb 的 forum
我想未來將會投資更多時間在 flashORB.NET這塊上面，覺得是值得的投資。
| by admin
Previous Posts
