Google Map 又有更新

呃，UrMap 處境真的越來越艱難了。 這次更新最主要的是可以用中文地址來搜尋了，這個又是一個里程碑了，下一個里程碑應該就是路徑規劃了。地圖上的資訊感覺也變多了，例如省道也有標出來，還有就是 7-11，全家，萊爾富，中油，郵局，和一些寺廟等在地圖上也找得到。 下一步應該就是路徑規劃了。

台灣美女地理雜誌

因為是我自己也玩過這種結合地圖和相片相關的東西，每看到和地圖相關的應用時我總會比較注意一點。前一陣子看到一個令人眼睛為之一亮的酷站:
台灣美女地理雜誌
這個看起來真的蠻炫的，不過用 GMap 來做這個效果並不困難，但我知道這種應用最難的就是圖片和地理資訊的來源，當看到他的圖片來源是丁丁大站，這就有意思了。沒想到丁丁大站居然有記錄照片的地理資訊了？不簡單啊，如果沒有提供 API 的話，可能是他寫程式去從網頁分析出地理資訊來，這個也讓人佩服，再不然就是他去收集並記錄在丁丁大站中有記錄地理資訊的照片，這個也令人佩服。

不過我觀察了一陣子，覺得有點怪怪的，怎麼照片出現的位置這麼的平均？想像中應該會非常集中在南北，而在其他的地方應該會比較多是出遊的照片，沒想到真的很平均，連金門馬祖也蠻多出現機會的。我就想說他大概有考慮到地區平衡吧，讓每個地方都有出場的機會。不過當我好像看到有重覆的照片出現在不同地方我就開始覺得怪了，再等一下，就出現像下面的照片：




呃，這個... 該不會是隨機出牌的吧...

clickclickclick

算是留下個記錄吧。

相信大家都知道"點點點"是啥東西吧，不知道的請看這裡，這裡，這裡 和很多相關報導。

GAME 6 是從 19日，前期延續 GAME 5 的氣勢，台灣大幅領先，到 22 日起可以參考以下的戰記：
[Ｃ^３戰記] ＧＡＭＥ６ - 中後期時間紀錄

而日本方面也有記錄 GAME 6 戰記。有趣的是，他們也知道台灣方面落敗所歸咎的原因，也就是中華(種花)電信。 其實日本一直都在記錄他們的戰史，放在這裡。回顧過去幾回合的記錄，就知道匈牙利也和台灣一樣被日本逆轉過，雖然看不懂日文，不過光看圖像的記錄就覺得很有趣。

回顧日本方面的戰史，他們在 GAME 2 參與遊戲時，也有一個快速超越的曲線
不過這條曲線是比不上台灣在 GAME 5 的氣勢 但基本上，在 GAME 2 時，日本用了 3 億奪冠，在 GAME 1 的冠軍丹麥只用了八千萬而已。

而在 GAME 3 時，出現了兩強的爭霸，日本和匈牙利各自演出了逆轉的實力，只不過日本才是最後的勝利者，而這個逆轉相信讓匈牙利非常不甘心。 而很明顯的看出來，這時候大家都開始出現誇張的爆發力，想必大家早就不是用手來玩遊戲了。GAME 3 用了五億才分出勝負。

GAME 4 延續的兩強爭霸，匈牙利要為 GAME 3 雪恥而一路領先，不過日本最後的追趕相信也讓匈牙利非常緊張。
從日本戰記中得知，此時日本的自動點點程式就用斧的形象出現了。 而從 GAME 4 的勝負到了 16 億的水準。

GAME 5 開始時還是日本和匈牙利的纏鬥。
但中期日本開發出自動認證機制這個決定勝負的工具，把遊戲從比點擊數到比人數，再變成比機器數，自然匈牙利後期就完全不是對手了。
從日本戰記中 "お祭り騒ぎで首位独走！　日本、孤高の一人旅！！！" 這句話就看得出自動認證是多麼的可怕。 GAME 5 日本用 21 億勝利。
在 GAME 5 中期，台灣就參與了這個遊戲，雖然上面提到那個追趕的曲線很讓人振奮，不過實際上和前兩強比起來還是懸殊的差距，雖然日本應該也很明白台灣的實力，不過他們還是很有自信的。


