mr.mu

jQuery Mu Image Resize 縮圖裁切外掛

mrmu — Mon, 07 May 2012 06:28:15 +0000

為網站內的圖片產生縮圖，已經是非常普及的應用了，不過這通常是透過後端程式來處理，動用到的也是Server的資源。不過某些情況下，我們希望在前端將縮圖的問題處理掉，而今天要介紹的jQuery Plugin – Mu Image Resize 就是為此而生的。為何需要縮圖裁切(resize with crop)？圖片好好的為什麼要進行縮圖及裁切？如果圖片本身的尺寸跟網頁想呈現的圖片尺寸不同，我們就會想縮放這張圖片，而通常縮放後若原圖比例跟網站需要的縮圖比例不同，就會造成比例失真的問題：因此我們需要對圖片作縮放及裁切，讓它可以依照正確的比例及尺寸顯示於畫面上。在後端or前端進行縮圖在後端進行縮圖的情況，可能是內容由我們自己產生，圖片的所有權是我們的，因此可以這樣處理。但若內容是由第三方網站產生的，圖片根本不在我們家，這時候若要由後端縮圖，就必須要把內容整個抓回我們的Server，再進行縮圖處理。如果我們並不打算把內容整個打包回家，而是直接在畫面上顯示，這時若要作縮圖，就只能透過前端 javascript 的協助了。前端縮圖的限制後端縮圖通常是「真的」將圖片縮小及裁切成另一張圖片，其中也許有進行檔案讀寫的動作。但前端限制很多，不能進行檔案I/O，縮放圖片的大小也許還行，但要裁切圖片，就必須要使用其他的技巧。因此，在這個Plugin中，我是使用 CSS 的 Clip 屬性來作裁切效果。試玩jQuery Mu Image Resize外掛這是我第一個放上Github的小程式，使用方式很簡單，只要將js檔加進來，加上以下script就行了：就這樣，這裡有Demo可以看看，有任何問題再麻煩回報了。到 Github 下載jQuery Mu Image Resize

用ChromePHP 探索 WordPress 佈景主題的運作機制

mrmu — Wed, 11 Apr 2012 11:25:59 +0000

也許你用了一陣子 WordPress，也拿它來開發了許多專案，對於 WordPress 底層的運作有點概念，但一直沒有機會更清楚地理解TMD到底裡頭是發生了啥事，那麼這篇文章也許可為你的探險之路開啟一扇窗。因為專案需求，我用 ChromePHP 寫了一個 wordpress 的小plugin，主要是為了觀察WordPress佈景裡頭的每個頁面，到底暗中執行了哪些SQL，還有WP內建的那一堆常看到的global變數 (像是$wpdb, $post…) 又到底被放進了哪些東西。 ps.如果你只是拿WP來做一些小網站，未來也不太有機會拿 WordPress 做中大型的網站或開MU做深度應用，那就可以先別往下看了，因為內容我想應該不太適合你XD。安裝後的效果是？先來個看圖說故事好了，在安裝這個小plugin之前，必須先裝 chromePHP ，注意，這一切都只支援Google Chrome瀏覽器，裝完後你的Chrome右上角就會出現它的小圖示，記得開啟它：安裝我自己寫的這個小plugin後 (或者把code寫在functions.php當然也行) ，開啟任何一頁 WordPress 網站頁面，打開 Chrome 的開發工具 (網頁上右鍵>檢查元素)，點選"Console"頁籤，就可以發現這個頁面的底層做了啥事XD (一個普通的twenty-ten佈景首頁，就執行了38個大大小小的SQL queries，不過我的本機環境有開mu，所以應該會比較多一點)：目前基本的就是查看有多少Loop，執行了多少次SQL，總時間及最耗時的SQL查詢也會列出。展開圖中的「SQL查詢詳情」，就可以看到所有在此頁面執行的SQL的明細：再下一張是Loop裡的主角-WP_Query物件的內容，因為例子是在首頁，所以可見到 is_home 是 true：如果你看過twenty-ten佈景的原始碼，對WordPress Loop的運作也有基本的了解，你就會知道為啥這個頁面開出來會有兩個Loop，在此就不贅述。然後，如果你進入的是單一頁面 (is_singular為true，就是像頁面(page)，文章(post)等這種單一頁面)，還可查看 $post 裡有啥鬼東西： Plugin的實作方法本想直接放下載連結，但目前還不夠滿意，所以先放上可呈現上述效果的code，有興趣的朋友可以慢慢tune成自己要的工具，或等我有空將plugin發佈出來。首先你的 wp-config.php 需要加上：接著請去剛提到的 http://www.chromephp.com/，下載 ChromePHP.php，放進你目前所使用的佈景目錄裡的 lib目錄。(lib目錄自行建立即可) 再來就是要加入的code，以下預設為你將它加在 functions.php 先試玩：就這樣，謝謝收看，記得按讚XD。

