顯示具有 web2.0 標籤的文章。 顯示所有文章
顯示具有 web2.0 標籤的文章。 顯示所有文章
等的好久啊...

以前 Yahoo Mail 剛推出 API 的時候,很多人都在紛紛詢問,到底要怎麼撈通訊錄的名單呢?當時的官方說法是,根本不提供這個 API。但是像是 flickr 的 friends finder 就很明顯有內部的 api 可以使用,也因此被不少人詬病說開放只開一半。

但是這方面的需求始終不少,所以很多人都用一些旁門左道的方式來撈 - 比方說把使用者的寄信匣中的收件人撈一次,可以得到類似通訊錄的效果。

現在開始終於不用走這些旁門左道啦。今天看到,Yahoo Addressbook 終於也開放了 API 可以讀取。以後如果要讓 user 互相匯入匯出使用者資料就方便多囉。

雖然是這樣,但是公告上面每天 5000 個 queries 還是實在有點小氣。大一點的網站,像是 LinkedIn 提供的功能,每個小時就不只 5000 個 queries 了吧?不過雖然小氣了點,至少隔了一年多 API 總是開出來了,也算是踏出了好的開始啊。

原始 blog post 在這邊
今天看到消息Amazon EC2 已經開始提供兩個新的 instance type,給 CPU 需求量較大的人使用。新的 instance type 分別是:
  • $0.2/hour,1.7G ram,5 個 EC2 computing units,32bit platform
  • $0.8/hour,7G ram,20 個 EC2 computing units,64bit platform
如果 application 是 CPU-bound 的話,也許新種的 instance type 會比較合用。不過我倒是比較希望看到,只要 $0.05/hour 的 mini-instance,這樣對 prototyping 比較合適 :p

Anyway,EC2 網站上也已經公告新的 instance type 了。
我還滿好奇的,NetApp 怎麼還沒倒啊?

大家都知道,Amazon 提供的 webservices 搭配起來可以多強多猛。EC2 + S3 + SQS + SimpleDB 簡直就是無敵。但是問題在 EC2 的 instance 上面,沒有可靠的儲存裝置可以使用。S3 雖然很保險,可是操作 S3 沒有辦法像操作 filesystem 那樣方便,而 S3 的 latency 也不允許一層 FUSE 的介面操作。

上個月 Amazon 公佈說,將來會開始支援 persistence storage 了。你可以動態要求任意大小的單位容量 - 小從 1 GB 大到 1TB - 而且還不限制單位數目。也就是說你可以輕輕鬆鬆要好幾個 1TB 的儲存單位,放置你想放的東西。還支援 snapshot 備分到 S3 上面,達到更強固的備分效果。Amazon 的 Jeff Barr 也在他們官方的 blog 上面貼了一篇簡單教學,告訴你應該怎麼操作。

聽起來很棒對不對?真的是很棒。可惜現在 API 還沒有正式上線。這段時間如果覺得需要 persistent storage 的人,就只能自己硬幹了。... 可是我沒想到這年頭還真的有人這麼熱血!XD

今天在這邊看到一篇文章,是一篇完整的 howto,用 DRBD、LVM、Heartbeat 等元素組出來一套建構在 EC2 上面的「persistent storage」。雖然說是 persistent 但是畢竟不如 Amazon 官方製作的一般,可以完全獨立於 EC2 instance 以外。但是大部分功能都已經很齊備了,諸如 failover、redundancy、snapshot 等功能一應俱全。雖然建構起來頗費工夫,但是對於已經需要上線運作 (換句話說沒空等 Amazon 官方 release 的 solution)、又很擔心資料完整性的人,倒是很適合的。

話說回來,等到 Amazon EC2 官方版的 persistent storage 上線以後,還有多少人要買 NetApp?XD 這年頭買 NetApp,根本已經完全不符合成本效益了。

Gmail uploader 好像很糟...

今晚拿了 Google Email Uploader 想來把一些以前的信件往 Google Application 上面丟,沒想到跑起來慢的要死不說,居然還有這個 screenshot:

gmail_uploader

473 封信裡面舊友 829 個 error。這還滿強的嘛... @_@
傳言已久的 flickr video 終於推出了。雖然如此,但是只允許 90 秒長度的限制、只有 pro member 能夠使用,加上沒有類似 jumpcut 編輯影片的功能,看來影響力十分有限。

