October 30, 2006
++LC-A+++++++++++++++++++++++++++++++
October 29, 2006
Sony GPS-CS1 使用感
Nikon 的高階 DSLR 在很早就引入了 GPS 的支援,在它的中高級機種上,可以外接 GPS 器,在拍攝照片的同時,相機便會把所處的全球座標位置同步紀錄在照片當中,這項功能在以前對專業攝影師相當有幫助,例如一些專業的生態攝影師或者風景攝影家,可以靠這些座標資訊整理照片,也可以在多年後仍能夠回到原地拍照。不過很可惜的是,Nikon 在後續的機種中並沒有繼續加強這個功能,功能仍是在,但是存在著很多不便,像是他只支援 RS232 接頭的 GPS 裝置,目前這種裝置比較難找到,有也比較貴,此外還要另外接一條 Nikon MC-35 訊號線,這訊號線除了不便宜外,在台灣也不太容易買到,所以網路上可以找到不少文章都是在討論如何改裝,透過藍牙或是改線來讓 GPS 接收器接上相機,或者如何透過熱靴從相機偷電,不過對於怕麻煩的我來說,想到要改裝一堆東西就頭大。有時候我會很納悶,Nikon 的相機都支援 Wireless 了,怎麼會沒想到用藍牙去支援 GPS 呢?畢竟現在多數的 GPS Mouse 都是藍牙訊號。
Nikon MC-35 "借電"學與自製 RS-232 GPS 連接線
Nikon D200 與 GARMIN 60CSx 異國聯姻
或許 Nikon 沒注意到一般使用者對於 GPS 與相機的結合也會有興趣,不過 Sony 注意到了。Sony 用另外一種方式來結合 GPS 以及數位相機,不再透過硬體與硬體的結合,而是由軟體來整合。前不久 Sony 就推出了 GPS-CS1 這個產品,他標榜的就是在拍攝照片的同時,利用 CS1 記錄當時的位置,等到回家後,再透過軟體從 CS1 中下載座標位置,並由該軟體自動比對數位照片的時間與座標位置記錄時的時間,便可以知道該照片拍攝時的位置了,不再需要透過一堆線將兩台機器結合在一起,而且適用於大部分的數位相機,即使是非 Cybershot 的相機也可以使用,例如我現在就是用我的 Nikon D200 跟他搭配。
我是剛好在禮拜五下班前收到包裹,正好趁著週末假日出去玩時試用,真感謝郵差先生及時送達。底下是我禮拜六去「朱銘美術館」參觀遊玩時一路上的紀錄,GPS-CS1 所記錄下來的 log 檔可以直接上傳到 GPS Visualizer 網站,由該網站幫妳描繪在 Google Maps 上,相當方便,第一張圖是路線圖,我從台北景美出發,沿著二高到基隆金山,再到朱銘美術館。
...繼續閱讀
Nikon MC-35 "借電"學與自製 RS-232 GPS 連接線
Nikon D200 與 GARMIN 60CSx 異國聯姻
或許 Nikon 沒注意到一般使用者對於 GPS 與相機的結合也會有興趣,不過 Sony 注意到了。Sony 用另外一種方式來結合 GPS 以及數位相機,不再透過硬體與硬體的結合,而是由軟體來整合。前不久 Sony 就推出了 GPS-CS1 這個產品,他標榜的就是在拍攝照片的同時,利用 CS1 記錄當時的位置,等到回家後,再透過軟體從 CS1 中下載座標位置,並由該軟體自動比對數位照片的時間與座標位置記錄時的時間,便可以知道該照片拍攝時的位置了,不再需要透過一堆線將兩台機器結合在一起,而且適用於大部分的數位相機,即使是非 Cybershot 的相機也可以使用,例如我現在就是用我的 Nikon D200 跟他搭配。我是剛好在禮拜五下班前收到包裹,正好趁著週末假日出去玩時試用,真感謝郵差先生及時送達。底下是我禮拜六去「朱銘美術館」參觀遊玩時一路上的紀錄,GPS-CS1 所記錄下來的 log 檔可以直接上傳到 GPS Visualizer 網站,由該網站幫妳描繪在 Google Maps 上,相當方便,第一張圖是路線圖,我從台北景美出發,沿著二高到基隆金山,再到朱銘美術館。
...繼續閱讀
October 25, 2006
My flickr viewer
國內的 Album Service Provider 如 wretch 或者 xuite 等,大部分長的都很像,就像是 gallery 系統一樣,中間一張小圖,下面一串縮圖,這樣的設計沒什麼不妥,看的人進到這個 Album,多數不會只看一張圖就走,通常會順著底下縮圖一張一張的點下去,所以在底下放上前後張縮圖操作起來也順暢。不過我常常納悶,為什麼是放下面?螢幕多半是長方形,左右較寬,放在旁邊不是可以讓畫面有比較好的效果嗎?而且每次點下一張時,就必須要等待頁面重載,圖檔慢慢顯示,這很煩人,當妳在看這張圖檔時,我相信有相當大的機率會點下一張,為什麼不先偷偷下載,讓瀏覽器去暫存,等到妳看下一張時圖片會立刻出現,這樣不是順暢許多,只不過缺點是頻寬的浪費,不過我順暢的瀏覽與頻寬的利用應該是可以取得一個平衡點。
因為這樣我嘗試照著我的想法去做個 prototype 出來,利用一些 AJAX 的技巧,以及搭配一些 Javascript library 跟 Flickr API 去做出這個 gallery prototype 來。

