First delete and re-clone the repo using the new address:
cd to [shared folder]
rm -rf cached-copy
git clone ssh://git@example.org/new/repo.git cached-copy
Then modify your config/deploy.rb to use the new repo:
set :repository, "ssh://git@example.org/new/repo.git"
set :scm, :git
set :deploy_via, :remote_cache
And finally deploy:
cap deploy
solved :)
ref: here
某個專案的每日更新是依賴第三方的資料，但第三方更新的時間常常 delay 或甚至一天更新兩次XD
於是苦命的碼農就必須
雖然只有幾步，不過就是不爽啊!!
不過自從使用了 Cape 之後，就變成
人生豁然開朗，又再次變成彩色der
廢話講完了，以下是說明
大前提是使用 Capistrano 部署
gem 'cape', '~> 1'
require 'cape'
Cape do
# 將 :link namespace 下的 tasks 都接過來, 或是直接 mirror_rake_tasks 就會接全部的 tasks
mirror_rake_tasks :link
end
cap link:my_awesome_link_task
btw 如果有 rake task 撞名的問題記得用 rename 閃過~
iTerm2 是 OS X 裡最好用的 terminal 軟體, 強大的自訂功能一直深受使用者喜愛.
Zsh 則是取代 bash 並且擁有 oh-my-zsh 豐富擴充能力及多樣的 theme 的 linux shell.
一般來說在 iTerm2 裡只要將 Profiles 裡的 Keys 使用 Load Preset - xterm with Numeric Keypad
就可以正常使用九宮格鍵.
可惜在使用 Zsh 的情況下還需要多一步才能讓九宮格的 Enter 鍵作用.
在這個畫面選取 num - (enter 符號)並雙擊該項目
在彈出視窗的 Keyboard Shortcut 直接按下 九宮格的 Enter 鍵
按下 OK 並重啟 iTerm2 (或開新分頁), 即可正常使用九宮格的 Enter 鍵
早上在 maintain 一個小專案的時候發現之前 ok 的 rake task 竟然動不了
一行行偵錯才發現是死在這裡
photo = Photo.new
photo.remote_file_url = "PHOTO_URL"
而錯誤訊息則是可惡的 SystemStackError: stack level too deep ( which is 有說跟沒說一樣)
不過既然是掛在 photo.remote_file_url 這邊，那勢必和 PhotoUploader 有關
於是進了 rails console 直接 new 一個 photo 物件看看
想不到出現一堆警告訊息
RMagick.rb:44: warning: already initialized constant XXXXXX
(下略一百行
okay, 這下知道兇手可能是 RMagick
用 Rmagick warning 問狗, 馬上得知因為 Gemfile 裡如果是這樣寫的話, RMagick 的 constant 會自動 initialize 一次
gem 'rmagick'
而在 PhotoUploader 裡因為我們需要對圖檔進行操作, 所以也加上了這段
include CarrierWave::RMagick
卻導致 RMagick 又再次 initalized
解法其實很簡單, 只要將 Gemfile 改成這樣即可
gem 'rmagick', require: false
如此一來 RMagick 就只會在 PhotoUploader 被叫起的時候才 init
靈異現象結案.
最近在重讀人月神話，其中第七章 ”巴別塔為什麼失敗？” 某種層面上和我的工作經驗產生了聯結，我們先來看看書中怎麼描述巴別塔這傳說中的巨大工程專案。
巴別塔的故事寓意深遠，由不同的角度可以得到不同的啟示，但是我們在此純粹是以工程專案的觀點，來看看巴別塔可以帶給我們哪些管理上的教訓。巴別塔具備了多少成功的條件呢？他們是否有：
- 明確的目標？ 有。雖然這是痴心妄想，但遠在人類所能達到的極限之前，它就宣告失敗了。
- 人力？ 很多。
- 材料？ 美索不達米亞蘊藏著豐富的黏土和柏油。
- 足夠的時間？ 也有。沒有任何證據顯示有時間上的限制。
- 充分的技術？ 這不成問題。金字塔或圓錐型結構本身就很穩定，可以很有效地分散壓力的負載，磚石建造技術顯然也很成熟，但這項工程早在達到技術的極限之前，就宣告失敗了。
為什麼萬事皆備卻仍然失敗呢？是不是還缺少什麼？答案有二 溝通 以及隨之而來的 組織
人與人不能彼此交談，就無法合作，當合作失敗，工作就陷入停頓。從故事中可知，缺乏溝通將導致爭執、誤解、集體猜忌，很快地，整個團隊就會分崩瓦解，各自為政，最後就連吵也不想吵了，選擇孤立。
回到現實世界，曾經在某公司裡，不知道從什麼時候開始，公司領導人喜歡和每個人單獨談心，然後打探其它員工的工作狀況，也許以為這樣就可以掌握全局。可惜員工並不吃這一套，尤其在口口聲聲的夥伴之下，公司的營利狀況、方向決策、甚至是股份配置，都是謎樣的存在。由於錯誤的溝通方式，造成員工情緒上的不愉快，各種猜忌和誤解不斷產生，最後公司發生離職潮，後話又是另一回事了。
當團隊開始失去信任，最好的辦法並不是各個擊破，而是在太遲之前，開誠佈公，和所有人一次把目前的狀況說明清楚。
不要害怕團隊會因為經營狀況沒有起色而跳船，說白一點，就算有人因此而離開，他也不值得被視為夥伴。
但如果因為對內部隱瞞狀況，而造成誤會並失去原本可能成功的契機，這才是領導人真正應該避免的。
懶人如我, 在 shell 裡設定了各種 alias, 包括cd to projects folder (pro), cd to Downloads folder (down)之類的 "alias shortcut"
用起來雖然方便但如果是在頻繁增加專案目錄的時候, 難道每次都要寫 alias 或認命 cd 移動嗎 ?
幸好有神人寫出這支 z.sh, 讓我從此大大減少 cd 來 cd 去的時間.
z 的核心概念是, 他會記錄並計算你 cd directory 的次數, 然後給予每一個 directory 對應的 rank. 而當你輸入
z PATTERN
的時候, z 會按照 rank 開始 matching PATTERN 並進入該 directory.
這樣子在目錄間移動便順手許多, 也減少了很多 cd 找目錄的時間.
關於 z 的更多使用方法, 請參考 github z 的頁面
Linode 上碰到第二次了, 先記下來
據說語系檔不見或沒設好, 會導致 Vim 炸掉...
這樣你的 git 相關指令會有比較清楚的顏色區別
原文連結在此 Lifehacker
恭喜你擁有一套正版且免費的 iWork !
把以下這段丟到 application.rb 裡
config.assets.precompile.shift
config.assets.precompile.push(Proc.new do |path|
File.extname(path).in? [
'.html', '.erb', '.haml', # Templates
'.png', '.gif', '.jpg', '.jpeg', '.svg', # Images
'.eot', '.otf', '.svc', '.woff', '.ttf', # Fonts
]
end)