但是對我來說,保存自製的 memorable videos 剛剛好合適。也許這才是 flickr 的用意吧。隨文附貼一個當年 HeatoN 小槍局逆轉、一人幹掉強敵 4k 一整隊的經典場面。大家可以看看影片撥放的效果。



另外,我抱怨已久的 flickr uploadr,也終於推出新版了,當然新的 uploadr 也支援影音。不過我還沒測試中文問題到底這版修好了沒... 試了這麼多版其實也沒什麼信心了 *_*

[Update] 看來 3.1 版終於修好了。
Amazon EC2 確實便宜大碗,但是之前最為人所詬病的,就是必須用 CNAME 或是 dyndns 的方式來指定 domain name。今天收到信,現在 Amazon 推新版的 EC2 API,終於提供了 static IP 的功能,還讓人可以自由選擇自己的 instance 要開在哪個機房的 cloud 中。

雖然機房位置可以選的並不多,static IP 也只提供一組,不過已經是不小的進步了。

詳細資訊可以看:

flickr 邁入 farm4 了!

新傳上 flickr 的照片都會在 farm4 上面出現了。記得 flickr 沒多久前才破 20 億張照片,前幾天寫 blog 傳的照片編號就已經是 22 億多了。當時 flickr 每秒要接收三千多張新照片,不知道現在這個數字是多少?

不過話說回來,我還是希望 flickr 先把 uploadr 搞的好一點再說。畢竟離 3.0.5 版推出也好一陣子了,可是狀況還是一樣糟,許多 bug 還是沒修好啊...

Anyway,這張是我第一張在 farm4 的照片,紀念一下 XD
IMG_7156
對 developer 來說,Amazon S3 解決了許多大量檔案儲存的問題。但是對一般 user 而言,如果只是要備份一些小東西,比較少有人特別寫 script 來專門做備份、monitor 自己有哪些檔案。今天亂翻資料的時候,倒是看到一個 S3fox 的好東西。

S3fox 是一個 firefox 的 extension,可以在 firefox 理面瀏覽自己的檔案、拖拉上傳,也可以替你建立子目錄、進行目錄的 sync 來做備份。(開子目錄是 Amazon S3 不支援的 API,我猜是 S3fox 模擬出來的虛擬目錄吧...)

s3fox

對一般用戶來說,倒是滿好用的。

[Update 2008/03/02] 我還真是後知後覺,今天才知道 infiniteFTP 這種東西。看起來很好用啊...

Amazon SQS 調整定價

大概是受不了大家狂抽猛送了 XD

話說第一次看到 Amazon Simple Queue Service 的時候,發現他的計價單位是以傳送的 queue message 來計算,而不是以 request 數量。當時的直覺反應就是:既然這樣誰還要管什麼 messaging 架構?如果有多種 system 之間需要溝通,直接往 SQS 塞就好,其他都不用煩惱。反正另一邊只管狂 poll,不斷查詢有沒有給自己的新訊息就可以了 XD 反正查詢不用錢嘛!

Amazon 大概是受害甚深,現在公佈要「調降」價格了:以前是每 1000 個 message 算 $0.01 美金,現在變成每 10000 個 request $0.01 美金。換句話說,如果還是用老方式狂 poll amazon 的機器的話,用新的方案就會比較貴;如果自己乖一點,有適當的 backoff 機制的話,新方案或許就會比較便宜。

新的價格也已經 announce 在 SQS 官方網頁上了。不過這個消息公佈到定價調整之間沒有什麼空檔,倒是稍嫌過分了點。至少也該讓惡搞的人有點時間改程式嘛。論語也教我們,「不教而殺謂之虐」啊。

假降價之名,其實是在告訴大家「別再操我們的機器了!不要亂搞我們的服務!」
這也算是典型的以價制量吧 :p
話說 flickr 前陣子出了新版的 Uploadr 3.0,原本以為會替久未更新的 Uploadr 打一劑強心針。沒想到 forum 上面哀鴻遍野,而且我今天拿來用才發現原來根本不支援 multibyte!只要目錄結構裡面任何一個目錄或是檔名出現中文,Uploadr 就沒辦法成功讀到這張圖。

看了三頁,實在很訝異這麼明顯的問題推出一週後居然還沒有人反映,所以在 forum 上面簡單回報了一下。看看什麼時候會出新版修正吧...

