Me唱歌看書研究,程式小說新詩。搞了個Blog和古文網站,寫些亂七八糟及翻譯文章,玩些小程式和中文化。可惜時間美好人生苦短,沒法一一盡善。夢想是開間小 pub,放喜歡的音樂,喝自己調的酒。

noIE.png 針對 css 支援極差的 IE 可能會無法正常瀏覽本站,強烈建議 Mozilla Firefox

本站連結圖示與 Feed:
rss.gif atom10.gif
smalllogo.png

支援標準:
xhtml10validated.gif cssvalidated.gif
rss_valid.gif atom_valid.gif

本站架構:
firefox.png thunderbird.gif
openoffice.png postgresql.gif
spring.png ubuntu_button.gif

網路運動:
Sticker Map GeoUrl
Fight Spam!

本站授權規範:
cc.gif
Creative Commons License by-nc-sa
請參閱網頁下方之版權說明

Powered By Sylphie 0.1a

2009-04-01 03:56:20.39

[翻譯] The Open Cloud Manifesto 開放雲端宣言 中譯

2009 年 3 月 30 日時 ZDNet.com.tw 發佈了檢視「開放雲端運算宣言」的報導,文中指出「開放雲端」(Open Cloud)的六大關鍵原則。而今各家廠商對雲端運算磨拳擦掌,但現在卻未有一套開放標準。這將會使得未來各雲端運算之間可能不存有共通的介面,也會讓未來在各雲端供應商之間轉移或創造新應用時勞心傷財。

此宣言僅是針對網際網路奠基的基本原則,而非針對任何團體、組織、軟體程式碼或專利授權。

本翻譯文件的原始資料來自 http://www.opencloudmanifesto.org/index.htm。其餘相關資料請參見文末。


開放雲端宣言

對全球雲端社群的一項行動呼籲

草稿 1.0.9


序言

圍繞在雲端運算的喧擾已日趨白熱化。有人認為這是種破壞性的趨勢,象徵著網際網路發展過程中的下一個階段。有人則認為這是種炒作,因為它使用的是建立已久的運算技術。如同資訊世界中的任何新趨勢,各組織必須找出雲端運算所帶來的利益及風險,以及使用此技術的最佳方式。

有件事是相當清楚的:資訊產業需要一個客觀且直接明確的對話。此對話是關於新的運算模式將如何影響組織、如何以現有的技術去使用它、以及專利技術的潛在陷阱可能導致封閉或選擇受限。

本文件旨在開啟這項對話,能將新興的雲端運算社群(包括雲端使用者及雲端提供者) 聚集到一套核心原則裡。我們相信這些核心原則將會植根於「雲端運算應如其他資訊技術同樣開放」的信念上。

本文件並不打算定義雲端運算的最終分類,或是許可任何新標準的成果。它也沒有試圖成為雲端架構和設計的詳盡論文。相反地,本文件對打算使用雲端運算,以及為雲端提供者建立核心原則的 CIO、政府、資訊技術用戶及商界領導者闡述,雲端運算雖仍處於早期階段,有許多事物可學,並且更具有實驗性,但此時卻正適合將新興雲端運算社群成員共同聚集到「開放雲端」的概念之中。


什麼是雲端運算,以及為什麼它很重要?

為了了解開放雲端的核心原則,我們需要先有一些基本定義和雲端運算本身的概念。首先,什麼是雲端?雲端運算的架構和術語已明確且精準地定義為,呃,雲端。由於雲端運算已是眾多技術中的高潮,像是網格運算,公用運算、SOA (服務導向架構)、Web 2.0 和其他技術一樣,對其下精確的定義往往反流於爭論。

雖然定義、分類和架構很有趣,但更重要的是了解雲端運算的價值主張。我們需要了解雲端技術的供應者如何共同履行雲端運算的承諾。

雲端中的關鍵特色是能以符合成本效益的方式去動態地調整及提供運算的能力、並且消費者 (終端使用者、組織或資訊技術成員) 能運用大部分權力而無需打理技術的底層複雜事物。雲端架構本身可以是私有的 (位於某組織的防火牆內) 或是公共的 (位於網際網路上)。這些特色可引領出一套核心價值主張:

可擴展性需求
所有組織都必須處理各自環境的變化。雲端運算可調升和調降的解決方案是項重大好處。如果組織有某些時期的運算資源需求會遠高於或低於平常的話,雲端技術 (包含私有及公共) 能處理這些變化。組織僅支付實際使用的資源,而無需維護數套高水準的資源以應付高峰時期的需求。

