AJAX…好大的招牌
其實我第一次認識 ajax 這個字,是因為國、高中時瘋狂看體育台,所以認識了這一支足球隊…阿賈克斯,不過他戰績不好…沒有像特南克斯擁有戰鬥力。
在玩程式時遇到 AJAX(Asynchronous JavaScript and XML),其實一直沒有深入研究,因為看了幾篇教學之後,就發現他是有一個小小的問題…「安全性」,剛好「安全性」是我的怕研究的部份,所以就不管AJAX了。過了幾年的發展,AJAX其實有很大的進步,首先…一些如mojo、jquery之類的js程式庫支援,讓終端使用者可以利用簡單的方式操作DOM,也可以直接使用AJAX,除此之外在XML、JSON上也不用再自己想辦法…簡直就是把我的惰性發揮到極致,讓我再也不想去深入瞭解它運作的原理了。
另一方面,IE改邪歸正也有關係,因為以前一遇到js的程式,我就認輸了,寧願用php去想辦法繞出結果,也不願意為了IE6、7、8測試修改。
重新開始玩AJAX之後發現,我以前還蠻不長進的,因為所謂的「安全性」,其實是和AJAX搭配使用的程式如PHP該注意的,AJAX還是負責傳遞資料為主。
網路上應該很多資料了,我來寫篇教學…恐怕力有未逮,即然如此,那我就此收手了,單純是此時此刻覺得ajax…很不錯。
javascript…曾經被我看不起的程式,翻身了。
2011/04/19
2011/03/22
dyson
昨日傍晚時分,黏大問起 dyson 吸塵器,感覺他是一個問了就會買的人,但是我手邊實在沒有任何資料,補他一篇小文供參,因為我要買的那時候,也是花了很多精神研究…畢竟…有點小貴呀!
台灣代理的dyson吸塵器只有部份型號,這樣也好…單是在美國有的機種就太多了,反而會太花精神,先不討論手持式的,那就只剩下圓筒式及直立式。
台灣有的是 dc24 (直立式)及dc22、dc26、dc12、dc12plus(以上4台為圓筒式),簡而言之…直立式就是整台推著走、圓筒式就是整台拉著走,推拉之間各有不同,看個人使用習慣吧!每個型號之下,還有不同的設定,如所有地板皆適用版、吸力加強版、標準版、吸頭電動掃地版…之類的。我建議大家可以只考慮dc22 or dc26,時間就是金錢,就不要去想微乎其微的地方了。Dc22算是dc26的原型,把dc22縮小成面積只佔一張a4大小的機身…這就是dc26,廣告號稱體積縮小、吸力不變,不過官方數據顯示吸力約是75~80%,換言之天下沒有白吃的午餐,縮小體積要牲犧部份的吸力,不過還留有7成算是合理的。Dc26設定給都市中的小公寓,或是自己一個人住的小房間,因為方便收納;dc22給我們鄉下人用,房間太多、堆了太多廢物的家裡。
不過我買的是dc25直立式,台灣沒有這一台,最接近的是dc24,相當好用…且方便。
我買的時候還有另一個考慮,那就是HEPA過濾,就是內建醫療級濾網,數據是可過濾到0.1微米的過敏原,官方的另一個比譬是…過濾到香煙氣味的分子。不過HEPA不是每一台都有,要再看一下。並且,這是我個人喜歡的功能,但這不是空氣濾淨器,只是拿來盡可能吸掉一些不好的物質,可以拿來吸床、被、沙發…就只能這樣用。
如果從dyson us官網看,並不是每台都有HEPA,不過台灣代理商也很乾脆,現在可以買到由台灣代理商通路的每一台,除了手持式之外都有HEPA功能。
Dc25的其他特點,如吸力永不減弱、沒有消耗品、不會排出廢氣、全地板適用…等,基本上大部份的dyson都有。
看完以上小文章,再來個快速提醒。
1.先決定要不要買。如果是,請看2。
2.決定要買直立式(看3)或是圓筒式(看4)。
3.只能買dc24了,結案。
4.家裡的坪數,大的(看5)或是小的(看6)。
5.大的請買dc22,結案。
6.小的請買dc26,結案。
最後,如果你真的買了,請一定要看說明書,因為這種高級的玩具設計的處處用心,使用最佳方法可以得到最佳效果。還有HEPA濾網每3個月需要用水洗一次,算是保養,沒洗會怎麼樣,等過了幾年我再告訴你。
如果還是買不下去,相信你有克勤克儉的美德,讓我們再從另一個管道下手。找一台來比價…我找的是dc24 allfloor,美國官網售價$399.99,以1:30換算,約是台幣$12,000,台灣官方售價$21,500…能殺價的空間有限,這一來一往之間,台灣人不是被坑殺了嗎?不過亞馬遜或是bestbuy都可以買到$279.99美左右的,換算台幣是$9,000,再加上運費…,不過不含保固,是另一個方式。
2011/01/07
開發 facebook apps 筆記
最近開始玩 facebook 應用程式的開發,
也就是在 apps.facebook.com 上所有的網站都算是。
之前想要玩 android ,
不過 android 的版本實在是變得太快了,
連買手機的人都可以感覺得到,
想要著手開發程式更是覺得困擾,
想說等它穩定一點再來玩玩,
就先跳到 facebook了。
沒想到 facebook apps 變動的更快,
而且連官方說明也是非常的簡略,
並且官方曾經公佈的 api 也很容易就又全盤的推翻,
實在是很意外,
曾經挾著數億會員而公佈標準的公司,
這種官方文件說明有點讓我傻眼了。
首先,
經過了幾個波折,
目前繁體中文的書籍,
我找得到的只有2本。