這個 snapshot 是我拿來讀取「C:\Documents and Settings\All Users\Documents\My Pictures\範例圖片\Water lilies.jpg」會出現的樣子。因為目錄結構中有「範例圖片」,所以...

uploadr 3.0 doesn't support chinese filenames
explore page broken

圖、作者、統計資料、什麼都沒出來。不知道跟這陣子升級 stats 有沒有關係...

Amazon 推出 Simple DB

Amazon 快要一統江湖了。

剛剛一邊泡茶,一邊在 AWS 翻查 EC2SQS 的資料的時候,突然發現旁邊的 webservices 多了一個以前沒看過的 Simple DB... 愣了一下,腦海裡響著:「前陣子才在想 Amazon AWS 系列獨缺 DB 一塊,怎麼這麼快就補上來了?」馬上點下去看,發現原來確實是今天剛出的 Orz 果然早起的鳥兒有蟲吃啊...

話說 SimpleDB 不像 RDBMS 一樣支援那麼強大的 Query 方式,提供的是基本的 =、!=、<、>、<=、>=、STARTS-WITH、AND、OR、NOT、交集和聯集等查詢條件。但是好處是你不再需要一個經驗豐富的 DBA 來替你處理 DB schema 和 indexing,也不用考慮 scalability 和 load balancing,這些全部交給 amazon 煩惱就好。對於資料關聯不複雜、處理 database 經驗不足的開發者來說是不小的誘因。

不過話說回來,這個 SimpleDB 目前還在 limited beta 階段,白老鼠有限,不曉得還有沒有什麼怪地雷還沒被踩過。另一方面來說,目前的版本還是有些限制:每個人只能開 100 個 domain (可以把 domain 想像成 table),一個 domain 只能放 10G 的資料。然後每個 attribute (可以想像成 column) 最高只能 1024 bytes。最後,不論 10G 的限制有沒有達到,一個 domain 不能有超過 2500 萬個 attributes。

這對於真正希望 SimpleDB 替他解決 scalability 的人來說不是很好的消息。不過目前 SimpleDB 才剛推出,或許將來這些限制也會慢慢被降低。整體來說,SimpleDB 對於喜歡用 Berkeley DB 的 lightweight、不愛 MySQL 這種重量級大砲的人來說,倒是個很好的 solution。尤其 Berkeley DB 處理多台電腦 access 資料的 solution 不多,而且 SimpleDB 提供的功能遠比 Berkeley DB 強大。

看來,以後有志於 web startup 的人,根本不需要具備太多 scalability 的技巧。只要有一些 common sense,租一台 EC2,需要 storage 就用 S3,需要處理不同架構間的 IPC 就用 SQS,要存資料就放 SimpleDB... 你還需要些什麼?Amazon 根本就已經把 solution 都做好給你了。

不過,相對於 Amazon S3、Amazon EC2、Amazon SQS 的價廉物美來說,Amazon SimpleDB 的價格略嫌貴了一些,我想我應該會等他降價再來考慮看看吧。

[Update] 果然是 Limited beta,我想申請的時候居然跟我說:「The Limited Beta will be opened to the public in the next few weeks. We will contact you via e-mail when the beta program opens and a spot becomes available.」原來根本還沒開始賣啊?=_=
這標題有點繞口。不過這篇文章是翻譯 Paul Graham 的「Why to Move to a Startup Hub」。這幾天工作狂症狀再度發作,連睡覺都在工作,實在覺得這樣下去不好,應該轉換一下心情。所以把這篇文章拿來翻譯看看,如果有缺失的地方還請各位先進不吝指教。

另外,根據 Paul Graham 在這邊說的,他歡迎文章被翻譯成其他語言,但是希望能夠把譯文網址給他。但是我不知道他的聯絡方式。如果有的人,請讓我知道一下。感恩!

那麼,以下譯文開始。
在我上一次演講結束的時候,其中一個幹部立刻站上台來發表即席演說,反駁我的論點。這在以前是從未發生過的。我只聽他說了幾句話,不過我已經了解,我說的什麼讓他感到不滿了:「新創公司如果搬到矽谷去會表現的比較好。」

這場會談是辦在倫敦的。而大部分的聽眾似乎都是英國人。所以告訴他們應該搬到矽谷去聽起來就很帶有國家主義的味道;這個機車的美國人在跟他們說,如果想成功你們就得搬到美國去。