我把 photostream 擺在右手邊,圖檔縮圖透過 phpFlickr 去抓出來,當妳往下拉動 scrollbar 時會動態去抓更多圖檔出來。如果妳點了其中一張圖,就會顯示在左邊的畫面中。而且在載入縮圖的同時,大圖的圖檔也預先載入到瀏覽器的快取中,所以當妳點選時,有很大的機會圖片會很快的顯示出來。
這個 prototype 還有很多缺點,不過最近心灰意冷,所以不想改了,大家隨意看看吧。
因為這樣我嘗試照著我的想法去做個 prototype 出來,利用一些 AJAX 的技巧,以及搭配一些 Javascript library 跟 Flickr API 去做出這個 gallery prototype 來。

我把 photostream 擺在右手邊,圖檔縮圖透過 phpFlickr 去抓出來,當妳往下拉動 scrollbar 時會動態去抓更多圖檔出來。如果妳點了其中一張圖,就會顯示在左邊的畫面中。而且在載入縮圖的同時,大圖的圖檔也預先載入到瀏覽器的快取中,所以當妳點選時,有很大的機會圖片會很快的顯示出來。
這個 prototype 還有很多缺點,不過最近心灰意冷,所以不想改了,大家隨意看看吧。
October 24, 2006
innerHTML 與 createElement 的差異
查了一下網路上有關於 innerHTML 與 createElement() performance 的比較,都是顯示 innerHTML 有較好的 performance ,這跟我以前的印象有蠻大的差距,我一直都以為 innerHTML 會較差,直接 createElement() 以及 appendChild() 會有比較好的 performance,不過既然測試出來的數據都是這樣,看來也應該如此。
innerHTML 的優點是容易實做,程式碼容易維護,再加上 performance 較好,那麼我真的不知道使用 createElement() 跟 appendChild() 的理由為何了。
感謝 midoli 糾正我上一篇文章,我一時不查,以原本的想法觀念,寫了一篇錯誤的文章出來,看來作學問還是要秉持著嚴謹的態度。
innerHTML 的優點是容易實做,程式碼容易維護,再加上 performance 較好,那麼我真的不知道使用 createElement() 跟 appendChild() 的理由為何了。
感謝 midoli 糾正我上一篇文章,我一時不查,以原本的想法觀念,寫了一篇錯誤的文章出來,看來作學問還是要秉持著嚴謹的態度。
October 16, 2006
[AJAX Pattern] Amazon A9 Search
上次在 Amazon 的 A9 Search 看到一個很有趣的 AJAX 應用,看了就很想自己實作看看,實際上也不困難,如果瞭解 AJAX 的原理,Javascript event 處理等就能寫出來了,所以在這裡介紹給大家看看。
[Amazon A9 Search]
傳統的搜尋引擎如 Google 或 Yahoo 等,在將搜尋結果丟出來後,會以分頁來顯示這些結果,使用者想要找的結果如果不是在第一頁的話,就會一頁接著一頁向後找尋。這種作法也沒什麼不對,很直覺,但是我看了 A9 的用法後,我反而覺得 A9 的作法更為實際,更加直覺。A9 怎麼操作的? Scrollbar !

