這只是這幾天觀察的一個小心得...
在日本, 路上看到的iPhone並不算少, 但總覺得比例上比在台灣上看到的還少, 雖然說我目前看的只有大阪地區, 不過, 不能說iPhone賣不好, 只是想說, 在這市場, Android的機會會比iPhone來得大
來過好幾次日本, 也有注意到日本人換新機的速度之快, 每個人用的手機幾乎都是比新的, 足以見得日本人對手機喜新厭舊的程度, 大家都要最新最好
加上, 日本手機其實客製化的程度頗高, 同一款手機, au KDDI和Softbank裡面欲裝的AP一定不同, 甚至還有像Disney phone這種針對特殊族群設計不同功能的手機
這兩點其實正好就是iPhone做不到的, iPhone一年才出一支新的, 應該滿足不了喜新厭舊的, 至於客製化, iPhone幾乎不客製化的吧....但這兩點確是Android的強項, 幾乎滿滿的機海, 加上可以任意客製, 要滿足這市場應該比較容易
這幾天外面看到smart phine的除了iPhone外, 最常看到的就是Sharp那隻3D的手機了...
今天吃了兩家, 黑潮跟一蘭...
先說說黑潮吧, 有點像踩到雷了, 點了兩碗拉麵, 豚骨還有一個寶拉麵
豚骨拉麵真的是地雷, 沒啥特色, 只是濃油而已....不說也罷...至於寶拉麵, 號稱鮪魚湯頭(我從網路上看來的), 雖沒有魚介類湯頭的腥味, 但不知怎, 稠到一個不行, 不是濃而已喔, 是稠....像是勾過芡, 但日本拉麵不勾芡的吧...又不是大滷麵, 不知道怎會稠到像勾過芡, 除了濃稠外, 我實在也想不出啥形容詞, 只能說這碗還OK不會太爛
接下來是聞名天下的"一蘭"
一蘭讓我學到...要如何製造排隊? 就是位子弄少一點, 這樣外面大排長龍, 看起來就很熱門, 不過本身也有他獨到之處啦!
要說一蘭的特色在哪? 我覺就兩個字..."專注"...整個菜單上的拉麵不像其他店那麼多樣化, 就是"拉麵"而已, 其他的就是客製化了...
這碗拉麵就長這樣:
要不是昨天吃過一風堂, 我可能今天就覺得光吃這碗就不虛此行了, 不過, 我覺得他湯頭跟一風堂比起來只能算不相上下, 甚至我還喜歡一風堂多些, 不過比到麵條....一蘭的麵條的口感就明顯勝了, 我今天故意選偏軟一點的, 口感還是一樣棒...叉燒入口即化, 也是很優
不管怎說, 湯頭還是很棒, 還是要讓他見底, 讓碗底出來見見天日
晚上這碗的確很棒, 比起中午的黑潮好太多了
今天吃的是博多一風堂, 這家可是擁有許多分店包含國外, 紐約和新加坡, 能開這麼多家分店, 要嘛就是有他一套, 要嘛就是亂開, 地雷很多, 不過, 這家應該是前者才對
本來今天也不是預計吃這家, 本想吃作ノ作, 黑潮, 離飯店也比較近, 無奈從海遊館回來後, 從都營地鐵的迷宮重見天日後, 又繼續迷路, 往了心齋橋反方向走, 不小心遇到這家(但也離飯店越來越遠導致今天腳都沒力了), 不過雖是名店的分店, 但店面跟一般拉麵店一樣, 很小間(比起這邊到處可見的金龍, 算很小, 金龍也不知道在紅啥的)
好吧, 無能老爸的錯, 到了時已經累翻了...
說起博多, 自然就是豚骨湯底囉! 這邊當然就是正統的白湯底, 又濃又厚的豚骨湯, 菜單上當然也不需要太多選項囉!!
我們點了兩碗, 一碗赤丸(照例, 還是我的),一碗傳統的白丸
白丸赤丸差哪裡呢? 赤丸就是白丸加上一團辣肉團, 和胡麻油(黑黑那個), 原本是不含半熟玉的, 要的話要加點
桌上有生大蒜和辣豆苗可取用
不得不說, 這家是我這三天吃的最好吃的一家, 比起前天的神座, 又更上一級, 豚骨湯則是比黑門屋跟河童還來的鮮甜, 湯頭的鹹度和鮮甜搭配的剛剛好, 雖然上面浮著一層豬脂, 但吃起來卻不覺油膩, 赤丸加上胡麻油, 多了一股香氣, 卻沒昨天吃的黑河童的苦味, 麵條也是細麵, 硬度中等, 麵條口感雖沒河童好, 但差不多啦, 也是很好吃
不過, 我每碗都說好吃, 可能比較會被覺得唬人....小朋友總比較不會說謊了吧....這是這三天吃的唯一一家我兒子說了好吃後悶著頭一直吃的(他很少停下來不講話的, 而且在這之前一個多小時前才吃過漢堡)
吃到滿臉都是:
昨天吃的黑門屋, 神座, 大多網路上都有台灣人的blog介紹, 今天想找找不同的, 剛好旅館附近, 過個大馬路就有一家河童拉麵, 這家拉麵似乎沒有啥繁中的blog有介紹, 但卻是已經是一家開了多家分店的拉麵店了, 心想應該不會是地雷才對
千日前這家是本舖
我們點了兩種拉麵, 紅河童跟黑河童:
理所當然, 紅的那碗當然是我的囉, 而且紅的還是本舖限定
紅的那碗當然是辣的, 不過對我這個吃很辣的人來說這辣還好, 但沒過辣的好處是, 跟湯頭搭配的不錯, 豚骨湯頭的鮮甜, 加上適度的辣度, 一開始乍看之下, 我還以為是擔擔麵
麵條是細麵, 比起我昨天吃的還硬一些, 不過口感很不錯, 他們標榜自製麵, 這麵條還蠻好吃的, 而且平日11am~9pm加麵免錢...
黑的那碗, 剛吃的時候, 胡麻的香氣撲鼻而來, 湯頭香氣還蠻夠的, 豚骨湯頭的鮮甜度讓整體喝起來也蠻順口的, 美中不足的是, 所使用的胡麻喝到後面有帶點淡淡的苦味
比起昨天同樣是豚骨湯頭的黑門屋來說, 他的湯頭有稍甜一些些, 但整體來說感覺差不多, 比較沒有昨天吃神座那種讓我小小的讚賞的感覺
另外有免費泡菜可以添加
我還點了杯生啤
生啤本身並沒啥好特別的, 但招待一小盤下酒菜, 炸大蒜....這我還是第一次吃到
剩下的口袋名單還有作ノ作, 黑潮, 一風堂, 一蘭 (其實旅館對面還有家四天王, 早上五點就營業)
這次來大阪, 就是打定了...來吃拉麵!!!
今天一到飯店, 稍事休息後就去逛街吃章魚燒, 傍晚的時候到黑門市場入口的那家黑門屋拉麵吃, 這家似乎網路上有不錯的評價
這家店面相當的小
其實就只有一排不到十個的座位, 用食事券點餐, 選擇還算多, 豚骨, 味噌, 鹽味, 醬油湯頭皆有, 我個人是喜歡鹽味湯頭, 但台灣實在沒這種湯頭的拉麵, 但我今天反而不是點鹽味的, 菜單看不是很懂, 但看到有道上面寫個"祕"字就點下去了
這是豚骨湯頭, 湯頭本身還算扎實, 麵條是細面稍硬, 但口感還不錯, 叉燒不錯吃, 有點入口即化的感覺, 上面有些蔥花, 但還好(比起我後面吃那碗來說)
我老婆點的是這碗, 黑門屋拉麵, 也是豚骨湯底, 但超濃厚, 雖然我口味重, 面是粗麵, 但我反而不偏好這碗, 我兒子吃後也覺得我那碗比較好吃
在這邊吃的時候遇到兩個台灣美眉, 也是尋著網路介紹來的, 看來網路的力量還真大
晚上我一個人跑出去逛, 由於我們就住在千日前, 附近相當熱鬧, 我就朝道頓㻕方向走, 這一整條路有不少看起來還不錯的拉麵店, 我就憑我直覺選了這家"神座"來吃我今晚的第二碗拉麵
買食事券時我猶豫了一下, 實在不知道那邊口味如何, 後來我就選了蔥拉麵
由於晚上出去忘了帶相機出去, 只好用手機拍拍, 拍出來的賣相好像沒那麼好
其實我也不知道這家店招牌是啥, 但一進門發現好多人桌上都一大盤蔥, 我就知道我應該沒點錯, 小姐一開始端來時還忘了把蔥給我, 我還以為我點錯了, 還好, 我的蔥也是一大盤
湯頭是偏醬油味, 但特別的是, 這似乎是白菜熬煮出來的, 裡面有一堆白菜, 搭配的也是細麵
然後...青蔥, 當然是要豪邁的整盤倒下去啦!!!
不知道該怎形容這碗麵好吃的程度....我只能說, 我吃這碗麵的聲音是..."咻咻~~卡茲卡茲"...青翠的青蔥口感真是好....這湯頭油但不膩, 裡面白菜的量也不少!
一晚挑戰兩碗...好過癮呀!!!我還要在挑戰其他的....一蘭也要列入名單內!!!
今天才又忽然想起以前寫過這玩具, 這個在之前演講時, 有拿出來小Demo過, 不過只是當時隨便玩玩的, 就又沈寂, 也忘了分享source出來了, 這個範例很簡單, 只是寫了一個Java interface去給WebView裡的javascript呼叫, 並用JQuery mobile做出list view
呃, 不過話說回來, 我另一個玩具Rhino on Android好像無聲無息很久了... @@"
有點偷懶, 超過一個禮拜沒寫了, 來隨便寫個一篇....
最近覺得, tablet比手機有趣一點, 智慧型手機將會是(也已經差不多是)人人必備的工具了, 但tablet目前卻還有很多可塑性
昨天看到這一篇: 當CEO打算送給所有員工iPad：一位CIO的故事
我用了iPad也好一陣子了, 從一代用到現在二代, 看到這篇除了覺得"這老闆好凱", "怎我老闆不送我"(誤)外, 第一個想法是, iPad不是一個適合拿來做商務應用的平板....沒錯, 它很好用, 也可以適用很多用途, 但它的取向是比較通用的應用, 你可以拿它來玩遊戲, 聽音樂, 看電影(娛樂), 可以拿來教小朋友數學, 英文(教育), 可以拿來收發mail(商務), 但拿來當一個專用的(尤其是公司內應用)的商務平板, 就略嫌不足, 舉個例, 如文章中提到的device deplyment這件事就沒辦法容易達成, 每台iPad都得分別開通, 而非公司IT可以送到你手上後就已經預載好所有應用跟設定
商務平板應該是不錯的生意, Black berry之所以還可以佔有一大片領土, 有一部分就是由Business這方向貢獻, 還蠻多公司會發送BB給員工當商務使用
(我認為的)商務平板該有什麼呢?
資訊查詢, 提醒以及速記絕對是標準功能, 很多人工作上常常碰到的活動不外乎是開會, 討論之類的, 這類的活動, 資訊的紀錄, 交流 等等...就蠻必要的, 如果可以很快速的做紀錄, 比如說速記, 拍下白板之類的動作, 就還蠻必要的, 現在很多標榜商務平板的, 像是富士通Q550, 都標榜附上筆, 無非是, 筆是速記上一個很好的工具
Acess anywhere, 平板最主要的優勢是, 它比Notebook有更高的行動力, 可以在任何地方使用它, 甚至是你泡澡的時候, 能夠很快存取你所需要的資訊就很重要, 像是跟公司資訊系統的整合, 現在很大部份的公司內部系統都已經web化了, 因此要達到這點, 瀏覽器的相容性就很重要, 還有就是檔案的存取(整合SMB, FTP等等), 現在的iPad缺乏工具可以存取遠端檔案, 而且缺乏工具可以開啟大部分類型的檔案, 最好是還可以有開放的API供一些比較有能力的公司IT人員開發相關的整合程式, 另外存取遠端桌面(VNC), terminal等等應用其實也不錯, 最後最重要的是, 由於是可以"Access anywhere", 安全性相當重要, 加密的連線, 以及VPN都應該是要必備條件
安全性, BB受歡迎的其中一點除了是傳送訊息(Mail, SMS)方便外, 另一個就是安全性, 前面已經有提到VPN和加密連線, 如果要達到好的商務平板需要的不只這些, 可以隨處帶的東西, 丟失的機率就很高, 安全性是相當重要的, 目前iPad和大多數Android平板, 丟失後很難說有安全可言, 如果還可以跟公司認證系統結合(使用者認證), 以及防止資料的拷貝與外流, 加密的檔案系統, 以及遠端的資料管理(遙控刪除), 那應該就可以增加不少安全性
Device management, 前面所說的device deployment就是其中一項, 要讓IT人員可以很快push hot fix或是新的服務(應用軟體)到每個人的平板上, 針對遺失的裝置做搜尋或遠端控管(強制上鎖, 刪除資料), 遠端更改設定等等
最後一點, 這是我隨便亂想的, 就是跟公司內裝置的連接性, 這想法是來自於, 公司的影印機, 傳真機, 離座位通常都比較遠, 每次印個東西都得跑大老遠, 印錯了或是漏了, 都得在影印機跟座位之間來回, 如果平板可以很順利的連接這類裝置, 那就可以省掉不少麻煩... (我太懶)
以上, 是剛醒來隨便亂想, 沒事亂寫寫充版面的, 不用太認真.. :P 我的結論只有一個, 要拿iPad來當這類的商務使用, 好像還有點距離就是了....
iCould其實感覺好像還不錯, 雖然說Google有Google的Backup manager, 但像是自動拍照就自動備份到自己的stream這東西, 就沒有了
以雲端儲存來說, DropBox算是相當不錯了, 所以其實也可以利用它呀, 想到兩種方式:
[[posterous-content:pid___0]]Dropbox as a fake SD
Android很多功能, 像是相機, 沒了SD card就好像廢物一樣, 實在很討厭
如果把Dropbox功能implement成一個Fake SD card, 在有網路時自動掛載, 沒網路時卸載, 在沒SD卡時也可以把他當SD來用, 應該會蠻實用的吧
這應該可以透過FUSE, 改vold等方法來達成, 找到一個dropbox on fuse的implementation: Dropfuse
不過這方法應該只是用於rooted rom或是自己build的rom
Auto backup to Dropbox
這方法應該是比較容易實現的, 利用Android上FileObserver來實做一個SD monitor (監視SD或是其他的external storage), 在有改變時就自動同步到dropbox去, 如Camera拍了張照片
FileObserver的使用方法很簡單, 如下:
這API不需要一個特定的thread一直去polling, 但由於這個instance如果被GC掉時, 就不會有任何event送達, 所以應該是要在一個Service內來實做這樣一個功能
有點寫(畫)上癮了
基本上, 越來越天馬行空了, 所以算是寫好玩的吧, 現在根本沒時間去做那麼多
新功能 - 問題發問:
如果在簡報的同時, 螢幕上也同時顯示一個QR Code, 聽眾只要事先用手機掃描這QR Code並帶他到一個可以問問題的URL去, 聽眾在一面聽的過程可以透過手機發問問題, 在Q&A投影片時自動列出所有的問題
自從看了Google I/O上Reto Meier用兩台Xoom做簡報, 就一直很想這樣做, 光靠手機和tablet做簡報, 而不是靠笨重的電腦, 上次去大陸出差, 用iPad+Keynote當場做投影片當場簡報, 這樣做還蠻爽的, 只是好像離我理想中(通常都過大)還差很遠, Reto Meier有說要放出Source, 但我等好久了....Source咧.... orz
今天跟人又討論起這東西, 回家路上, 順便把我想要的function design隨便塗鴉出來:
哇哈哈...這聽起來好像好難...我好像太挑剔了... XD
最近為了想實現device 2 device的auto discovery/communication ，特別去研究了bonjour/mdns，今天跑去GTUG時，試著想利用mdns從我的mbp找我的手機時一直不成功，起初還以為我程式有問題，抓了封包，卻找不到mdns的封包，後來才發現到，原來我手機連上的wireless ap跟mbp連上的是不同一台，雖然同屬同一家咖啡廳，但卻是不同的subnet，當然就收不到multicast的封包
有了這樣一個經驗後，當下就開始思考(哈，台上講的我老早就沒認真聽了），利用multicast做這樣的應用到底實不實用，雖然說不管是mdns也好，還是upnp用的ssdp，都還蠻適合這類應用的，而且它們都是以udp multicast來實作，但對mobile device而言，特色是不會固定attach在同一個network，ip也隨時在變，利用multicast的方式大概只有在同一個wifi網路之下比較適用，要做真正 decentralized device 2 device discovery好像有點難度
因此後來我又轉往另一個想法，geographical peer to peer，剛剛想了幾個簡單的想法，先寫下來
Why peer 2 peer?
其實只是很單純的想讓在同一區域的mobile devices可以不用透過某一個central server來交換資料，或是通訊，甚至達到類似c2dm的功效，所以想是個可以處理peer 2 peer communication的service，支援的application只需要跟它註冊服務資訊，收到的request就以broadcast intent的方式交給相關服務處理。
大部分的P2P network像是BitTorrent, Napster, Gnutella, eDonkey, Tor都是為了分享而存在, 也有像是Skype是為了通訊, 由於我最初的想法是想達到zero configuration的通訊跟分享, 所以第一方面就往這方向的機制去想, 當然也不是為了做一個像BitTorrent這樣規模的東西
Why geographical?
最早的想法是local share, 也就是在同一個區域, 比如說同一個房間, 同一間會議室裡的mobile device之間的相互分享溝通, 所以最早想到的是Bonjour類型(基於mDNS), 不過如前述, 問題就存在於這些裝置未必在同一個sub net, 甚至是有些未必是用wifi, 也有可能是3G
想到的作法是： 借用BUMP的作法來建立一個虛擬的區域網路, 這"區域"是實際地理位置上的區域, 而非一般的LAN, 現在的mobile device, 大多都有定位系統, 取得地理位置資訊並不難, BUMP的作法是將地理相關的資訊例如IP, GPS座標等等資訊傳送到Server, 藉以判定是哪兩台做互碰的動作, 我想同一個原理應該可以用來協助建立一個地理上的local network, BUMP是用於兩台不同device之間, 但同一個原理也應該適用來建立一個這樣的network
How?
剛在回家路上把想法畫了一個簡單的架構圖
這是一個大體上的架構, 應該還有很多細節, 比如說像是notification when join network等等
應用?
想到的應用像是file/data sharing, gaming network, data sync between different devices, chat room等等...
這只是一個簡單的想法而已, 還沒去想得很完整, 也還沒想到是不是有啥缺陷
今天跟人討論到關於Background update相關的問題, 這個議題一直是看似簡單(反正就是在backgroud抓資料), 但實際上很複雜也很難做的好
剛剛又拿了今年Google IO的Android protips這session的投影片複習了一下, 這個session裡剛好也有提到相關的內容, 就順便拿來借題發揮一下
為什麼要做background data update? 無非是 - Being Fresh
原本投影片上有三點, 我簡化成兩點, 是我覺得2,3其實可以歸為同一類(把位置當成是一種資料來看), 對於資料導向的應用程式來說, 是提供user一個好的使用體驗的方式, 因為大部分的資料都在背景幫你先預取回來了
另外我再多加一點: 需要提供使用者有新資料通知(Notification)時, 如新郵件, 新回覆之類的
但其實在移動裝置上, 要實現這樣的東西, 其實考量點並不只是抓取資料這麼簡單, 移動裝置通常意味著有較少的資源(運算能力, 記憶體, 儲存空間等等), 可能有限的且昂貴的網路環境(lower bandwidth, high data rate), 以及有限的電量(battery life)
第一點, 在現在高端手機的硬體競賽之下, 移動裝置其實已經漸漸的不比PC, Notebook來的差了, 雙核甚至四核的CPU, 更多的RAM, 儲存空間或許還有點距離, 不過也是越來越大, 這點, 變成比較不是問題, 更多的資源意味著可以容納更多的事情一起進行, 包含background update, 但相對的也意味的, 越來越耗費電源, 現行的電池科技並未進步到可以提供這麼大量的消耗, 因此移動裝置可以使用的時間會因此越來越短, 也會影響到整體的實用性
至於網路環境方面, 台灣的3G收費還不算貴, 多則不到一千就可以擁有無限制的data rate (吃到飽), 但並不是所有的地方都擁有這樣的環境, 很多國家, 資料總額還是有上限, 雖然大多已經相當的夠用了, 但多餘的資料抓取, 可能還是會變成無形中在偷使用者的荷包, 再者, 雖然電信商在智慧型手機流行的今天, 提供更多資料型的資費方案可選擇, 但大部分的電信商並沒預算好由於智慧型手機所帶來的網路流量, 有些電信商本身的infrastructure並不好, 越來越多的資料流量反而造成網路負擔不起
因此, 針對background update這類的設計, battery life跟資料量就是很重要的考量點
在這份投影片中提到"When is the best time to update your app's data":
這兩點, 主要還是都是針對電力的角度
根據過去做的經驗, 這樣其實並不是很夠, 在Android上允許很多background processes, 這有時來說是種災難, 每個processes可能都要此起彼落的起來抓取資料, 就算還有電源, 還是會加速電力的消耗, 即使是接著電源, 也可能會導致充電效率變低, iPhone 4其中一個讓我最印象深刻的是充電效率, 其實不只是電源要能夠持久, 充電效率高也是很重要的, 那代表user可以花比較少的時間回復到他正常使用的狀態
在"Monitor device state to vary refresh rate"裡面有更進階的提到幾點:
基本上這幾點都是很實用的設計, 不過, 真正實行起來會發現, background update的學問可能還比這多很多, 例如上面所說充電的問題, 也就表示說, 並不是充電時多抓點東西就是好事, 而且多抓點東西也表示需要消耗更多的網路頻寬, 撇開資費和電信商的頻寬不說, 當user如果正在使用網路, 比如說瀏覽網頁, 看影片, 這時候如果背景也在狂抓取資料, 就有可能影響到user在前景的使用
我覺得, 還有更根本的問題, 比如說, 到底是要啥時抓, 多久抓一次資料才足夠, 要抓多少資料才足夠, 抓資料的次數越頻繁, 抓取的資料量越多, 代表裝置要耗費更多原本可以休息的時間來處理, 這方面可能得從整體設計面來考量, 先分析出有哪些資料需要background update, 這些資料在遠端被更新的頻率有多高(藉由此來決定到底更新頻率多高才是合理), 每一種資料需要的即時性不同, 有些資料久久才會有變化, 有些資料則很快, 如果很久才變化的資料, 沒事就去更新, 不但耗電, 而且浪費資料頻寬, 甚至這些資料你有沒在背景更新, 使用者也不會有任何感覺, 另外一個是資料量的問題, 如何縮減傳輸的資料量, 一方面是節省頻寬, 更重要的是節省每次抓取資料的時間, 這樣耗費的電量也才可以更少
iOS4上雖然也允許了Background task, 但它的限制就高上很多, 很多需要做背景更新的, 還是透過push來達成居多, 不過push的方式在某方面來說可以減少不必要的update(比如說, 如果資料沒更新的話, pull的方式還是會上server去抓, push的方式則無這種無意義的浪費), 但設計不好的話, 其實也是會造成同樣的問題的....