而 GAME 6 就是開頭提到的戰記了。不過此時的勝負反而退到了 10 億的水準，原因是因為官方網站的認證機制使用全動態的形式，這也比較出 GAME 5 的 21 億有多誇張。

遊戲還在進行中，目前是 GAME 7，台灣領先。

Reference:
台灣點點點
ClickJapan

變動 blogger 模版

最近把我 blogger 的模版做了蠻大的變動，變得更單純(調)更難看了 :) 不過我還是比較喜歡這種延伸整個版面的方式，反正醜都醜了，也弄不出什麼好看的版面，就這樣單單純純的也不錯，不過顏色還是挺難看的。

雖然 blogger 是各個 BSP 系統中讓人有最大自由度的一個，不過他提供的模版系統說實在的也難用得可以了，用 XML 來寫程式真是痛苦。blogger 還有幾個讓人抱怨的地方，首先 blogger 對 xhtml 的支援真是讓人不知該說什麼，他的模版輸出的一些連結都無法通過 W3C Validation Service，而且還有一個自做聰明無法去除的 Navigation bar，也一樣過不了驗證，雖然不致於影響顯示，不過對我這個龜毛人來說就是看得不爽。而因為他的模版是 XML，所以寫在模版的連結要把 & 寫成 & ，否則產生出來的 url 驗證會不過。

再來就是他的 Widget 真是難用，這個也是一來是因為 XML 模版的問題，二來很多資料必需在特定的 Widget 中才能取得，而他 Widget 的內容卻不全放在模版中，而是還有另一個存放的地方，當然這些做法可能是因為他要讓一般使用者方便用拖放的方式修改版面，不過還真是難看。

還有一個真的很討厭的功能，就是 blogger 預設會有很多類 Ajax 的功能，例如換頁和他的 Archive 都用了 Ajax 的功能，而且我覺得做得真難用，最糟的就是都去不掉。後來只好在 body 的開頭加上

<script type='text/javascript'>
_WidgetManager._Init=function(){};
_WidgetManager._SetPageActionUrl=function(){};
_WidgetManager._SetDataContext=function(){};
_WidgetManager._SetSystemMarkup=function(){};
_WidgetManager._RegisterWidget=function(){};
</script>

把 Ajax 相關的功能全部蓋掉。但這樣預設的 Archive 就不能用了，所以再用 YUI 的 TreeView 把 Archive 的功能做出來，清爽效果又好，:)

<link href='http://yui.yahooapis.com/2.2.2/build/treeview/assets/tree.css' rel='stylesheet' type='text/css'/>
<script src='http://yui.yahooapis.com/2.2.2/build/yahoo/yahoo-min.js' type='text/javascript'/>
<script src='http://yui.yahooapis.com/2.2.2/build/event/event-min.js' type='text/javascript'/>
<script src='http://yui.yahooapis.com/2.2.2/build/treeview/treeview-min.js' type='text/javascript'/>

<b:widget id='BlogArchive1' locked='false' title='Archive' type='BlogArchive'>
<b:includable id='toggle' var='interval'/>
<b:includable id='interval' var='intervalData'/>
<b:includable id='menu' var='data'/>
<b:includable id='flat' var='data'/>
<b:includable id='posts' var='posts'/>
<b:includable id='main'>
<div class='header'><data:title/></div>
<div class='content' id='blogarchive-content'/>
<script type='text/javascript'>
 var archivetree = new YAHOO.widget.TreeView("blogarchive-content");
 var archiveroot = archivetree.getRoot();
 var yexp = true;
 var mexp = true;
 <b:loop values='data:data' var='i'>
   var y = new YAHOO.widget.TextNode("<data:i.name/> (<data:i.post-count/>)", archiveroot, yexp);
   yexp = false;
   <b:loop values='data:i.data' var='j'>
     var m = new YAHOO.widget.TextNode("<data:j.name/> (<data:j.post-count/>)", y, mexp);
     mexp = false;
     <b:loop values='data:j.posts' var='k'>
       new YAHOO.widget.TextNode({label:"<data:k.title/>", href:"<data:k.url/>" }, m, false);
     </b:loop>
   </b:loop>
 </b:loop>
 archivetree.draw();
</script>
</b:includable>
</b:widget>