精簡資料中心
任何規模的組織在其資料中心上都有實質的投資。這包括了購買和維護硬體及軟體、提供設施來擺放硬體、以及雇用人事以保特資料中心運行。組織可以在內部裡利用雲端技術,或以卸載工作量到公共資源的方式來精簡其資料中心。

改善業務流程
雲端提供了基礎設施來改善業務流程。組織和其提供者及合作夥伴可共享雲端中的資料和應用程式,讓每個人把焦點放在業務流程上,而非承載它的基礎設施上。

減少起始成本
對於剛起步的公司、新興市場的組織、或甚至是較大組織中的「科研重地」團體,使用雲端運算可大幅降低起始成本。新組織可在基礎設施皆已到位的狀態下啟動,因建立資料中心所需消耗的時間和其他資源已由雲端提供者所承擔,無論此雲端是私有或公共的。


採用的挑戰和障礙

雖然雲端為各組織呈現了極大的機會和價值,但日常的 IT 需求 (安全性、整合性等等) 仍然適用。此外出現了一些新的問題,原因是雲端運算的多租用戶性質 (來自數間公司的訊息可能位在同一台實體機器上)、應用程式和資料的合併、以及公司的工作量可能位於其實體資料中心之外。本節審查下面五項雲端運算必須傾注精力解決以實現其承諾的主要挑戰。

安全性
許多組織都不安於將他們的資料和應用程式存放在他們無法控制的系統上。轉移工作量到共享的基本設施會增加因未經授權而曝光的潛在危險。因此認證一致性、識別管理、遵從性和存取技術將會變得越來越重要。為了使其用戶安心,雲端提供者必須提出具有高度透明性的操作方法。

資料和應用程式互通性
重要的是,資料和應用程式系統兩者都公開了標準介面。組織將會想要能靈活地創造新的解決方案,好讓資料和應用程式彼此互通,無論其位於何處 (公共雲端、位於組織防火牆內的私有雲端、傳統的 IT 環境或某種組合)。雲端提供者需要支持互通性標準,使組織能將任一雲端提供者的能力納入他們的解決方案之中。

資料和應用程式可攜性
如果沒有標準,那麼用戶將系統轉移回到內部,或選擇改用其他雲端提供者將都會受限於專屬介面。一旦組織把系統建立或移植成使用某個雲端供應商的產品,那麼在將系統轉移回內部時會變得困難無比且代價昂貴。

治理和管理
當 IT 部門採用雲端解決方案到其傳統資料中心時會出現新的挑戰。處理生命週期管理的標準化機制、授權和共享雲端基礎設施扣款是雲端提供者必須共同努力去解決的某些管理問題。

測量與監測
商業領導者會想要在他們的 IT 解決方案中使用數個雲端提供者,並且也需要在這些解決方案中去監測系統效能。提供者必須提供一致的格式,以監測雲端應用程式及服務效能,並且使其與現有的監測系統相容。

很顯然的,機會是留給那些有效利用雲端運算到他們組織中的人。然而,這些機會並非沒有風險和障礙。我們相信雲端運算的價值只有在當雲端提供者確保雲端開放的時候才能夠充分實現。


開放雲端的目標

客戶期望他們所使用的雲端服務能如同他們其餘的 IT 選擇般一樣開放。如前所述,採用雲端運算仍有重大的障礙。當雲端提供者要求他們的潛在客戶去接受放棄對其資源的控制時,仍將廠商封閉性藏在雲端運算的利益背後,會造成雲端運算產業長期的損害。當一個開放雲端成為事實,商業領導者能經由數種方法獲益。

選擇
當某組織選擇某個提供者、架構或使用模式時,開放雲端將讓他們更容易改用不同的提供者和架構以因應商業環境的變化。如果某組織因為新的夥伴關係、收購、顧客需求或政府規章而需要變更提供者,那麼他們能夠輕易地轉移。如果某組織想部署私有雲端,那麼他們能夠依擴展能力和功能性,而在數個提供者之間做出選擇。消耗在艱困移植步驟上的資源現在可運用於創新上面了。

彈性
無論組織使用哪一個雲端提供者和架構,開放雲端都讓他們更容易與其他團體一起工作,即使那些團體選擇的是不同的提供者和架構。開放雲端讓組織更容易在不同的雲端提供者中互相操作。