A9 會先丟出前幾筆的結果於網頁上,例如排名前 20 筆,但是當妳使用 Scrollbar 往下拉動時,更多資料就會源源不絕的顯示出來,同時妳也會發現左邊的 Scrollbar 越來越小,代表資料量越來越多。用寫的來描述這行為實在很難,妳可以上 http://www.a9.com ,透過實際操作便可瞭解。為什麼說他更直覺呢?因為如果第一次沒看到你想要的資料時,同時妳又看到 scrollbar 在旁邊,直覺上的操作就是會去拉動 scrollbar ,如同妳在 google 的搜尋結果中,也會拉動瀏覽器視窗的 scrollbar 來看底下的資料,如果沒有再點下一頁,所以既然都在拉動 scrollbar 了,何不在同時也去抓新的資料,所以我說他的操作方式更加直覺。
[怎麼做?]
假設我們想讓內容顯示在一 DIV 區塊中,藉由使用者拖拉 scrollbar 來動態增加顯示內容的話:
第一步、於 DIV 區塊上顯示 scrollbar
這很簡單,只需要透過簡單的 style 屬性設定即可,前提就是妳必須先設定 DIV 區塊高度,並設定屬性 overflow:auto ,例如:
第二步、攔截使用者 scrolling 動作
檢而言之,攔截該 DIV 區塊的 onscroll 事件,例如:
第三步、呼叫 AJAX,向伺服器要新資料,例如:
第四步、取得 AJAX 回傳結果,也就是上述程式碼中的 showResponse 函式:
[Refactoring]
我們將這樣的概念稍微把他物件化,讓它可以重複被使用,而且增加一些保護措施。
這裡頭有個 ScrollNav 物件,就是將這些東西都包進去了,此外,於 checkScroll 函式中會檢查 event 是否被重複攔截,以及檢查目前 scrollbar 是否被拉動至最下方,唯有 scrollbar 被拉到最下面時,我們才向伺服器要求更多的資料,避免頻寬資源的浪費。scrollTop 跟 scrollHeight 都是內建的屬性,scrollTop 代表目前顯示的 view 距離最上方多少有 pixel,而 scrollHeight 則代表內容 view 的總長,同樣是 pixel,當妳資料越塞越多時,scrollTop 跟 scrollHeight 都會跟著增加,如果要判斷 scrollbar 是否為拉到最下方,最簡單的方法便是計算 scrollTop 和 DIV 區塊的高度總長是否等於 scrollHeight 即可。
至於在 showResponse() 函式中,我們會在每次抓到的新資料中都塞進個「Fetching ...」的字眼,代表目前正在抓取更多資料,這是一種小技巧,就像在大部分的 AJAX Pattern 中都可以看到的 Loading 字眼,妳也可以用個 gif 動畫來取代,只不過每次取得新資料時,必須將上一個「Fetching ...」移除。
想看結果嗎?請看 Demo 。裡頭有兩個 DIV 區塊,左邊的 DIV 區塊所 request 的 PHP 檔執行較快,而右邊的每次都會 sleep 5 秒鐘,所以感覺起來比較慢,拉動兩個 scrollbar 妳便可以發覺兩者間的不同。
[其他問題?]
目前這個範例還有些存在性的問題:
[這可以應用在哪?]< br/> 我想這些概念,實作都是很簡單,重要的是妳有沒有創意,有沒有想到這些 idea,以及怎麼應用在妳的網頁中,這我想應該讓妳自己去想想看,不過我覺得可以應用在某些功能上,例如 blog 留言版,留言版並不是每個人都想看,如果留言眾多時,每次都將留言塞到使用者的瀏覽器上也不甚合理,如果透過類似的方法,先讓使用者看到最新的留言,如果想繼續看下去,只需要拉動 scrollbar 即可。應該還可以想出更多有趣的應用,不過還是大家自己想想看吧。
[Amazon A9 Search]
傳統的搜尋引擎如 Google 或 Yahoo 等,在將搜尋結果丟出來後,會以分頁來顯示這些結果,使用者想要找的結果如果不是在第一頁的話,就會一頁接著一頁向後找尋。這種作法也沒什麼不對,很直覺,但是我看了 A9 的用法後,我反而覺得 A9 的作法更為實際,更加直覺。A9 怎麼操作的? Scrollbar !