事實上我沒有看起來那麼「美國」。我雖然當時沒有說,但是我是在英國出生的。而就像猶太人也不忌諱說猶太笑話一般,我不覺得我跟英國人講話需要特別注意外交辭令用語圓融。

事實上,新創公司如果搬到矽谷表現的會更好的說法,跟國家也沒有關係。即使我在美國我也這樣對其他新創公司說。Y Combinator﹝譯註:該作者創辦的創投﹞每半年就從東岸換到西岸,而在東岸的運作總是到波士頓。而即使波士頓是美國﹝包括全世界﹞第二大的「創業聚集地」,我們也依然會跟新創公司說,你們最好搬到矽谷去。如果在波士頓這種情況成立,那在世界上其他任何一個角落都應該成立。

這和都市有關,而不是國家。

而且我想,我可以證明我是對的。甚至大部分人也都應該會同意。很少人會說,在哪裡開一家新公司根本無關緊要 ─ 等於是說在創業聚集地開公司不會比在一個小農業村莊裏面有優勢。大部分人都可以看出,在一個創業聚集地,各種創業的基礎建設都比較完備的地方,會有大量創業的知識累積、也會有眾多的創業家聚集,在這種地方創業會比較有幫助。如果你想說從倫敦搬到矽谷不會比較好,那等於是在說從英國農業小村莊搬到倫敦不會有幫助一樣。

而我們說都市的差別,是說等級的差別。每個知道的人都會說,矽谷的新創公司比波士頓好。而且在矽谷的新創公司也會比世界上任何一個地方好。

我知道我說這個話有點利益衝突的味道。而且新創公司如果搬來矽谷也可能會透過 Y Combinator。但是我們投資過的美國公司也都可以證明,我對他們說的話是一樣的。

當然,我並不是在說,每個新創公司都要搬到矽谷才能成功。只是如果所有其他條件都一樣,越好的創業聚集點會讓新創公司表現的更好。但是許多不一樣條件的考量可能都會有影響。我並不是說已經成家的創業者都應該舉家遷徙半個地球。這樣子對創業者的干擾可能更大。

移民面對的困難也是留在原地的一個好理由。處理移民問題就跟募資一樣,雖然不是最重要的事情,但是偏偏它就是會佔住你所有的注意力。新創公司沒辦法負擔多少這種注意力的分散。過去我們投資的一家加拿大公司,花了六個月仍然沒辦法順利搬來美國。最後他們也只好放棄,因為他們沒辦法承擔花這麼多時間而不去開發他們的軟體。

﹝如果有另一個國家想要做一個創業聚集地來和矽谷競爭,那麼第一個他們應該考慮的也許是提供特殊簽證給創業家。美國的移民政策是矽谷的最大弱點之一。﹞

如果你的新創公司和某個產業聯結特別緊密,那麼也許你應該待在那個產業的中心點。一家關於娛樂事業的新創公司可能應該設在洛杉磯或是紐約。

最後,如果有金主已經承諾,只要你留在原地就金援你,那麼也許你也不應該遷徙。尋找投資人並不容易,通常你不應該放棄已經確定的募資條件去搬移。

事實上,創業集散地最大的優勢之一,或許就是投資人的素質。矽谷的投資人顯然就比波士頓的更有野心。我一次又一次的看到,波士頓投資人注意到我們資助的公司之後,卻因為反應速度太慢,而被西岸的投資人搶先一步。在這次波士頓的 Demo Day,我也特別說,因為這種情況每年都會發生,所以如果你們看到喜歡的公司,最好儘早提出你們的條件。雖然如此,一個月內情況依然再度發生:一家 Y Combinator 投資的公司,他們的 founder 只認識西岸某創投不到一個禮拜就接受他們的投資。而波士頓的創投認識這個 founder 數年了卻沒有採取行動。當這家波士頓的創投終於了解發生什麼事情以後,他們的生意早就談妥了。

波士頓的投資人會承認他們比較審慎小心。有些人會說這是基於悠久北方謹慎的傳統。但是事實真相可能沒那麼好聽。波士頓投資人比矽谷投資人更謹慎的理由,就和芝加哥的投資人比波士頓投資人更謹慎的理由一樣。他們並不那麼了解新創事業。