快速和靈活性
雲端運算的其中一項價值主張是,調校硬體和軟體的能力是必要的。使用開放介面可允許某組織建立新的解決方案,以整合公有雲端、私有雲端和現有 IT 系統。隨著組織的條件變化,開放雲端能讓組織更快速以及更靈活地去因應。

技能
開放雲端的副作用是將會有更多技術熟練的專業人員可雇用。如果同時存在著眾多專屬程式模型,那麼任何 IT 專業人士都不太可能完全理解其中每一部分。在開放雲端中,只有小部分新技術需要學習 (特別當現有技術已使用時),大幅增加了組織找到擁有必備技能人才的機會。


開放雲端原則

當然,許多雲端將持續在一些重要方式上保持不同,好為組織提供獨特的價值。我們不打算為雲端的每種能力去制定標準,或創造單一同質的雲端環境。相反地,當雲端運算成熟時,許多關鍵原則必須要去遵循,以確保雲端開放,並且提供具有選擇性、彈性和靈活性的組織需求:
  1. 雲端提供者必需共同努力以確保能透過公開合作和適當使用標準,來解決採用雲端時所遇到的挑戰 (安全性、整合性、可攜性、互通性、治理/管理、測量/監測)。
  2. 雲端提供者不可利用他們的市場地位,將客戶鎖定至自己特有的平台上,並限制他們選擇其他提供者。
  3. 雲端提供者必需適當地使用和採用現有標準。IT 產業已在現有標準和標準組織中投入大筆金額,沒有必要再重製或重複投資。
  4. 當需要新標準時 (或調整現有標準時),我們必須明智且務實,以避免創造太多標準。我們必需確保標準能促進革新,而非阻止。
  5. 開放雲端的任何社群成果都應依用戶需求來主導,而非依照雲端提供者的技術需求,而且應依實際的用戶需求來進行測試和檢驗。
  6. 雲端運算標準組織、擁護團體和社群應共同努力及互相合作,以確保各項努力不會互衝或重疊。

結論

本文件旨在開啟對話,而非下定義。當雲端運算社群聚集一起時,許多細節 (例如:分類、定義、方案) 將可望填補。

我們概述了組織想運用雲端時的所面臨的挑戰。這些問題將引發一項呼籲行動,對象是身處開放雲端展望中的資訊產業。我們身為產業參與者必須共同努力以確保雲端能維持開放,如同其他資訊技術。有人也許認為討論諸如標準、互通性、整合性和可攜性的話題仍為時尚早。但此時正是雲端運算社群的巨大革新時期,革新仍應遵循本文件所概述的開放原則。我們認為現在正是開始努力去建立開放雲端的正確時刻。

支持開放雲端宣言的公司條列於 http://www.opencloudmanifesto.org/


延伸閱讀:

2007-04-25 14:48:30.703

Google Maps 推出繁體中文化的台灣地圖

今天同事 Maxchu 告訴我 Google Maps 推出了本地化的台灣地圖搜尋服務(意即繁體中文版),於是我立刻上去搜尋台灣的地圖。果然,我看到了熟悉的中文字出現在台灣的地圖上。隨手小試一下,想試試看在 Google Maps 中搜尋台灣地名的成效如何。

google-maps-taipei.png

就目前的測試結果來看,「中文搜尋」僅能搜尋到較大的區域名稱,例如台北、台中、高雄、屏東這樣的縣市名(有趣的是搜尋台東會跑到日本東京都台東區。而其實搜尋花蓮也是會跑到日本去);如果是找中和、中壢、豐原、左營這些類型的地區(縣轄市),那麼 Google Maps 會吐給你一句「Your search for XX around this map area did not match any locations.」(請把 XX 替換成地名)。當然,其他像是「台灣大學」、「台北市政府」、「台北車站」等等完整中文地名的搜尋也幾乎都是吐出這一句。

不過如果使用「英文搜尋」的話,那麼找到的機會就大很多,像是「National Taiwan University」、「Taipei City Hall」或「Taipei Main Station」等較可以正確無誤地找到。或者,退而求其次,使用較簡短的中文關鍵字。像是「逢甲大學」無法直接搜尋到,但是在「大學」的搜尋結果列表中卻可以看到「逢甲大學」的連結。

在地圖的詳細度上,Google Maps 將街道圖的細節描繪的十分精細。許多窄小的巷弄在上面都可以找到,並且也有標示出巷弄名,甚至是單向道也有標示。另外在地標部份,目前有教育機構(國小、國中至大學等等)、醫院、公園、行政機構、捷運站等。只是目前仍未完全支援「地址搜尋」,所以如果你想搜尋「台北市忠孝東路三段」之類地址的話,使用 Google Maps 是會令你有些失望的。