A9 會先丟出前幾筆的結果於網頁上,例如排名前 20 筆,但是當妳使用 Scrollbar 往下拉動時,更多資料就會源源不絕的顯示出來,同時妳也會發現左邊的 Scrollbar 越來越小,代表資料量越來越多。用寫的來描述這行為實在很難,妳可以上 http://www.a9.com ,透過實際操作便可瞭解。為什麼說他更直覺呢?因為如果第一次沒看到你想要的資料時,同時妳又看到 scrollbar 在旁邊,直覺上的操作就是會去拉動 scrollbar ,如同妳在 google 的搜尋結果中,也會拉動瀏覽器視窗的 scrollbar 來看底下的資料,如果沒有再點下一頁,所以既然都在拉動 scrollbar 了,何不在同時也去抓新的資料,所以我說他的操作方式更加直覺。
[怎麼做?]
假設我們想讓內容顯示在一 DIV 區塊中,藉由使用者拖拉 scrollbar 來動態增加顯示內容的話:
第一步、於 DIV 區塊上顯示 scrollbar
這很簡單,只需要透過簡單的 style 屬性設定即可,前提就是妳必須先設定 DIV 區塊高度,並設定屬性 overflow:auto ,例如:
<div id="content" style="width:490px;height:490px; overflow: auto">當妳於 DIV 區塊中的內容超過 DIV 高度時,瀏覽器便會於右邊出現 scrollbar。
.... 妳想要顯示的內容。
</div>
第二步、攔截使用者 scrolling 動作
檢而言之,攔截該 DIV 區塊的 onscroll 事件,例如:
// 注意:以下程式碼使用 prototype.js 語法checkScoll 函式便是我們想要處理 scrolling event 的函式。
$('content').onscroll = checkScroll;
第三步、呼叫 AJAX,向伺服器要新資料,例如:
// 注意:以下程式碼使用 prototype.js 物件
var opts = new Object;
opts.parameters = 'page=' + page_num;
opts.onComplete = showResponse;
var ajax = new Ajax.Request (url, opts);
page_num ++;
第四步、取得 AJAX 回傳結果,也就是上述程式碼中的 showResponse 函式:
function showResponse(origReq) {看,這樣就完成了!超簡單!所以來 re-factoring 一下。
$('content').innerHTML += origReq.responseText;
}
[Refactoring]
我們將這樣的概念稍微把他物件化,讓它可以重複被使用,而且增加一些保護措施。
function showResponse(origReq) {
var nav = $(this.nav.contentID);
var last = nav.lastChild;
while (last.nodeName != 'DIV') {
last = last.previousSibling;
}
nav.removeChild (last);
nav.innerHTML += origReq.responseText;
nav.innerHTML += '<div style="background: #AAAAAA;">Fetching ... </div>';
this.fetching = false;
}
function ScrollNav(contentID, url) {
this.contentID = contentID;
this.contentObj = $(contentID);
this.contentObj.nav = this; // 記錄目前物件,給 checkScroll 函式使用
this.fetching = false;
this.scrollTop = this.contentObj.scrollTop; // 記錄一開始 scrollTop
this.scrollHeight = this.contentObj.scrollHeight; // 記錄一開始 scrollHeight
this.url = url;
this.idx = 0; // page number
this.checkScroll = function() {
if(this.nav.scrollTop == this.scrollTop)
return;
if (this.fetching)
return;
this.nav.scrollTop = this.scrollTop;
if (this.scrollHeight == parseInt(this.style.height) + this.scrollTop) {
var opts = new Object;
opts.parameters = 'page=' + this.nav.idx;
opts.onComplete = showResponse.bind(this);
var ajax = new Ajax.Request(this.nav.url, opts);
this.fetching = true;
this.nav.idx ++;
}
}
// 攔截 onscroll event
this.contentObj.onscroll = this.checkScroll;
}
function init() {
var nav = new ScrollNav('content', 'scroll_test.php');
var nav = new ScrollNav('content2', 'scroll_test2.php');
}
這裡頭有個 ScrollNav 物件,就是將這些東西都包進去了,此外,於 checkScroll 函式中會檢查 event 是否被重複攔截,以及檢查目前 scrollbar 是否被拉動至最下方,唯有 scrollbar 被拉到最下面時,我們才向伺服器要求更多的資料,避免頻寬資源的浪費。scrollTop 跟 scrollHeight 都是內建的屬性,scrollTop 代表目前顯示的 view 距離最上方多少有 pixel,而 scrollHeight 則代表內容 view 的總長,同樣是 pixel,當妳資料越塞越多時,scrollTop 跟 scrollHeight 都會跟著增加,如果要判斷 scrollbar 是否為拉到最下方,最簡單的方法便是計算 scrollTop 和 DIV 區塊的高度總長是否等於 scrollHeight 即可。
至於在 showResponse() 函式中,我們會在每次抓到的新資料中都塞進個「Fetching ...」的字眼,代表目前正在抓取更多資料,這是一種小技巧,就像在大部分的 AJAX Pattern 中都可以看到的 Loading 字眼,妳也可以用個 gif 動畫來取代,只不過每次取得新資料時,必須將上一個「Fetching ...」移除。
想看結果嗎?請看 Demo 。裡頭有兩個 DIV 區塊,左邊的 DIV 區塊所 request 的 PHP 檔執行較快,而右邊的每次都會 sleep 5 秒鐘,所以感覺起來比較慢,拉動兩個 scrollbar 妳便可以發覺兩者間的不同。
[其他問題?]
目前這個範例還有些存在性的問題:
- 別吃光 browser 的記憶體了。塞資料時要設立停止點,別一直狂塞,吃光妳瀏覽器的記憶體了。
- 不一定要拉動到最下方才開始抓取資料,可以在使用者的 scrollbar 接近最下方時,便向伺服器要求新資料,可以達到更順暢的操作。
[這可以應用在哪?]< br/> 我想這些概念,實作都是很簡單,重要的是妳有沒有創意,有沒有想到這些 idea,以及怎麼應用在妳的網頁中,這我想應該讓妳自己去想想看,不過我覺得可以應用在某些功能上,例如 blog 留言版,留言版並不是每個人都想看,如果留言眾多時,每次都將留言塞到使用者的瀏覽器上也不甚合理,如果透過類似的方法,先讓使用者看到最新的留言,如果想繼續看下去,只需要拉動 scrollbar 即可。應該還可以想出更多有趣的應用,不過還是大家自己想想看吧。
October 15, 2006
October 14, 2006
Jay-Z
最近來台灣開演唱會的 Jay-Z 資料。
節錄部分:
資料來源 ptt hip-hop 版,全文: [歌手]:Jay-Z
LP 與 Jay-Z 於 Collision Course 的合作:
...繼續閱讀
節錄部分:
Jay-Z, 他或許是美國饒舌音樂圈裡, 最具影響力的饒舌歌手之一, 除了一些商業面賦予
的附加價值, 包括五度奪得葛萊美獎…估計超過三億美金的身價…專輯張張白金唱片的數
字銷售量…榮登2006年時代雜誌一百位全球最具影響力的人之一…經營唱片公司, 旗下歌
手各個打進告示排行榜…橫跨體育事業(最有名的就是他也是NBA紐澤西籃網隊的股東)…
目不暇給的連續印象衝擊下, Jay-Z達成了許多不可思議的成就。
原名Shawn Corey Carter的Jay-Z, 生於1969年的12月4日, 成長於紐約布魯克林區惡名昭
彰的Marcy Houses貧民窟, 12歲時父母離異, 小Carter便由母親撫養長大, 在Jay-Z以自
己生日為名的歌曲December 4th有也提到, 母親Gloria Carter甚至也參與歌曲中的一段
唸白…總喜歡晚餐時在餐桌上敲敲打打胡亂製造節奏的小Carter, 被母親發現他對音樂的
天份, 因而買了一台錄音機送給小Carter, 開啟了他的音樂之路…但是另一方面, Jay-Z
的學生之路倒是很不順遂, 據說是為了討生活而在街頭販毒遭到逮捕, 導致Jay-Z高中沒
畢業就被退學了, 這一段黑暗的遭遇也成為Jay-Z刻劃冷血街頭的記憶來源之一。
從一台小小的boombox到慢慢練習即興饒舌, 壓韻技巧, 小Carter慢慢在鄰里之間有了自
己的綽號『Jazzy』(Jay-Z的前身), 他的饒舌事業一直到他參與一場即興饒舌擂台比賽才
突飛猛進, 當時與他對擂的對手是一個叫Zai的, Jay-Z很快的痛宰了Zai, 贏得滿堂采,
也贏得了許多唱片公司的青睞, 獲得跟一些饒舌歌手合作的機會(包括已故哈林區地下傳
奇Big L)。
資料來源 ptt hip-hop 版,全文: [歌手]:Jay-Z
LP 與 Jay-Z 於 Collision Course 的合作:
...繼續閱讀
October 10, 2006
我哥的小豆子
我哥的小 baby 出生, 10/3 天秤座,提早出生,體重也比一般嬰兒輕了許多,只有 2500 公克,所以也在醫院住了特別久,連中秋都是在醫院裡度過。上週四回家前順道到新竹探望了這個小姪子,那時候都還不能抱,只能透過玻璃觀看,好像在動物園的可愛動物館一樣,不過看到小小的新生命,又是跟自己有關係的親人,感覺畢竟是不同。
看看小豆子的照片吧:
...繼續閱讀
看看小豆子的照片吧:
...繼續閱讀
Google 買下 Youtube 以及 Web2.0 經營模式思考
今天除了「天下圍攻」外,網路上最大的消息就是 Google 買下了 Youtube,一舉躍升成為最大的網路影網站,這應該不意外,Youtube 年年燒錢,而且還不是普通的燒,根本是拿金條去融,單靠微薄的廣告收入是難以支撐一個流量如此之大的網站,所以 Youtube 的算盤中,應該早算好被併購的一天,被誰併購,被花多少併購,才是問題,而最後出線的金主就是「咕背背」。Google 已經有 Google Video service 了,花了錢買 Youtube 應該只是單純要增加流量,Google Video 有營業模式,多了流量多少可以刺激買氣,增加此方面的收入,也可以開創多方獲利模式,與各家軟硬體公司合作,推出各種服務,不過買了之後,要怎麼整合兩者,要怎麼搞定版權問題都是 Google 要開始煩惱的問題。
但是說實在的,看到這則新聞,我自己卻有些不一樣的感受,看這一兩年來,Web2.0 的起來就好像以前網路達康時代,大家都很看好,網路創業風又起,各式各樣的服務競相冒出來,但是呢?!大家似乎都沒記起達康泡沫化的教訓,為什麼會泡沫化?不就是缺乏良好的獲利模式,不管是以前的 .com 公司,還是現在的 Web2.0,一個網站要怎麼獲利?大家首先先想到的就是「廣告」,但是真能靠廣告賺錢的網站少的可憐,而且能靠廣告賺到大錢的就只有 Google,因為他很聰明的利用全世界網站幫他刊登廣告。但是除了廣告外,還有什麼獲利方式,會員?像無名小站一樣?不過要提供會員制,相對的你就必須要提供更好的服務來留住會員,要提供更好的服務通常代表著 Cost 也會增加。雖然相對於 .com, Web2.0 網站所需要的 Cost 較低,但是如果缺乏有效的獲利模式,沒有實際的經營模式, .com 與 Web2.0 的差別只是燒錢的快慢而已。
如果沒辦法賺錢,就只好等別人來買,咬緊牙關撐著,巴望著那些在前面赫赫有名的網站多關注你一點,不過這種機會可遇不可求,而且你不會覺得很可悲嗎?你的心血創意只是等著別人來買,而不能靠自己手成功(或許有些人不會這樣想,有人買就該偷笑,賺個七億也不錯啊)。
我很歡迎 Web2.0 的到來,我也很喜歡用網路上一些服務,自己也常常有滿腦子的 idea 想去實踐,但是有時候我很怕 Web2.0 不是機會只是陷阱,終會成泡沫。今天除了看到這則新聞外,也看到了下面這篇文章,他提到:「但是當我們看著這熱鬧的 Web 2.0 熱潮之時,或許也該是時候反思 - 如果 Web 2.0 企業只能透過併購當做出場機制,而不能透過自身的商業模式獲利時,這股熱潮將如何結尾呢?」,值得深思。
Google 併購 YouTube ? Web2.0 最好的出場機制是併購?
但是說實在的,看到這則新聞,我自己卻有些不一樣的感受,看這一兩年來,Web2.0 的起來就好像以前網路達康時代,大家都很看好,網路創業風又起,各式各樣的服務競相冒出來,但是呢?!大家似乎都沒記起達康泡沫化的教訓,為什麼會泡沫化?不就是缺乏良好的獲利模式,不管是以前的 .com 公司,還是現在的 Web2.0,一個網站要怎麼獲利?大家首先先想到的就是「廣告」,但是真能靠廣告賺錢的網站少的可憐,而且能靠廣告賺到大錢的就只有 Google,因為他很聰明的利用全世界網站幫他刊登廣告。但是除了廣告外,還有什麼獲利方式,會員?像無名小站一樣?不過要提供會員制,相對的你就必須要提供更好的服務來留住會員,要提供更好的服務通常代表著 Cost 也會增加。雖然相對於 .com, Web2.0 網站所需要的 Cost 較低,但是如果缺乏有效的獲利模式,沒有實際的經營模式, .com 與 Web2.0 的差別只是燒錢的快慢而已。
如果沒辦法賺錢,就只好等別人來買,咬緊牙關撐著,巴望著那些在前面赫赫有名的網站多關注你一點,不過這種機會可遇不可求,而且你不會覺得很可悲嗎?你的心血創意只是等著別人來買,而不能靠自己手成功(或許有些人不會這樣想,有人買就該偷笑,賺個七億也不錯啊)。
我很歡迎 Web2.0 的到來,我也很喜歡用網路上一些服務,自己也常常有滿腦子的 idea 想去實踐,但是有時候我很怕 Web2.0 不是機會只是陷阱,終會成泡沫。今天除了看到這則新聞外,也看到了下面這篇文章,他提到:「但是當我們看著這熱鬧的 Web 2.0 熱潮之時,或許也該是時候反思 - 如果 Web 2.0 企業只能透過併購當做出場機制,而不能透過自身的商業模式獲利時,這股熱潮將如何結尾呢?」,值得深思。
Google 併購 YouTube ? Web2.0 最好的出場機制是併購?
LOMO 老母雞 LCA 重出江湖,這次由俄+中國製造,純手工製作,增加了幾個新功能:








![Syndicate RSS feed [Syndicate this site]](http://pics.yamedia.tw/images/rss2.gif)
![Syndicate ATOM feed [Syndicate this site]](http://pics.yamedia.tw/images/atom.gif)