另一個變動是，換回 syntaxhighlighter ，雖然它最近出了 1.5 版，不過在 blogger 上還是有問題 (因為這是 blogger 的問題 XD, 解法就看這裡囉)，而且 code 裡也還有 bug ....

Picasa Web 結合 Google Map

真可惜當初 flickr 不是被 Google 買下來...

終於 Picasa Web 也把 Map 的功能加進來了 (目前只有英文版有)，加上 Picasa 本身速度真是快得嚇人，用來當做個人相簿真是個很好的選擇。不過 Picasa Web 本身社群的功能還是弱得很，還差 flickr 很多，這點一時半刻大概也很難追上來。

目前 Picasa 的 Map 功能大致上算是不錯的，很直覺也很快速，不過這些只算是基本的，我的 Flickr Gmap Show 也都有 :) 不過在 Flickr 推出多國語言版後，我的 Flickr Gmap Show 好像會有點問題，要找個時間看看是什麼問題了。

Reference:
Picasa Web Album 終於與 Google Maps 結合了！
Picasa Web Becomes Location Aware

推推王 frame 內嵌顯示

好像已經是個炒冷飯的話題了。

先看一下後面列的相關討論吧，基本上是討論推推王用 frame 內嵌的方式顯示其書籤網頁。



討論中常舉出的例子是 Google 和 Yahoo 的圖片搜尋。雖然從技術上來說是相同，但以我自己來說，呈現出來的感覺是很不同的。從 Google 和 Yahoo 的圖片搜尋結果，很明顯的把 frame 的邊界保留，在上面的頁面很明白的寫出有可能有版權保護，並且沒有加上太多的裝飾，而是以很單純的方式來明顯指出上面這個 frame 的目的 (如標示原始網址，顯示圖片尺寸和大小)。但從推推王的畫面來看，首先他把 frame 的邊界隱藏，再來他加上了很多和推推王本身的功能，並且上面的 frame 用的裝飾和配色和他首頁有一致的型式。如同討論中提到 「匡架鏈結（frame link）」會侵害著作權嗎？ 中的：

是否會造成不公平競爭或欺罔公眾之情形，亦得依個案認定。

以我個人來看是上面我所舉的這些差別是不能忽略，而不能單純用 Google 和 Yahoo 的例子來推論推推王的做法沒問題。我知道這麼做對使用者來說也許是比較方便的，但以我個人來說，我第一次看到推推王看到它這種顯示方式時，我是皺起眉頭，而不是覺得"哇，真方便"，我相信這應該不只是我個人的感覺。

再者，如果推推王是要成為一個工具型的網站，也就是說像是 rss reader 之類方便使用者收集資訊的網站，這樣以使用者的方便為原則來使用內嵌或許會比較有說服力，但以推推王的首頁來看，實在分不出和一般書籤網站有什麼不同之處，使用者不用註冊就可以使用，也可以瀏覽和點選連結開啟 preview，而不是需要使用者註冊才能使用。

以前在搜尋網站出現時就出現討論是否搜尋引擎有權力不經同意去為網頁做 index，而書籤網站出現時也來討論是否有權力不經同意去把網頁加入書籤，甚至連部落格觀察之類的排名網站也有人不想參與其中，而現在這種 frame 的使用方式難道不需要再考慮一下嗎？目前推推王的 preview 是沒有一個固定的網址可以讓別人從外面直接連結至 preview 畫面，但如果有另一個類似網站把 preview 也做成有固定的網址呢? 那就可以把 preview 網址再提供給別人使用，我相信如果這樣會讓更多人皺眉頭的，而我們要在哪一步喊停呢？討論中提到可以用 toolbar 的形式來解決這個問題，而大家也知道如果要使用者安裝一個 toolbar 一定就沒那麼多人用了，那為什麼其他的網站還要做 toolbar 而不去做和推推王相同的事呢？是因為推推王第一個想到嗎？我想既然推推王有很豐富的功能，就不要一直維持這個可能讓人不悅或引起爭論的做法，盡力發展和其他單純的書籤網站不同的功能才算是真正的特色吧。

相關討論：
關於各位部落客對推推王iframe的指教
[討論] 推推王的適法性 (推推王的討論)
推推王瀏覽方式所造成的不公平競爭
FUNP不公平競爭的問題？
有關FUNP的適法性
推推王應注意著作人格權問題