UrMap 比較起來,Google Maps 的優點是多了道路單向道標示、在巷弄的精細度上更高(大多數的巷弄幾已明確標示地址)、衛星空照圖的解析度更高(但大解析度的 Hybrid 會有偏移現象);而 UrMap 的優勢是在於地址搜尋、地標搜尋(相當多各式各樣的地標,甚至結合其他網站)、路徑導航等項目。因此我想在短時間之內, UrMap 在台灣地圖搜尋的地位,其重要性仍應是不容忽視。

Updated: 不知道是一堆網友瘋狂地在上傳 Kmz(地理資訊內容壓縮格式),還是 Google Maps 一直瘋狂地在網路上搜尋及解析 Kmz 檔案,目前 Google Maps 已可使用中文地名和地址來搜尋,包括像「山佳」、「暖暖」、「台灣大學」、「新光三越」、「忠孝東路」、「台北車站」等大小地標。只不過目前尚不齊全,有許多地標仍找不到、對地址搜尋的支援度仍嫌不足,並且路徑規劃並不如 UrMap 好用。但是依照這個泰勢下去,也許用不了多久,Google Maps 便會凌駕於 UrMap 之上,成為更強力大殺手級應用。

2007-02-12 17:43:37.546

Yahoo Pipes - 輕鬆玩弄出你的混搭程式

現在有許多網站提供了自身的 API,可讓開發人員經由 API 來存取該站的資料,並藉以開發出許多極具創意的應用。另外 RSS、Atom 等 Feed 讓我們可隨時掌握網站的最新消息,眾多提供 Feed 的網站形成了大量的資料,當然這也是混搭程式(Mashup)內容的來源之一。

本站之前的介紹文章 - 幾個 Google Maps 和 IP Address 相關的 Mashup,就針對了有關 Google Maps 的幾項混搭程式做了介紹。 只是要做出新奇有趣的混搭程式,除了要有創意之外,還需要一些程式設計的底子,也因此門檻比較高。對一些使用者來說,可能徒有創意但無能力實現。

logo_1.gif不過 Yahoo 在 7 日推出了 Yahoo Pipes 網站(Taiwan.CNET 新聞:Yahoo新推Pipes工具 讓網友自創應用),它提供了以視覺開發為導向的工具,讓大家可以輕易使用拖拉的方式去處理各種 Feed 資料,包括排序、計算、替換、過濾、分析、翻譯(BabelFish)、聯集等等操作,結果可以輸出成 RSS 或 JSON 格式。也就是說,當我們做好一個 Pipe 之後,你可以使用 RSS Reader、Bloglines 來訂閱,或者是把它加進另一個 Pipe 當中,或應用在 AJAX 之中。

最簡單的 Pipe 例如像是你可以把你的 Atom 當輸入,然後以 RSS 輸出(如果你的網站僅提供 Atom 的話,不過我想應該很少會有這種情況);或是把 RSS 當輸入,以 JSON 輸出, 然後在網站以 AJAX 動態更新頁面,做到各科技網站的即時新聞、各大賣場特定商品的即時報價、各網路正妹的最新照片輪播(我承認我想多了)等等服務。

Yahoo Pipes 的自我介紹:

Pipes is a hosted service that lets you remix feeds and create new data mashups in a visual programming environment. The name of the service pays tribute to Unix pipes, which let programmers do astonishingly clever things by making it easy to chain simple utilities together on the command line.

中文翻譯大致如下:「Pipes 讓你可以在一個虛擬的程式環境中,混合資料來源並建立出新的資料混搭程式。本服務的名稱對 Unix 的 pipe(|) 致上敬意,它讓程式人員能在命令列中輕易地把簡單的功能串接起來,做出令人叫絕的奇技淫巧。」所以我想常用 Unix 或 Linux 的人應該對 pipe 這個字並不陌生,可以了解 Yahoo Pipes 想要做到什麼樣的事情。它的操作介面並不會太複雜,經過一些學習後,可以很輕易地製作出混搭程式。雖然說有些地方還是需要點時間去了解,而且只有英文介面,不過我覺得對於想自行製作混搭程式的人來說,其門檻已經降低不少。

Schee 已經做了兩個:Yahoo Pipes: 台灣地方新聞和書籤網站,大家可以上去 研究看看,或是利用 Yahoo 的帳號登入後來玩弄一番,搞出個新奇又有趣的混搭程式吧。