西岸的投資人的大膽並不是因為他們是魯莽的牛仔,或是當地天氣特別好讓他們生性樂觀。他們大膽是因為他們知道自己在做些什麼。他們是屬於在滑雪場滑最困難坡道的一群滑雪者。大膽是創投的精隨之一。創投事業之所以能取得豐厚的報酬,並不是由於嘗試不賠錢,而是在於增加買到強棒公司的機會。而最好的公司剛開始看起來都滿冒險的。

就好像 Facebook 一樣。Facebook 最早是在波士頓開始的。波士頓的創投本來最有機會,但是他們拒絕了。所以 Facebook 就搬到矽谷去,然後在那裡募資成功。拒絕他們的這位波士頓創投,現在也承認,「這個決定也許是個錯誤。」﹝譯注:根據最近微軟投資 Facebook 的估價來看,Facebook 市值大約是 150 億美金﹞

照以往經驗來說,大膽的總是贏家。如果西岸投資人的野心遲早會反咬他們一口,那這一口也來的太慢了。矽谷至少從 1970 年代就開始領先波士頓。如果真的要說報應,那也許可以說是當年的網路泡沫。但是從那以後,西岸只有把領先差距拉的更大更遠。

西岸的投資人對於他們的大膽野性信心十足。至於東岸的則不然。如果有人認為東岸的投資人這樣做是因為比較謹慎,那麼他們應該看看這些人知道自己發現的公司被西岸創投搶先入股的抓狂反應。

從另一個方向來說,創業聚集地也是一個大市場。市場也有集中的特性。即使現在交易員可以在任何地方交易,他們也喜歡群聚在幾個都市裡面。很難說在投資案裡面,面對面接觸產生的效果有多少,但是不論多少,這都不是新科技可以取代的。

如果走在大學路上,時機剛好的話,你可能會聽到五個不同的人在談創業的投資案。事實上,這也是為什麼 Y Combinator 每年要花六個月在波士頓:一年到頭都聽這種事情太累了。但是雖然老是聽到一樣的東西可能會讓你厭煩,但是如果這件事情剛好就是你想做的話,那麼也許你就該到這個地方去。

我最近才剛跟一個在 Google 做搜尋的人聊天。他認識很多 Yahoo 的人,所以很適合比較兩間公司。我問了他為什麼 Google 的搜尋做的比較好,他説,並不是 Google 特別做了些什麼事情,而只是 Google 對搜尋懂得多太多了。

這也是為什麼在矽谷的新創公司絡繹不絕。新創公司是很特別的事業,就跟切割鑽石一樣特別。而在矽谷這種創業聚集地,他們懂這門事業。


全文完

[Note] At here Paul Graham said that translations are welcomed but he wishes to receive a note so he can add a link. However I don't have his mail so I can't contact him. Please let me know if you have his contact information.

YouTube 對創業的真正啟示

大家都知道,去年以 $1.6B 賣給 Google 的 YouTube 是眾人欽羨的目標,也是現在眾多人網路創業的榜樣。但是很多人不知道的,是他們怎麼走到這一步的?難道他們一開始就知道,把影片轉檔然後讓使用者到處播放,就會大紅特紅嗎?

很顯然不是。根據紐約郵報的報導,YouTube 最一開始的點子只是想模仿 HotOrNot。後來發現此路不通,於是逐漸開始轉型。我對他們轉型的過程很有興趣,可惜沒有機會直接問 Chad Hurley 或 Steve Chen,於是找上了好幫手 www.archive.org 幫忙,看看各個時期 YouTube 的網頁長什麼樣子。

youtube_20050428

這是 YouTube 在 2005/04/28 長的樣子。可以點進去,選「All sizes」看大圖。由圖可知,這個階段的 YouTube 做的根本就像是交友網站,弄得跟 video dating site 一樣。或許這個階段的 YouTube 走的還是 HotOrNot 的路線,往 video 交友的方向在走。

youtube_20050614

然後是這個。到了 2005/06/14,YouTube 的首頁版型改變了,變成有點像 video search 網站的味道。但是明顯的感受到使用者上傳的 video 量開始出來了,首頁下方的 featured videos 也已經有各種不同種類的影片開始出現。


youtube_20050720

到了 2005/07/20 的首頁,這時候就已經很有現在的 YouTube 的味道了。使用者和 video 數量激增,這個階段的 YouTube,怎麼擋也擋不住了。