WordPress Customize 佈景自訂頁 (wp 3.4新功能)

mrmu — Thu, 05 Apr 2012 06:36:46 +0000

WordPress 即將推出的 3.4 版，最大的特色就是為佈景設定加入了自訂(Customize)功能，本文則是以 3.4 beta 版來試用這個功能。為了增加這個全新的佈景自訂功能，WP核心建立了一個新的 Class 叫 WP_Customize，未來將可預期會有更多相關應用的API出現。又一個佈景設定頁面？目前大多數較為專業的WP佈景主題，通常會自帶所屬的後台設定面板，那為何WP核心還要提供一個佈景自訂的功能？從佈景自訂這個功能的設定原理來看，WP是偵測一些預設的佈景程式碼設定(如register_nav_menu()、add_theme_support() )來自動產生相對應的自訂設定頁。也就是說，善用WP核心提供的API來製作佈景前、後台的頁面，將會自動讓設定出現在佈景自訂頁上，這樣也許不一定便於佈景開發者，但對使用者的使用習慣則是有一定的好處。 WP Customize 自訂頁初體驗安裝WP 3.4後，從後台的「外觀」>「佈頁主題」進入，就會發現每個佈景的下方連結多了一個「自訂」(暫譯，原文為Customize)，點擊後就會進入佈景自訂頁面，左側是設定區，右側則是佈景預覽區。我們可先從佈景自訂頁左邊的設定區開始看起，這裡大概分為六個小區塊，由上而下分別是(以下中文為暫譯)：佈景資訊區塊包含名稱、縮圖及作者，展開後還有更詳盡的描述，這跟佈景主題頁的佈景資訊來源是相同的，這個項目是所有佈景都會出現的預設控制項。網站標題及標語(Site Title & Tagline) 這裡有網站名稱及標語的設定，等同於後台的「設定」>「一般」裡面的頭兩項設定，此項目也是預設控制項。頁首(Header) 可以設定是否顯示頁首文字、設定頁首文字顏色、頁首圖片的變更/上傳/移除等。要顯示這項設定，該佈景必須支援custom-header，即是要利用 add_theme_support( ‘custom-header’, array(…略…) ); 這個語法來加入支援。另外也可再搭配 register_default_headers 放入一些預設的設定項目供使用者選擇。背景(Background) 背景相關設定，如背景色、背景圖片的上傳。要顯示這項設定，該佈景必須支援 custom-background，即是要利用 add_theme_support( ‘custom-background’ ); 這個語法來加入支援。導覽選單(Navigation) 這裡的設定是從「外觀」>「選單」借過來的，可以調整選單的設定。要讓此項設定顯示，必須佈景有用到 register_nav_menu()。靜態前頁(Static Front Page) 這裡的設定是從「設定」>「閱讀」的首頁顯示部份借過來的，可以設定首頁及文章頁面要使用哪個頁面。能不能出現其他自訂的設定？目前這六個區塊除了「佈景資訊」、「網站標題及標語」及「靜態前頁」三項為一定會顯示的預設設定外 (即使佈景只有style.css及空白的index.php也會顯示)，其餘的設定項目除了導覽選單要使用 register_nav_menu() 來生成外，其他兩項則是利用 add_theme_support() [...]

為什麼你不該使用WordPress Plugins？

mrmu — Fri, 30 Mar 2012 06:38:10 +0000