相關閱讀:

2007-02-12 01:46:37.187

AddThis.com - 幫你的文章加上快速社交書籤的功能

相信大家都對一些社交書籤的網站耳熟能詳,像是 HemiDemiDel.icio.usDiggFurl 等等。這些網站允許你將書籤存到網站上,並更進一步對這些書籤的內容做處理;像是 Del.icio.us 讓你把書籤加上標籤 (tag), Digg 將熱門書籤當成新聞一樣顯示,HemiDemi 讓你可針對書籤做評論(請注意,以上是不負責任報導)。有些部落格主和網站站長為了能讓使用者方便地將站內文章加入社交書籤的網站,於是在網頁上放置連結;如同本站每篇文章的尾端皆會有 HemiDemiDel.icio.us 的小圖示連結,點選並進行登入後,即可將該篇文章快速加到這兩個網站上。

然而隨著此類網站愈來愈多,有些格主們只能手動一個個增加小圖示按鈕,在中文支援不足以及各 Blog 系統相異的情況底下,這並不是件太輕鬆的工作。有時即使加了一堆社交書籤網站,偶爾還是會有遺珠之憾,或是一長排社交書籤的小圖示,看起來像在大拜年一樣(笑)。

不過幸好有人聽到了我們的心聲,AddThis.com 提供了我們一個解決的辦法。它將各種社交書籤的網站集合在一起,我們只需要簡單地把它提供的 HTML 式碼加到自己網頁中適當的地方,剩下的工作他們會幫我們操心;也就是說,他們會負責去收集整理各個社交書籤網站,當然包括查詢字串的參數。

首先連到 AddThis.com 網站,並點選 GET YOUR FREE BUTTON NOW! 連結。
1.png

點了之後跳轉此頁:
3.png

第一步選擇你要那種按鈕:Bookmard button 是指可以將網頁快速加入各個社交書籤網站,Feed button 則是可以將站上的 RSS 或 Atom 加到提供 Feed Reader 功能的網站。第二步是決定顯示圖示大小。第三步選擇你的網站是屬於那種類型。第四步則是問你需不需要加上統計資料,例如有多人將該文章加入書籤,以及多久加入一次,不過此項功能需要在 AddThis.com 註冊一個帳號後才能使用。然後按下「Get Your Free Button」按鈕,就可以產生相關的程式碼,再把這些程式碼貼在你的網站中就行了。

現在本站已經加入了 AddThis.com 小圖示了,大家可以點來玩玩。目前 AddThis.com 尚未提供 HemiDemi 的選項,所以仍留著 HemiDemi 的圖示。

同志們,整理你的社交書籤小圖示們吧!

2007-02-07 14:57:25.484

MyBlogLog - 打聲招呼吧

Shih-Hsien's BLOG 那邊看到了有關 MyBlogLog 的文章。其實已經隔了幾天了,想說要來玩玩,不過一直沒動手。(喂!已經很多事都很久沒動手了~_~)

今天又在工頭堅部落看到MyBlogLog:讓我知道您的來訪、讓我分享我的流量,讓我下定決心要來註冊一下,順便更新一下網站。詳細的註冊教學什麼的,已經有許多人發表文章了,底下列出幾個網址讓大家參考一下:

基於這些、那些理由之後,總而言之旁邊的側邊欄是已經加上去了,只是目前上面沒有「任何」一張圖片。呃…我想應該是它不會顯示網站擁有者的圖片吧,不然至少也應該顯示我的圖片才對。它到底在這裡能不能正常作用呢?@_@
2006-12-11 00:17:08.921

進入部落格觀察的藍眼觀注投票以及一些想法

在昨天將大部份資料匯整上線時,其實也一併做了個簡易的「反向鏈結」記錄程式。其實是在當初設計時,老早就把「反向鏈結」的表格 Referer 給設定上去了,只是一直到現在,這個表格都還沒有啟動它的功能 (老實說還沒用到的表格還包括有附加檔案 Attachment、迴響 Comment、引用 Trackback、範本 Template、標籤 Tag 和 版本控制 Version 及一些客戶端看不到的小表格)。今晚在檢查這個部份的運作情況時,赫然發現部落格觀察有一個反向鏈結連過來。用Mozilla Firefox的頁面。我大致知曉部落格觀察有所謂的藍眼觀察和綠眼觀察,藍眼觀察指的是以前一週的排名進步前 20 名為入圍名單,公告出來之後,交由使用者投票 (有關藍眼觀察的其他資料請參考這裡);而綠眼觀察則是穩定成長的大部落格,在這裡有綠眼觀察的說明及站台列表。