其他如果真的很有閒又有錢的話,
也是可以買一本介紹使用者介面的書來翻一下,
雖然只要認真的玩個幾天,
就知道 facebook ui 了,
但是這一類的書還不少,
所以請大家努力消費,
刺激台灣的內需市場。
如果想要買關於 facebook 行銷的話,
我覺得就不用了,
因為這不是看個一、兩本書就可以理解的,
重要的是對於網路的熟悉度。
我是用 php 當作畫布頁的,
當然還有 使用了 javascript SDK,
其他的申請應用程式流程,
就上網搜一下就有了。
不過先來講一下應用程式的兩種方式,
一種是 fbml ,
一種是 iframe。
fbml 就是在你的網頁中使用類似於 html 的 fbml 標籤,
然後在應用程式在 facebook 的伺服器就會去取得標籤,
重新把 fbml 改寫成 html 的方式呈現。
而 iframe,
真的很好理解,
就和 html 中的 iframe 是一樣的東西。
上述的2本書都有提到 iframe 和 fbml 之間的不同,
不過都是讓人有聽沒有懂。
而且2者都寫了 iframe比 fbml 容易學,
其實我覺得 fbml 比較容易學,
原因就是只要照著 fbml 操作,
呈現出來的東西是固定的,
即然固定…不就是比較容易嗎?
不過之所以有「iframe比fbml容易」的說法,
應程是指 iframe 不需要再另外使用 fbml,
直接使用 html 就可以了。
所以我一直被上面的說法誤導了,
等我都試過2種之後,
有以下的幾點心得。
像是我們常玩的 flash 遊戲即是,
基本上 facebook 只是提供基本資料給應用程式,
其他工作都是由應用程式自己去作業的,
像是 flash 遊戲的話,
最重要的是使用者認證之外,
還有就是朋友清單、發佈權限,
除此之外…都和 fb 沒有關係了。
所以幾乎世界上和 web 有關係的程式都可以開放 fb應用程式,
像是官網有列到的 php、python、javascript、ios、android,
還有官網沒列到的…太多不想寫。
決定要用什麼語言來寫並不困難,
畢竟常人了不起學了1、2種語言,
說好是常人的嘛!
不過世界上還是有很多精通10幾種語言的怪才,
(畢竟邏輯是一樣的)
怪才的困擾讓怪才去承擔就好,
我只會一種不太在行的 PHP,
所以完全沒問題。
問題是在現在正是 facebook 應用程式換季大拍賣之時,
就是舊的還可以用,
新的也可以用,
不過我個人認為…要嘛都用舊的,
要嘛都用新的,
不然組合起來,
原始碼實在是亂到一個極限。
新的 api 支援文件實在精略,
舊的一樣精略,
不過網路資源集中在舊的 API,
但是舊不如新,
所以我一開始就盡量採用新的 API。
新的 API 如 graph api、javascript SDK、 dialogs,
舊的有 Old REST API、Old JavaScript Client Library…等,
半舊不新的如 FBML->不建議使用的,
所以說呀!
很多方法可以用,
上網 google 時…就很難指定新舊之分了。
不是我不會用搜尋…是關鍵字都很接近。
也就是在 apps.facebook.com 上所有的網站都算是。
之前想要玩 android ,
不過 android 的版本實在是變得太快了,
連買手機的人都可以感覺得到,
想要著手開發程式更是覺得困擾,
想說等它穩定一點再來玩玩,
就先跳到 facebook了。
沒想到 facebook apps 變動的更快,
而且連官方說明也是非常的簡略,
並且官方曾經公佈的 api 也很容易就又全盤的推翻,
實在是很意外,
曾經挾著數億會員而公佈標準的公司,
這種官方文件說明有點讓我傻眼了。
首先,
經過了幾個波折,
目前繁體中文的書籍,
我找得到的只有2本。
其他如果真的很有閒又有錢的話,
也是可以買一本介紹使用者介面的書來翻一下,
雖然只要認真的玩個幾天,
就知道 facebook ui 了,
但是這一類的書還不少,
所以請大家努力消費,
刺激台灣的內需市場。
如果想要買關於 facebook 行銷的話,
我覺得就不用了,
因為這不是看個一、兩本書就可以理解的,
重要的是對於網路的熟悉度。
我是用 php 當作畫布頁的,
當然還有 使用了 javascript SDK,
其他的申請應用程式流程,
就上網搜一下就有了。
iframe & fbml
不過先來講一下應用程式的兩種方式,
一種是 fbml ,
一種是 iframe。
fbml 就是在你的網頁中使用類似於 html 的 fbml 標籤,
然後在應用程式在 facebook 的伺服器就會去取得標籤,
重新把 fbml 改寫成 html 的方式呈現。
而 iframe,
真的很好理解,
就和 html 中的 iframe 是一樣的東西。
上述的2本書都有提到 iframe 和 fbml 之間的不同,
不過都是讓人有聽沒有懂。
而且2者都寫了 iframe比 fbml 容易學,
其實我覺得 fbml 比較容易學,
原因就是只要照著 fbml 操作,
呈現出來的東西是固定的,
即然固定…不就是比較容易嗎?
不過之所以有「iframe比fbml容易」的說法,
應程是指 iframe 不需要再另外使用 fbml,
直接使用 html 就可以了。
所以我一直被上面的說法誤導了,
等我都試過2種之後,
有以下的幾點心得。
- fbml 是由 facebook 伺服器再幫忙編譯過的,所以風格和 facebook 網站非常相近,幾乎就是一模一樣;由此,如果是想要擁有自己風格的網站,就直接使用 iframe,因為選用了 fbml 開放,還需要再由 css 去調整,等於是加了一道手續。
- iframe 在寬度在官方文件中的公告是 760px,不過萬一超出來,各家瀏覽器預設的 scroll 寬度至少需要再加 15px ,算於是作業的範圍只剩下 745px。我試過了 ie、firefox、chrome,最寬可以使用到730px沒問題,不過為了美觀,我都以720px 去設計。其他如opera、safari這2應該相去不遠。
- fbml和 iframe 都需要由 api 去取得使用者資料,這一個判斷式通常是
if(is使用者){ 進入程序; } else{ 顯示登入網頁; }在官方 developer 的程式設定中,
就有範例可供參考。
不過隨著 php 環境的不同,
還是有一些需要調整的地方,
最重要的是… - curl
- json
- session 以上應該是 PHP 伺服器必備的, 不過我試過幾家免費php虛擬空間服務, 都可以讓我們無法開放 facebook, 不知是故意或是巧合。 如果無法使用, 試試把 php 的 session_start(); 用上。
- 在 fbml 中,
只要一經過認證,
無論是轉到應用程式的哪一頁,
都可以記錄使用者的session。 - 在 iframe 中利用官方範例的 rest class ,
也可以記憶使用者,
不過有少數 session 會因環境的關係無法由 api 記憶,
這時候自己寫一個會比去了解 facebook class 還要快。 - 在 iframe 時這可以利用一個 xhtml技術,
就是做用 javascript 把部份的 fbml 標轉譯在 iframe 之中,
不過可以轉譯的標籤並不是全部的 fbml。 - 基於官方網站將在今(2011)年第一季停止新應用程式設定為 fbml 版,
所以我會直接選用 iframe 作為所有應用程式的方式。
多重方法的困擾
有很多方式可以開放 faceboook 應用程式,像是我們常玩的 flash 遊戲即是,
基本上 facebook 只是提供基本資料給應用程式,
其他工作都是由應用程式自己去作業的,
像是 flash 遊戲的話,
最重要的是使用者認證之外,
還有就是朋友清單、發佈權限,
除此之外…都和 fb 沒有關係了。
所以幾乎世界上和 web 有關係的程式都可以開放 fb應用程式,
像是官網有列到的 php、python、javascript、ios、android,
還有官網沒列到的…太多不想寫。
決定要用什麼語言來寫並不困難,
畢竟常人了不起學了1、2種語言,
說好是常人的嘛!
不過世界上還是有很多精通10幾種語言的怪才,
(畢竟邏輯是一樣的)
怪才的困擾讓怪才去承擔就好,
我只會一種不太在行的 PHP,
所以完全沒問題。
問題是在現在正是 facebook 應用程式換季大拍賣之時,
就是舊的還可以用,
新的也可以用,
不過我個人認為…要嘛都用舊的,
要嘛都用新的,
不然組合起來,
原始碼實在是亂到一個極限。
新的 api 支援文件實在精略,
舊的一樣精略,
不過網路資源集中在舊的 API,
但是舊不如新,
所以我一開始就盡量採用新的 API。
新的 API 如 graph api、javascript SDK、 dialogs,
舊的有 Old REST API、Old JavaScript Client Library…等,
半舊不新的如 FBML->不建議使用的,
所以說呀!
很多方法可以用,
上網 google 時…就很難指定新舊之分了。
不是我不會用搜尋…是關鍵字都很接近。
- 官方的範例程式,
裡面拉拉雜雜的用了很多技術,
例如說明文件所指出的 Old REST API、Old JavaScript Client Library(最新的稱為 javascript SDK),
在我開始準備時,
官方文件已經指出不建議使用 REST 和 JavaScript Client Library,
所以我直接就不考慮了。 - 現在使用的 graph 和 rest 相比,
rest 多了很多功能,
像是在 facebook 使用者的個人牆上自定一個區塊,
或是可以多增加選單之類的,
現在多不支援了,
所以我直接使用 graph api。 - 另外 fql 是應用程式可以先向系統要求一些資料,
如使用者的朋友表列之類的,
但只限一次。
取得使用者的授權之後,
使用 graph 也可以無限次數向系統要求回報使用者個資,
所以也比 fql 好用。 - 取的使用者的大頭照十分重要,
因為「大頭照」與其代表的「人」是 facebook 組成的重要單位,
所以我會一直讓應用程式盡可能使用「大頭照」來替代使用者自己和他的朋友,
fbml和 graph都有很快的方法。 - 身為一個應用程式,
瘋狂的讓使用者 PO 文到他自己及朋友的頁面留言十萬分重要,
畢竟這是宣傳應用程式唯2的方式。
另一個方式是花錢買廣告。
不過所有的po文都應用由使用者同意後執行,
不然狂轟猛炸的誰受得了,
馬上會被 fb 停權。
學習的流程
我來講一下我個人認為需要學習的東西:- 使用官方範例,看一下裡面到裡是發生什麼事了。
- 一定要用 iframe,這樣引用 js 的時候會比較自由。
- 使用 graph api,並且試著查詢所有的資料,就知道 fb 也沒有給我們很多東西。
- fb 只是幫我們認證使用者,並且跟我們講他是誰,有哪些朋友。
- fb 中請求使用者授權給應用程式取得或是代發訊息的方式,有很多種,只需要學習一種,不然很浪費時間。
- 在 iframe 中最重要的是不要重覆 redirect回facebok,不然卡在哪裡,如果是使用 js 轉頁的話,在 ie 中好像會出錯,又是ie。
- 另外不相干的事,使用uml,加速架構程式,因為 facebook 可以提供的真的不像想像中的多,所以加上自己的資料庫是需要的。
訂閱:
文章 (Atom)