腳尾米

腳尾米30分鐘版

雖然大部分的評論是著眼於不查證這件事上，但我覺得這件事的問題主要是在製造新聞和題材選擇，至於查證這件事，他們弄這種老實說不知怎麼查證的事來玩，要是我也只能來訪問當事人，不然能怎麼求證呢？至少在狗的新聞上也有去找個醫生來問一下，說實在真不知道要怎麼求證，根據當事人提供的證物開始來化驗嗎？如果要凸顯不查證這個問題，應該要弄個真的能查證的事來搞吧，像是暴個假料之類的。

至於題材選擇，老實說觀眾水準就這樣，為什麼大家不去看公視新聞就好？如果公視新聞的節目收視率比那些有的沒的新聞台還高，那還怕他們不改嗎？這不就是自由市場嗎？說新聞太自由，選擇權就在手中的遙控器吧，大家都看公視，都看 Discovery 不就好了咩。當然，製造新聞也是該鞭沒錯。

Poor Pluto

呃，去年的事了。

雖然九大行星裡，冥王星名字聽起來最炫的，但其實他是小得可憐路徑又怪異，甚至以大小來說他也排不上前九名。所以就把行星定義改了一下，冥王星就排不上行星了。

必須圍繞太陽運轉﹔自身引力足以克服其剛體力從而使其呈圓球狀﹔必須是其所在區域具有統 治性的天體，能清除其軌道附近的其它物體。

冥王星因為路徑和海王星交叉，大小又比不上海王星，所以就被除名了。

被排擠了。

UltraEdit-32 v13

這裡沒有提供序號哦。

UltraEdit 一直是 windows 上的眾多 text editor 的頭號目標，他自己也大言不慚的說是 "the defacto standard for text and programmer's editors"。不過 UltraEdit 真的是功能完整，速度也快，雖然像是 Notepad++, PSPad 這類的開放或免費的 text editor 也做得不錯，但不論是功能上或是感覺上總是差了臨門一腳 (不過可能主要的原因是大家都用 UltraEdit "免費"版吧)。

但每套軟體都有 bug，UltraEdit 有個 bug 在很久以前就一直存在，就是在編輯 unicode 文件時在顯示 HEX 時，UltraEdit 會不管原本開的文件的編碼方式 (utf-8, unicode big/little endian) 而統統轉成 unicode little endian 來顯示。或許它是想把 unicode 轉換這種事通通藏起來，反正你看到的都是 unicode ，只不過在檔案裡是不同 encoding 而已，所以在編輯時就都先轉成 unicode 的型式。可是這個問題真的害了很多在 charset encoding bug 裡掙扎的人們，不知看過多少次用 UltraEdit 的人被這個問題混淆而找不出因轉碼造成的 bug。因為這個問題，我完全不相信 UltraEdit 的 Hex 的功能。

每一版 UltraEdit 出來，我都會看一下這個問題解了沒，直到最近的 v13 才把這個問題解了一部分。說一部分，就是他還是會把 unicode big endian 的 BOM 檔頭去掉，真不知道他是怎麼想的，使用者看到平白無故用 Hex 來看少了 2 bytes 不會覺得很怪嗎？所以還是不能相信 UltraEdit 的 Hex 的功能 :)

Flickr Gmap Show GM script v1.2

新版本，過一陣子應該就會自動更新吧~~
userscripts.org
install
主要加上兩個功能，一個依時間 (年-月) 來在 GMap 上瀏覽 Flickr 的照片，算是把舊版本的功能拿過來再改良吧。另一個類似的功能是指定某一 tag 然後在 GMap 上瀏覽。





把目前的功能整理一下，大致上有下面的功能：

• 依時間來在 GMap 上瀏覽照片
• 在 GMap 上瀏覽某一使用者的照片
• 在 GMap 上瀏覽標為某一 tag 的照片
• 在 GMap 上顯示某一 set 中所有的照片
• 在 GMap 上顯示某一 group poop 中所有的照片
• 在 GMap 上顯示單一照片
• 在 GMap 上指定、修改照片的位置

當然，一定要 geotagged 過的照片才看得到。