也就是說,部落格觀察的藍眼觀察在某一程度上將決定權交給使用者去執行,我似乎在其中嗅到了有 Web 2.0 味道。在上一次的 HappyWeb 網聚中請到了部落格觀察食夢黑貘愛麗絲談有關部落格觀察的事,我對於他們的工作也有了更多的了解,他們也提及到在未來會有更多的計劃將會逐步實施。然而在我今天注意到為了避免投票部隊,而做的加權比重設計時,我就在想,或許針對已註冊並認領過部落格的使用者,可以有一個「我的排名」之類的功能。這個「我的排名」首先不能加入自己已認領的部落格,並且不需排名所有部落格。例如某 A 只選了三十個部落格來排名,而某 B 或許排了三百個部落格 (意即某 B 名單中的二百多人對某 A 來說是「零分」,也就是無排名)。這種使用者自訂的自我排名或許也可以供其他的使用者做為參考,可能的後續結果會是使用者們集體所產生的另一種「部落格觀察」,這其中必然會有相對的權重出現。像是官方觀察名次較前、影響力較大的使用者所下的排名其權重會較高之類的。而至於需不需要將其也加入到官方目前的觀察選項之中,做為觀察的條件之一,則又是要另行討論的事了。

當然也有可能會出現某些使用者互相串通好的事情,在這部份需要再考量一番。而我認為在資料量夠大時,這樣的情況也許造成的差異性會相對降低,尤其是在權重分配的前提下。或許也可以討論出避免的方式,不過當然這只是我的想法而已。另外像是以 HEMiDEMi使用「推薦制度」(也就是沒有負分系統),也很可能會是一種做法 (當然權重我想仍會是必要的)。換句話說,經由每人限推薦單一網站一次的前提下,來用推薦配合權重來加以排名,這也許會比「我的排名」更易些,姑且稱之「我的推薦(謎?)」。不過話說回來,也不是所有的網站都需要趕上 Web 2.0 的流行的。趕不上就叫落伍的話,整個網際網路或許現在都處在極度落伍的狀態呢…=)

2006-11-30 05:42:06.515

HappyWeb 第二次網聚

最近不管是科技人員、報章雜誌、公司主管還是政府機關,如果不隨口帶上一個「Web 2.0」的新名詞的話(事實上是舊名詞了,人家 Tim O'ReillyO'Reilly Media 早在 2004 年的大會上就已經提出了。詳情請參閱 What Is Web 2.0 以及 Web 2.0),就彷彿落伍別人一大載,這情況甚至嚴重到 經濟部斥資四億以協助產業或個人從事各種網路創新服務的研發(我也好想分一點),整個網路似乎又瘋狂了起來。而到底究竟 Web 2.0 只是一時熱門的名詞,其實真的不晒一顧 (最近流行的名詞還包括 SEO、SOA,而前一陣子還有…呃,老實說流行過的名詞太多,誰會真的記得那麼多 ~_~),還是網路為求生存而不得不走上的道路?不管是網頁設計師、美工設計師、網站架構師還是公司主管們,到底究竟能不能繼續 Happily web?(那個請注意,這個 web 我把它拿來當動詞用)

之前 Tempocjin 在 11/11 舉辦了一場 HappyWeb 的網聚,當時邀請了 HEMiDEMi 的創辦人 葛力 到場演講,吸引了不少人參加此一盛會。HappyWeb 挾著 高漲的人氣群眾們的熱情Tempo 再度舉行聚會 (呃…我想應該是第二次吧…?)。本次將會邀請 部落格觀察食夢黑貘愛麗絲 來談談,和大家相見歡。可以預期(謎?)的是這次將會又是一個好吃(食物嗎?)新奇又好玩的聚會,可以吸收到不少新觀念,並且認識來自四面八方的人。詳細的時間和地點請點 這裡

PS. 雖然 某人 話說 有人一直在喊肚子餓,但那其實是……好吧,真的很餓 ~_~。

2006-11-23 00:56:38.64

幾個 Google Maps 和 IP Address 相關的 Mashup

自從 Google 推出了 Google Maps 的服務,並且無償開放 Google Maps API 給公眾使用之後,許許多多和 Google Maps 相關的應用相繼推出,它們稱之為 mashup,中文名稱為「混搭程式」。根據 The Free Dictionary 告訴我,mashup 的意義 如下:

A mashup is a website or Web 2.0 application that uses content from more than one source to create a completely new service. This is akin to transclusion.

Content used in mashups is typically sourced from a third party via a public interface or API. Other methods of sourcing content for mashups include Web feeds (e.g. RSS or Atom) and JavaScript.

Much the way blogs revolutionised online publishing, mashups are revolutionizing web development by allowing anyone to combine existing data from sources like Amazon.com, eBay, Google, Strikeiron, Windows Live and Yahoo! in innovative ways. The greater availability of simple and lightweight APIs have made mashups relatively easy to design. They require minimal technical knowledge and thus custom mashups are sometimes created by unlikely innovators, combining available public data in new and creative ways. While there are many useful mashups, others are simple novelties or gimmicks, with minimal practical utility.

Advocates and Supporters of Web 2.0 applications claim that mashups exemplify this new movement with their active user participation and interaction.

前兩段的中文翻譯大致如下:

混搭程式(mashup)是指網站或 Web 2.0 應用程式使用了來自一個以上來源的內容,藉以創建新的服務。

混搭程式內容的來源一般是經由公開的介面或 API 而取得。其他的方式亦包括有 Web Feeds(例如 RSS 或 Atom)及 JavaScript。

由於許多網站公開了其服務相關的 API,再加上在網路上已蔚為風潮的 RSS、ATOM 及 Ajax 等,我們現在可以發現已有數量極多的混搭程式存在,像是與 Google MapsFlickr 相關的混搭程式皆不可勝數。底下介紹幾個 Google Maps 與 IP 位址相關的混搭程式。

首先大家最先想到的是可能是某個 IP 位址位於地球上何處,尤其是網站遭受攻擊、或是在 BBS 中某個人發表了令你不快的言論,讓你很想送他一枝番仔火和一桶汽油(本典故來自 台灣霹靂火)、或者是你想要知道某個心儀已久的正妹家住何處,想利用她上線的 IP 位址來幫助你完成心願的時候(只是如果是這樣的話,我勸你還是不要再繼續做夢下去比較好)。所以底下我們就先來看有關此類型的應用。

第一個要介紹的是 My IP address。它可以根據你所輸入的 IP 位址來找出國家、城市、經緯度以及 ISP 的名稱,另外在其網頁的左側選單中還有幾個常見名詞的介紹。只是整個網站讓我感覺很想要出名的樣子,似乎一直希望大家把它們推廣出去,難不成是為了成名之後好出售網頁區塊給廣告商嗎?

第二個是 Geotool。它除了 My IP address 所列出的資訊外,還多了主機反查名稱、國旗、DVD 區域編號和郵遞區號(不過在台灣部份是未知狀態)。另外它也提供了一個 Mozilla Firefox 的附加元件(extenstion):Flagfox II。這個附加元件的功能是可以顯示目前主機所在地的國旗,當然它是藉由主機的 IP 位址去找出主機實際所在地點,因此可避免 Domain Name 的網域名稱結尾是 .uk 或 .tw 而給人的誤解,因為很可能它們實際上是位於其他國家的機器。

第三個是 Google Maps IP,只不過我的 IP 在上面的地理位置是在非洲外海。咦?我不記得我是坐在船裡上網的啊(默)。其網頁中指出該網站使用了 hostip.info 的地理資訊,而在 hostip.info 只認出我的 IP 位址的是來自台灣,經緯度似乎無法確認,看來是資料庫中的資訊仍然不足。另外值得一提的是 hostip.info 提供了 Mozilla Firefox 的搜尋引擎外掛和名為 hostipfox 的附加元件。它的功能是當滑鼠移到超連結上時,會有一個像是工具提示之類的黃底小框框,上面會記錄有該連結的網址、主機名稱、IP 位址、及地理位置。我個人認為這可以算是一個尚可一試的雞肋玩具,適合很在乎每個連結會連往那個主機和地點的使用者。

再來是有關 traceroute 的部份。Traceroute 的意思是追蹤路由,也就是說它會從你目前的 IP 位址當作起點,你所指定的 IP 位址或網址名稱當作終點,然後依此開始往上追蹤每一個路由節點,並且將這些路由節點的 IP 位址、反查網域名稱(如果有的話)以及反應時間列出來。因此和 Google Maps 結合的話,就是在地圖上用一條線從你的 IP 位址連出去,並經由各個路由節點的所在地點後連到終點,也就是你想查詢的 IP 位址或網路名稱所在的地點。