那麼,YouTube 的創業啟示到底在哪裡?對我們有什麼幫助?我覺得可以歸納為以下幾點:
  1. 你第一個想到的點子不見得就是最好的。YouTube 一開始做的根本就是 video dating 的交友網站,但是卻發現 user 上傳的東西五花八門。於是才靈機一動,轉向成「digital video repository」,什麼影片都收。終於大紅大紫。
  2. 要有足夠數量又肯嚐鮮的初期使用者,來試用你的產品。這些人要有足夠的代表性,讓你能夠揣測市場溫度,從而得知點子散播出去的機會大不大。這個族群最重要,feedback 也最 critical。
  3. 要順應使用者的需求,不要妄想教育使用者。人家不見得想聽你說教!如果 Chad Hurley 和 Steve Chen 初期碰到使用者亂傳影片上來,想到的不是轉型,而是教育使用者說:「你傳錯了,你要來我們這裡應該傳你自己擺 pose 的影片!」那麼 YouTube 成功的機會還有多大?
尋找好的點子,就跟找好股票一樣,需要眼光、智慧,和一點運氣。但是點子也跟股票一樣,碰到不賺錢的就要有停損點。停損再出發,總比耗費力氣在不能成功的點子上好。Chad Hurley 和 Steve Chen,即使從 2005/01/01 開始算,到他們逐漸轉型成功,也只花五六個月的時間。時間不可謂不短,手腳不可說不快。這麼短暫的時間裏面,要扼殺掉自己原本想出來的創業點子,換角度重新出發。這中間需要多大的勇氣和魄力,恐怕只有當事人自己能夠體會了。

到底是珠玉還是糞土?

剛剛瞄到一個消息,說另一家使用工人智慧的搜尋引擎 Mahalo,募了另一輪 $20M 的 funding。所謂工人智慧是什麼意思呢?意思是說,相對於 Google 這種利用解讀大量網頁分析出規則的搜尋引擎而言,他們是使用「人」來維護 - 每一個搜尋結果都是使用者製作的。而且根據 Mahaho 的 FAQ,甚至還有人來審核使用者編輯的內容!簡單的說,希望靠網民大軍的貢獻,來提供比 Google 更準確的搜尋結果。

我是不知道這對你們來說看起來怎麼樣,可是在我看來這根本是白痴到不行的東西。這樣的東西也可以在第三 round 募 $20M 的 funding 來燒,簡直不可思議。而且 investor 當中還不乏知名創投與商界聞人,例如 Elon Musk (PayPal 創辦人)、 Mark Cuban (創辦 broadcast.com,當年以 $5.9 Billion 賣給 Yahoo)、Sequoia Capital、News Corp、CBS Corp... 是真的我眼光淺薄,看不到這些前輩看到的東西?還是他們現在已經看不清眼前的東西到底是珠玉還是糞土了呢?

話說回來,前幾天也才有另一個類似的 chacha 拿了 $10M 的 funding,看來這年頭瘋子還真不少...

我實在很想知道,投資人到底從這兩個網站看到了什麼願景?

[Update 2007/11/19: Sorry, but I was not accurate on Elon Musk being the founder of PayPal, although this is true in a way. Elon Musk founded X.com, which later acquired Confinity, and later changed its name to PayPal. But when people talk about PayPal founders, they usually refer to Max Levchin and Peter Thiel, the co-founders of Confinity, since most X.com employees (including Elon himself) left after the acquisition.]

Google Maps 推台灣版了?

怎麼有種 "Not so Google" 的感覺...

剛剛才注意到,Google Maps 這次貨真價實出台灣版了。以前只是更新圖資、把台灣地圖納入,現在看來有些比較 local 導向的應用出現。

怎麼說不是 "很 Google" 呢?感覺以往 Google 都專注在單一平台上面,全世界都推同一套平台,差別只在不一樣地區套用不一樣的 localization - 多半只是介面的翻譯而已。這次跟上次台灣版的 iGoogle 感覺頗像,都很有當地 customize 的味道。不知道是不是 Google 現在開始改弦易轍了呢?

[Update 10/13] 今天剛好要去社教館,想看一下地圖查一下路線,結果只有 Google Maps 用「社教館」會問我是不是要查「台北市立社會教育館」 :p 如果先上社教館網址查好地址﹝臺北市八德路3段25號﹞的話,Google 用該地址可以正確定位到社教館,但是 Yahoo Maps 會定到「宜蘭縣冬山鄉武淵村」... 這還讓我滿訝異的 0__o

