計畫著 部落格搬家 也已經有一段時間了，卻一直沒有時間去付諸實行， 直到前兩天因為不小心把原本的網站弄壞才剛好藉這次機會把他搬出來。
原本只是因為沒事做想要把 wildsky.cc 搬到 blog.wildsky.cc 而已， 結果出了點差錯，而我的 phpmyadmin 又怪怪的登不進去沒辦法手動修改， 手邊有的備份就只有已經丟在垃圾桶裡的 Jekyll-export.zip，無奈之下只好開始動工。
原本是打算把 blog.wildsky.cc CNAME 到 wi1d5ky.github.io 那邊去， 直接用 GitHub-pages 提供的 Jekyll 來做事，但後來 WM 跟我說有個東西叫做 surge， 而我又剛好想要學新東西，所以現在這個部落格才用 middleman 下去做， 原始碼可以在 GitHub 上找到。
來說一下這次搬家的心得好了。
事前準備要做足，且不要到最後一刻才下定決心。
由於這次搬家的起因是個意外，所以我的 wildsky.cc 一度停擺， 當中造成的損失或許現在不會太多，但未來發展到一定規模後可能不容許這麼長時間地停止運作。 應該要無痛轉移，確定好 blog.wildsky.cc 後再把 wildsky.cc 轉過去， 而原本的東西也能保持他最初的模樣，做個弔唁紀念之類的。
既然起因是意外，就要盡可能讓意外的發生機率降到最低， 因為我以前很喜歡對我的 Android 上下其手（？），所以也常常會不小心讓手機變磚， 後來會先確定好一切準備工作就緒後才開始動手。 可能是太久沒有刷手機了（太久沒有變磚了）忘記那種失去的痛苦，才會造成這次的悲劇。
該是找時間來重操舊業的時候了。
搬家很痛苦，尤其是留言部份
手刻版型花了我不少時間，不過這次改用 SASS 下去寫（過去都是用 Scss），算是一個新的嘗試， 或許改天我會把手邊某個正在用 Scss 的專案改寫成 SASS，並把這個部落格用 css-next 改寫， 畢竟這是用 middleman 的好處之一——可以用 Jekyll 的東西，也可以用 npm 世界的資源。
至於留言部份，這個網站是使用 Disqus 系統，他應該是根據網址來記錄哪個夜面有哪些留言， 這本身沒有什麼問題，但因為我一方面換 domain name，另一方面又將文章的網址格式調整從 /{title}/ 變成 /posts/{title}.html， 結果就導致過去的留言全部 memory leak（？），目前還沒有想到解決辦法， 雖然 Disqus 有提供 Migration Tool，但距離我按下去那個按鈕已經過了兩天了，他還是一樣連不過去， 目前是打算把他 export 出來，手動更改（隨便找個編輯器取代一下），然後再 import，不知道可不可行，如果還是無法的話就只好算了。
沒有了後台，也沒有分析工具
過去用 wordpress 的時候，他後台的首頁有個地方會顯示哪一篇文章很常被點擊，就可以大概分析 Target audience 的喜好。 但轉移到現在這個靜態網站後，別說分析工具，就連後台都沒有。 目前除了這個分析工具工具的消失讓我稍微有感外，其他好像都不是什麼大問題。 就安全性來看也是往好的方向發展，慢慢體驗。
不過這可能是個讓我玩玩 GA 的契機，有空來用用看。
版型，版型，版型
這個版型不是我設計的，是從一個以前很喜歡的 wordpress 主題改過來的 😛 2007 年的設計到現在還是讓我很喜歡，但因為原本的設計我覺得不太平衡（沒錯我超愛對稱） 所以還是把一些我覺得不需要的東西拿掉，並稍微修改了一下手機版面，就變成現在的主題了。 之後應該還會再繼續修改，前提是我有時間的話 :S 原本設計的網址如下：
http://www.mono-lab.net/demo/flat/
Middleman 和 Jekyll 的比較
這個部份我可能沒有什麼好說的，未來對有 Middleman 有更深入的了解後可能會寫一篇文章出來，這邊就簡略地提一下目前的感想。 現在部落格用到的東西都是 Jekyll 可以做到的，像是版型和內容分開、用 Front-matter 來記錄各頁面的資訊、或是用 Markdown 來寫文章， 各式各樣的變數以及可以使用 if/else 或是 for loop 來產生頁面，如果有學過 Jekyll 再學 Middleman 會有許多熟悉感，當前感想如下：
1. Middleman 的全站變數很難用
若要使用 Middleman 的全站變數，就必須要特地在專案資料夾的根目錄開個 data 資料夾， 再用資料檔格式（.json, .yml… etc）來儲存資料，使用 {{site.data.[資料黨名稱].[變數] }} 來存取之。
相較之下，Jekyll 只要在 _config.yml 設定變數，就能直接以 {{ site.[變數] }} 來取值，輕鬆愉快，乾淨舒爽。
2. Middleman 的文件沒有 Jekyll 詳細
這個問題讓我很痛苦，或許是因為前者的使用人數沒有後者那麼多，所以相較之下比較沒有人力去寫文件， 很多東西都要在茫茫網海中搜尋，沒有方向的亂找著實令人有些頭疼， 即便 WM 有給我 osdc.tw 做參考，但資訊界的技術日新月異， 有些兩年前能用的東西現在都不能用了，再加上 Jade 我看不太習慣，只好努力慢慢啃別人問過的問題了，就當做是關鍵字的敏感度的訓練吧。
順帶一提，在爬文的過程中也有找到 Middleman 的論壇，不知道 Jekyll 有沒有類似的東西。
3. Middleman 的 build 好久，圖片應該外置
其實這一點不算是他們兩個的比較，因為我平常用 Jekyll 都是推到 GitHub 上給他跑，所以沒有用過他的 build， 但因為 Middleman 要產生靜態網站到 surge 上去，所以必須要先在本機端 compile 後才能丟出去。 不知道是我的文件太多還是怎樣，每次 compile 的時候都跑很久，雖然他會偵測檔案有沒有變動，但還是要一個一個慢慢跑， 應該有什麼方法可以加快速度，但我現在還沒想到。還有一個影響因素等等會提到。
關於 Surge
就是因為有這個東西的存在我才能用 middleman 來跑部落格，他其實沒什麼特別的，就是一個靜態網站的 host 平台而已，這裡簡單介紹一下：
npm install --global surge
只要用上面這個指令就可以裝好他的命令列工具，而使用的方法也很簡單：
surge
他就會先確認你是否要把[當下目錄]丟到[特定 doamin]，你也可以直接指定目錄名稱：
surge build/
這樣就不用再確認目錄位置，如果在要丟出去的目錄中有 CNAME 這個檔案的話，他就會直接往那個方向丟，連 Domain 都不用確認。
因為每次都要下指令有點煩，所以我就直接在 config.rb 的最後面加入這一段程式碼:
after_build do |builder|
exec "surge build"
end
這樣一來他就會在 跑完 middlema build 後直接跑 surge build，懶人的福音！
繼續把剛剛抱怨到一半的「build 好久」抱怨完，其實會覺得他跑很久不是 middleman 的問題，是 surge 造成的。 他每次都會重新把我的所有的檔案丟上去伺服器，而不管哪些文件壓根都沒動過，這真的很耗時間，先不說文件量——畢竟一個文件了不起給你 500kb 就很大了， 比較困擾的是圖片，一張兩張不是什麼問題，但一拖拉庫真的很恐怖，以後部落格的圖片還是放在 flickr 或是其他地方好了。
尾聲碎碎念
部落格搬家 真的是一件累人的事情⋯⋯ 下次真的要乖乖備份再來亂改東西。
參考連結
更多關於這個網站的經營的文章，可以見： http://blog.wildsky.cc/categories/部落格經營/