你也許常聽到有人說：我要幫我的WP網站更新一些功能，但我不使用任何 Plugins。相信很多人一開始使用WordPress時，也會這樣想：WordPress應該包含所有功能，為什麼我非得去使用Plugins來加入一些常見的功能？為何我需要去安裝Plugins來抵擋垃圾留言(spam)？為何我需要額外去安裝SEO套件？為何WordPress不一開始就把這些好用的功能都收錄進來？當這些人用了WP一陣子後就懂了，因為我們不需要世界上最大的瑞士刀。上圖的瑞士刀有85個用途，但一般人根本不會想用它，在靈巧及功能性上它都已經失去了最佳的平衡。所以當我聽到有人說「我要做這做那、改東改西，但不使用Plugins…」我都忍不住去想這整件事根本是錯的，於是我問「為什麼不用Plugins？」，他們給了我一些神奇的原因，但我仍然堅持我的信仰：沒有工具是絕對需要被搞成 All-in-one，而且如果我把客製功能hard code的愈多，以後它將會愈難以更新或昇級。來瞧瞧有哪些不願使用plugin的原因： Plugins 不屬於「核心」的一部份，所以它不太可靠。不意外，應該很多人有這樣的疑問。的確，WordPress打造了一個很棒的核心，所以我們可以透過Hook機制來實行我們需要的功能，如果你覺得WP核心是可靠的，那Hook本身也值得被信任，Plugins的運作應該也是可靠的，所以真正的恐懼是： Plugins 的作者可能會消失我們都知道 WordPress Plugins 開發者很多都消失了XD，有些開發者甚至還有參與核心的開發。是的，作者可能消失，但如果你把WP Plugins當成所謂的軟體供應/支援商，那顯然是很危險的，你不該如此。讓我們看看HP平板電腦停產的例子，HP是個公認可靠又知名的公司，但總是沒人知道未來會發生什麼事。一間實體的大公司都可能無預警的關上它的大門，一支WP Plugin停止更新或作者突然消失，大概也不足為奇了。所以也許你也許真正想說的是： Plugins不安全我想知道上次你為你的WordPress網站進行全面的安全性檢驗是什麼時候？注意，我不是說plugins沒有安全性上的問題，但如果你有在運行你自己的安全性檢驗，而且安全性一直是你最關心也最害怕的一環，那你應該平等的一併測試整個WordPress核心、佈景主題及所有plugins的安全性。所以如果有個 plugin你真的很想要，你應該review它的原始碼，而不是閉著眼睛去使用，這也才是open source最具意義的價值。我們打開plugin的原始碼，也許看見base64()或者get()呼叫莫名其妙的東西，我們就能立刻知道它夠不夠安全，進而去修復或回報給org。但也許還有一些人還是覺得： Plugins 還是比較不可靠你也許又會說「路人甲的程式碼就是不可靠」。是的，沒有任何東西是完美的。核心也是另一群陌生人寫的，而且核心也是需要歷經很多人的測試 (如果你也有架WP，你也正在參與可靠性的測試)，即便有這麼多人在測試，不免還是有很多bug正在待解中 (我上週才剛發現2個官方證實的bug，只能workaround)。所以也許你真正想說的是：我自幹做出來的WP網站，那樣的程式碼才會「一碼永留傳」! 如果你不用plugins，選擇自幹，那有兩條路可以選擇： 1. 改核心 2. 改functions.php 如果你改核心，等於你的網站永遠陷入「自我手動更新」模式，這表示：永不能使用自動更新，必須親自review所有程式。如果你改的是functions.php，那比較好，畢竟它跟寫plugins的主要差別，只在於放置的目錄不同而已。把code放在functions.php，代表這個功能只能存在這個佈景裡，失去了重覆利用的好處。所以，就他X的用那該死的plugin吧! 難道任何情況都適合使用 Plugin嗎？當然不。 1. 如果沒有好的理由去使用plugin，就別用。 2. 如果它是多餘的，就別用。 3. 如果你正在練習寫code，就別用。還有什麼使用Plugin可能會有的壞處嗎？也許你會想到效能(performance)吧？的確有可能影響，但你自幹寫出來的code也可能有效能問題。使用正確的方法來撰寫plugins可以有效提昇網站的效能 (寬義來說，這也是WP核心的一環:D)，例如只在需要的時候才載入你寫的Hook Function (如只該出現在後台的就記得用is_admin)，或者把你的plugin主檔寫成loader。在處理佈景時，要達成某種效果雖然有很多種方法，但請儘量找到最正確的用法。(例如：別以為 the_content() [...]

廣義的 Responsive Design

mrmu — Fri, 30 Mar 2012 02:13:28 +0000

Responsive 就字面上的意思來看是指「有反應的」，而 Responsive Design 即是指「有反應的設計」。先前本站介紹過的相關文章中，將 Responsive Web Design 譯成「自適應網頁設計」，一直到現在都覺得這樣的譯法怪怪的，原因是「自適應」字面上感覺是針對「顯示設備」的解析度，自我適應其解析度，讓網頁呈現適當的版面樣式。但就現在看來，不免有點太過狹義。這樣的譯法挶限了 responsive 的意涵，如果是比較本質性的討論什麼是「有反應」的網頁設計，就會發現「速度」是一個主要的關鍵。廣義的討論什麼是 Responsive Web Design，可以先看看GitHub的設計總監 Kyle去年發表的這篇簡報：http://warpspire.com/talks/responsive/。如此就不難發現為何node.js這類server端的js技術為何在近幾年變得火紅，原因就是「非同步」帶給使用者「感覺比較快」(feels faster) 的體驗，而不像PHP這類技術，一遇到問題就容易卡住，變得「沒反應」。除了速度還有URL的設計，這裡kyle提到HTML5 History API。History API是可以讓開發者自訂網頁「瀏覽歷程」的API。在無法自訂「瀏覽歷程」的情況下，使用javascirpt進行非同步資料存取時，使用者感覺好像進行了很多頁面的操作，但URL本身不會改變，這時若使用者按了「上一頁」，通常就會破壞他心中建立的歷程模型了。其實，不只是「上一頁」或「下一頁」的問題，還有重讀以及分享網址的問題，都會影響使用經驗。不過其實國外很多文章都把 responsive design 當成「自適應」的意義來使用了，因此狹義的用法也已被大眾接受，甚至出現專有名詞的感覺。不過思考一下原來的字義，會發現「有反應」的設計思考比起「自適應」的部份來得更加多元及有趣。

WordPress 台中趴踢樂

mrmu — Mon, 21 Nov 2011 06:23:47 +0000

Please upgrade your browser VIMEO: WordPress台中趴踢樂活動-WordPress還能怎麼玩？其實這是2011年的活動了，到了今年(2012)才補上。XD 實在是因為去年年尾+今年年初有點忙碌，因此活動結束後都好幾個月後了才寫文，真是不好意思。這是台灣第一次在台中舉辦的WordPress聚會，整體活動非常成功。我在活動中擔任講者，講述的主題是「WordPress還能怎麼玩？WP更多元寬廣的視野!」，主要分享的是WordPress網站的多元應用案例。會選擇這個主題，除了平常很多人問我到底WordPress能不能架xxx類型的網站，WordPress會不會不夠專業？是不是只能架部落格？…等等，主要原因是活動參與的朋友對使用WP的經驗不是很平均，所以就整理了許多不把WordPress拿來當部落格用的網站案例，拿來在這次活動中分享，希望能讓每一位與會的朋友都有所收獲。以下是簡報及實況影片。 WordPress 還能怎麼玩？更多元寬廣的視野! Please upgrade your browser

下個網站使用HTML5/CSS3來實作吧!

mrmu — Fri, 11 Nov 2011 13:45:35 +0000

不曉得身為網頁設計師的你，是否有考慮在下個專案開始使用HTML5/CSS3了呢？ HTML5/CSS3在2009年開始引發討論，並且在2010年開始至今年產出了非常多極具實用性的文獻及週邊應用。除了新標籤的使用方式外，最令人關心的應該還是老舊瀏覽器的支援度問題。但是這一年來已經有非常多的處理方法，可以幫助我們處理相容性的問題，即使IE系列支援度很差，但這也不該是讓我們躊躇不前的原因，大多數新標籤，也許舊版瀏覽器看不懂，但這並不影響瀏覽，況且也有很多處理工具可以解決，所以何不先從(正確地)加上基本的HTML5語意標籤開始？改版後的網站，在老舊的瀏覽器也許看起來很醜，在較新式的瀏覽器卻很酷炫，對使用者而言能產生很棒的推廣，也可以藉此機會向業主說明，IE佔有率的下降及HTML5在行動設備上的優勢(順便跟他提一下可上網的手機出貨量已經超過PC了)。也許讓網頁使用新的文件格式，對業主來說吸引力還是不夠強，但若是SEO呢？以本站為例，全站版型在2011年10月5日改以HTML5格式撰寫，一個月後觀察Google Analytics就發現每日流量平均就提升了25%。(下面是Google Analytics的截圖，週期性的「低谷」是周六與周日) 這裡是個小小站，但像T客邦的XDite也說改寫HTML5後，T客邦的日造訪流量多了1萬。這樣的例子，幾乎可證明HTML5格式非常益於SEO。不過會想寫一篇簡短的勸進文，主要是因為今天在Facebook社團「HTML5與CSS3在台灣」，有篇討論：針對這樣的現況，希望自己也能稍稍協助推廣一下。而且上圖這篇有很不錯的討論，社團裡也有非常多相當有用的新知，非常建議有心推行的設計師及開發者加入討論。有心想將版型改造為HTML5格式的WordPress玩家，也推薦近期香腸寫的HTML5改造系列文章! 最後，順便幫Facebook裡的WordPress正體中文社團打個廣告! 對WordPress架站有興趣的朋友，歡迎加入討論~

WordPress 台中趴踢樂，11/20台中見!

mrmu — Mon, 07 Nov 2011 02:49:59 +0000

自從今年5月份在台北舉辦了第一次的WordPress Party聚會後，10/15在台南也舉辦第二次WP一連兩天的聚會。在北部、南部都有過聚會後，終於中部也有一場了。活動訊息如下：活動名稱：WordPress 台中趴踢樂活動時間：2011年11月20日 (13:00~16:00，12:30 開放入場) 活動地點：黑貓月亮2F，台中市西屯區大墩二十街111號名額限制：25人 (就在寫本文寫到一半時額滿了XD) 活動費用：120元 (現場收費，飲料無限暢飲) 這次聚會講者有兩位，首先是在WP界頗有名氣的香腸，主題是「網站架設很困難？WordPress輕鬆一次幫你辦到好！」另一主題將由小弟介紹「WordPress還能怎麼玩？WP更多元寬廣視野」。雖然人已經滿了，但還是附上活動網頁，如果中途有人不克前來，也許還有機會一同參加XD：http://blogxd.com/WParty/ 另外WordPress台南場又有活動了! WordPress佈景行不行，名額有限，快衝吧!!

初學程式語言-先學個大概，再求精細

mrmu — Fri, 28 Oct 2011 07:51:19 +0000

因為最近時間還算許可，所以兼了一門基礎的程式設計課程。先前的教學主題，比較是放在大二、大三生稍微進階一點點的程式設計，但這學期要教的學生大多都是第一次接觸程式語言的朋友。雖然在備課上較為輕鬆，但每每回想起自己初次學習程式語言時的那種身處迷霧般的感受，不免還是會一直思考如何調整上課的方式，也因此產生了一些想法。本篇是討論如何提供程式設計初學者適當的教學內容，是我個人想法，也歡迎討論。自然語言也是這樣試想小朋友剛學說話時，我們通常不會教他一堆修飾詞、形容詞，而是希望他講出重點，即是先讓句子的實用性出現。例如：「媽媽，我想要溜滑梯，可以嗎？」，第一次教他當然不能期望他說得完整，而是先讓他從會說「溜」開始，當他指著滑梯說「溜」時，通常大人就知道怎麼回事了。當大人理解小朋友的想法，並作出正確的回應，小朋友也獲得了成就感，擁有了再次學習的動力。而我認為，一開始學習程式語言也應該要如此。傳統課堂上的教學通常的情況是，老師在檯上照本宣科，拿一本書從頭講解，也許在一開始談變數，就把所有它的形態、所佔容量都講完(甚至還要求背起來，考試拿來考)；其他章節也是，一開始就照著書本，把主題談得很詳細，老師本人覺得講得很完整，很有快感，但聽得人卻很痛苦，覺得還沒開始寫程式，就要記憶一堆不知為何物的知識，很複雜。為何這樣情況會很常見？我猜部份的原因是，這樣的教學方式，老師最輕鬆。這種情況下，對少數幾個原本就非常有興趣的同學來說，也許反而更加好奇，然後增加自修的時間去研究；不過往往我們最常見到的是，大多數有點興趣的同學會深深覺得「自己不是寫程式的料」，然後整個學期靠用「背」的來過關，然後從此放棄學習程式設計。「資管系學生，是不是都該跑去寫程式」，這個問題很有爭議，但若問題改為「資管系學生，是不是都該對程式有一定程度的認識」，我就覺得是必要的。先學個大概，再求精細也因為如此，這學期我只列了幾本參考書目，但沒有選定一本書。我覺得書是參考用的，很少能拿來依其目錄編排來作為主要的學習流程。因為每個人的學習狀況不太相同，最好的方式還是由老師動態調整路線。我上過某程式課，第一堂在電腦教室上課，卻都在解說課本上的東西，直到下課都沒讓我們實際操作玩一下，真的相當解High。為了避免一開始談一大堆無聊的東西浪費時間，這學期的策略是，先講最少最基礎的東西，讓學生前幾堂課就能一直寫程式。談到程式語言裡的「變數」，儘管VB裡有超過十幾個型態，但我只講Integer跟String，一開始學副程式也不會講到Call By Value 或 Call By Reference。我只求先讓它動，寫得很醜很隨便都沒差。前半個學期學的東西，都是以「最低可用」的標準來介紹，然後再依同學的問題開始發展之後的教學路線，除了依能力來學習，問得多的就學得多，老師也不用無謂的趕進度，因為我的目標不是注滿指定容量的水，而是試圖點燃火苗。也許整個學期下來，能講到的主題不會像傳統方式那麼多元，但卻是最依同學能力，最切合需求的初階課程，未來對程式這麼排斥的同學也就不會太多。至於原來就很有興趣同學，就更不必去擔心了。一堂課的學習成績依興趣、態度、智力，每個人的程度都不會相同，我不會作齊頭式的要求，而是看立足點。我這樣教，只是想讓入門的門檻低一點，讓更多同學不再害怕學習寫程式，而不是想把學不會或寫不好程式的人當掉。我完全允許學生「混」過關，只要乖乖參與課程、不作弊、有交作業、有來考試，通常我不會當人。但我更想做的是鼓勵學的好或學習態度好的同學。學的好，當然是高分，不過學得不怎麼樣的同學，如果態度非常好，而且有建立起興趣，我通常會給很大的鼓勵性加分。也許學生會問，配分不是一開始學期初就談好了嗎？是的，但是作業、期中、期末、平時這些都是可以動態調整的，而且老師想要它多動態就有多動態。有時我覺得，成績在我看來佔最重的是「印象分數」。「教學」是人的活動，我們在教育的是「人」不是「機器」，人的變數很多，這些變數是構成印象的要素，在我看來這比分數更適合評斷學習成效，我不會在乎你多背了幾個語法，但卻很在意你是如何解決問題，或是不是積極去學習。分數是死的，它代表的意義很少，硬要說的話，也許分數高可以讓一個人的機會變多，如果是這樣，那我願意把機會多給一些具備更多可能性的同學。

網頁設計中的多層視差滾動效果 (Parallax scrolling)

mrmu — Tue, 18 Oct 2011 17:51:02 +0000

觀察上面的圖片，裡面有三張圖片，分別放置於不同階層，如此可以構成一幅具有簡單景深的畫面。假設我們將三張圖作成由右向左捲動的動畫，但背景圖片動得比較慢，前景圖片動得比較快，我們就可以感受到較符合生活經驗的景深效果。這種效果稱為視差滾動(Parallax scrolling)，它是電腦圖學中一種特別的滑動特效技巧，首次出現於1982年一款叫Moon Patrol的遊戲，主要是用來摸擬3D效果。滾動視差的原理是把背景圖片的移動速度放慢，讓前景圖片移動較快，因而在2D畫面上產生多層次的佈景深度。把滾動視差應用在網頁設計上，也具有非常棒的視覺效果，而且只要使用jQuery外掛搭配CSS設定就可以幫助我們快速製作出含有滾動視差效果的網頁了，非常方便。本篇要介紹的Plugin是 Scrolling Parallax Plugin for jQuery，我依照它的範例，修改成一個Demo，可以觀察到有三層葉片都有不同的捲動速度，還有三個空白DIV也設定了不同速度，如此就可以模擬景深，非常有趣! 也可以看看「橫向捲動」的實例： http://www.indofolio.com/ http://ericj.se/ 這邊則是WDL整理的21個具有Parallax Scrolling效果的網站： http://webdesignledger.com/inspiration/21-examples-of-parallax-scrolling-in-web-design 參考資料：維基百科 – Parallax scrolling Scrolling Parallax Plugin for jQuery 官網