第一個是 Google Maps Hacks。它需要你將 tracerote 封包列表資訊複製到表單之中,然後按下送出。接下來你就可以看到它在解析各個 IP 位址,然後在地圖上標示出這些主機的地點,並用一條線將它們連接起來。因為不是每個 IP 位址都有各自己的經緯度地理資訊,大部份都是 ISP 的機房地點,甚或是某城市的經緯度,所以實際上很可能你只會看到一個標記,因為所有的路由節點的經緯度都指向該點。因此建議你可以 traceroute 國外的網站,像是美國、歐洲甚或非洲,這樣比較容易看出來線段和它的轉折點,也比較容易有成就感 (笑)。

第二個是 Mapulator.com。它提供了 tracerote 和 ping 的功能,看起來似乎是使用 Java Applet 去做 traceroute 的工作。我說「似乎」的意思是指我無法在我的電腦上成功地完成 traceroute 的功能。可能是我的電腦太慢而讓它無法反應,或者是它的 Java Applet 程式有 Bug 還是載入問題什麼的。總而言之就是我無法正常啟動網頁上的 Java Applet 程式,也因此就無法得知它要如何得知 traceroute 資訊,以及它最後呈現的結果是什麼。

在 traceroute 方面,還有另一個不同概念的應用,就是 Email graphic traceroute。不知道信箱中的電子郵件是經過那些伺服器轉接站而來的嗎?這個網站可以幫助你,只要你將電子郵件的「標頭資訊 Headers」(重點是在於所有的 Received 定義) 複製到表單之中後送出,那麼它將會解析這些資訊,進而把所有轉送此封郵件的伺服器串連在地圖上,只是我想一般人大多都不清楚要如何查出一封電子郵件的標頭資訊。即使找出標頭後成功送出讓它去搜尋,也可能無法真正得知該封電子郵件的 traceroute 結果,因為有些 IP 位址很可能無法被順利解析。

最後一個有趣的應用是 Goocam World Map。它可以在地圖上標出有公開網路攝影機 Webcam 的地點。也就是說它藉由 Google 的特殊搜尋,找出含有特殊關鍵字「axis-cgi/mjpg」的連結,並經由 hostip.info 解析出這些連結裡主機的 IP 位址,然後再在地圖上標示出其 IP 位址的地理位置。如果你點擊地圖上的標記的話,那麼它就會跳出一個小框框,播放該網路攝影機目前所取得的影像。

覺得意猶未盡,想要找更多與的混搭程式嗎?那麼目前擁有 1262 項混搭程式列表的 ProgrammableWeb: Web 2.0 Mashup Listing 網站或許可以讓你一飽眼福,滿載而歸。

2005-05-22 13:00:19.968

Google personal web site URL

有興趣的人可以到下面的網址去玩一玩,目前當然只有英文版本。

mygoogle.png

2005-05-22 12:54:04.021

Google推出個人化首頁

Taiwan CNet 上看到了這篇Google推出個人化首頁新聞,心想Google搜尋引擎大老也和Yahoo看齊,推出了類似My Yahoo!的服務。其中將會讓使用者自訂 Gmail 電子郵件Google News 新聞標題每日一字每日錦句、股市、天氣、電影、SlashdotNew York TimesBBC News等等。你可以自由地去選擇每個模組將要出現在首頁的任何一處,只需要擁有 GMail 或其他 Google 服務的帳號,那麼就可以去使用這項整合的新功能。

由於 Google 從成立至今已推出了不少服務,因此可以預期的是,日後將會有更多的功能整合到這項個人化首頁之中。我猜想包括有 Flickr 相簿、個人 Blog、桌面搜尋、RSS 訂閱器、音樂圖片和影像的搜尋、個人搜尋歷史清單、地圖和 Google Groups 等服務都應該會慢慢增加到這裡面來。或許日後還有可能會和影片商及音樂商合作,推出線上購買音樂或新歌、新片快訊之類的東東,甚至買書、拍賣、每日每週星座預測之類的玩意。

雖然 Google 主管提出此項服務並不是要 My Yahoo 及 My MSN 等個人化首頁競爭,但是以 Google 如此大受歡迎的程度來看,如果他們持續針對 Google 個人化首頁做各式的加強,並延用傳統一致的簡樸畫面的話,那麼對 Yahoo 和 Microsoft 而言,將會造成不少的壓力。

Page: 1 2 3 Next >