達者為先

大概幾個月前,朋友 tsunghao 和我聊起他的一個想法,「讓網站智慧地、自動化產生 tag」。主要想法大約是不要讓使用者自己下 tag 這麼麻煩,而是讓這個頁面自動根據 search engine 導入的 keyword 來排 tag 出來。

我聽到的時候艷羨無比,深深覺得這個 idea 不只棒、貼近 web 基本精神,而且也符合時代潮流。只覺得這個想法潛力十足,也很看好這個 idea 後面的發展。

沒想到,今天一如往常在 surf around 的時候,發現一個網站做一模一樣的事情:Jiglu。完全一樣的做法,完全相同的點子,差別只是對方已經產品化開始推廣了。看起來做的也不壞,我已經把這個 widget 加到我的 blog sidebar 去了...

有句話是這麼說的,「學無前後,達者為先」。雖然這比喻有點不太對勁,但是在 internet 上面確實可以看到類似的情況。你聰明,別人也很聰明;假如你是萬中選一的精英,那世界上就還有五十萬個跟你相同水準的人。英雄所見略同,你想到的別人也不會差太遠,只是誰能夠先把東西做完?誰能夠把東西不只做完而且做的好?差別就在這裡產生。

突然想到去年十二月的一些感嘆。這個系統現在也已經賣掉了。人家確實也做的很好。同樣的事情,一個發生在我身上,一個發生在 tsunghao 身上。只希望我們現在想的點子,能夠比別人早做完,而且也能夠做的好。

Facebook 的 CEO 被告了

Facebook 的 CEO Mark Zuckerberg 被告了。(詳見 slashdot) 三個原告認為 Facebook 根本是剽竊了他們當年的 Business plan和程式原始碼。三名原告當年的網站後來發展成為現在的 ConnectU。三個原告於是要求法官:

1. 關閉 facebook
2. 將 facebook 的所有權,以及 facebook 所有的利潤,轉移給原告。

很多人聽到消息的直覺反應是:太扯了。

真的是滿扯的,不過大家都忽略了一件事情:在美國,打官司告人是非常容易的事情。他們打官司的目的經常不是為了勝訴,而是為了凹比較好的和解條件。

Facebook 如今是當紅炸子雞,看來大家都想找個藉口分杯羹。
週末的時候看到 DK 在講到 zooomr 改版,一定要順便罵一下的。zooomr 自從 Mark III release 以後,三不五時停機維修一下,而且老頭也屢屢跟我 complain,原本的 zooomr 唯一大量上傳工具 jUploadr 不能用了!

詳細狀態可以看這裡 jUploadr 作者的說明,以及後來這裏 zooomr 'CEO' Thomas Hawk 說的「等到我們達到 100% 穩定狀態以前,我們不會 release jUploadr 的 API key」。這種說法當然就在隔天被 jUploadr 的作者打槍了:「希望 zooomr 不用等到一年才能證明自己 100% 穩定。我不知道任何一個網站在一年的期間還可以保持 100% uptime 的...」

難怪 zooomr 這次改版以後可以宣稱讓所有人不限空間、完全免費。反正只要不開放大量上傳工具,使用者也只是看的到吃不到而已。不過話說回來,先不管 scalability 能不能挺的住,一個做 photo sharing 的網站,居然連個大量上傳工具都不敢開放,這簡直是在搞笑嘛...

心有戚戚焉

今天才有空看了六先生說的「加入小公司」一文,或許是近來我看六先生文章最有認同感的文章了。在這死氣沉沉的島上,見到這種局面的人比比皆是,但是有勇氣踏出去、或是願意花時間寫出心情來的人畢竟不多。

我想這篇文章,也完全可以解釋為什麼我想從前公司走出來自己創業的心情。不用被卡東卡西的制度綁死,也不用什麼都講究政治正確,更不用等待言不及義的空泛 innovation 口號。想要的東西,我可以自己做,想催生的網路變化,我自己來主導。成功或是失敗,我可以自己扛。

機會,不用等人給。你自己可以創造機會。

這才是當年決定和網路沾上邊的熱血。很高興在大公司待過之後的今天,這股熱血仍然沒有消逝。