山に来てBoxenやめてAnsibleにしました

気がついたら前回の退職エントリーから10ヶ月ぐらい何も書いてなかった。よくない。
最近あんまりネットにいませんね、とか(元々そんなにいなかったのに)言われるようになってた。よくない。

初心に立ち返って、環境構築のこと書く。

具体的には、boxenをやめてansibleにした話。

boxenを使ってきたけど、結論としては個人の環境構築に使うにはtoo much。使い始めた時点でうすうす感じてはいたことだった。

なんか一個brew upgradeしたいだけなのにpuppet moduleに手を入れなきゃならないのはコストがかかりすぎだし、boxen自体をour-boxenからfetchしてmergeしてアップデートしていくのもダルいし、それを他のところ（チームとか）でも使うならまだしも、自分しか使わないのであれば、新しいパソコンに毎回環境構築するほうが楽だと思った。

あとは、色んなものが/opt/boxen/の下に入るのがちょっと気持ち悪かった。brew installした時のインストール先とかわかりにくかった。

そんな感じでbrewfileにでも移行しようかと思っていたら、使ったことないうちにオワコンになってた。
じゃあどうすっぺーかと思っていたところで、今をときめくansible(僕の中で)をlocalで実行するという手があるとわかったので、そうすることにした。


boxenのhomebrew使ってた場合はboxen消すとhomebrewも消えるので、ansible導入後にまたbrew installするものはbrew listとかで洗い出しておくといい。

boxen関連のものを完膚無きまでに削除

$ /opt/boxen/repo/script/nuke --all --force

改めてHomebrewとAnsibleをインストールする

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ brew install ansible

ansibleをローカルに実行したい場合、playbookのhostsに127.0.0.1を指定してやって、実行時に--connection=localをつけるか、playbookにconnection:localと書いてやればssh経由でなく実行される。
参考: http://docs.ansible.com/playbooks_delegation.html#local-playbooks

そういうわけであとはplaybookを作って育てていけばいい。大抵の場合はlocalhost.ymlが1ファイルあるだけで事足りるんじゃないだろうか。

inventoryファイルに関しては普通に作ってやってもいいし、ansible-playbookするときに -i "localhost," とかつけてやると作らなくても済む。

あとはlocalhost.ymlを育てていけばよい。


適用するときには

$ ansible-playbook localhost.yml -i "localhost," --ask-sudo-pass

のようにすればよし。

たぶん、最初から入ってないと大幅に使い勝手が変わったり困ったりするものって僕の場合はそれほどないので、それ以外のものは必要に応じて手で入れるようにして、dotfileとかtmuxとか、インストールして設定するのがめんどいものを自動化しておくのがいいバランスなんだろうと思う。

Boxenの導入

準備が出来たので、Boxenを導入する。

前提として、Xcode Command Line Toolsがインストールされていること。
(Mavericksの場合はBoxenがいいようにしてくれるっぽいが、僕の場合は既にインストールしてあったので実際どうなるのかわからない)

https://github.com/boxen/our-boxen#bootstrapping に書いてある通りにやっていく。

あらかじめどこかに自分のboxen用のgitリポジトリを作っておいてから以下を実行。

sudo mkdir -p /opt/boxen
sudo chown ${USER}:staff /opt/boxen
git clone https://github.com/boxen/our-boxen /opt/boxen/repo
cd /opt/boxen/repo
git remote rm origin
git remote add origin <自分のリポジトリ>
git push -u origin master

用意されたモジュールだけで事足りる人はむしろ少数派だと思うので、必要に応じてPuppetfileの末尾に利用するモジュールを追加してやる。
大抵のメジャーどころはhttps://github.com/boxenにある。

Puppetfileはダウンロード元等の定義に過ぎない。Puppetfileに続いてmanifestを編集する。
globalな設定はmanifests/site.pp に、personalな設定はmodules/people/manifests/githubのユーザー名.pp に書く。この辺は仕様ではなく流儀。

(んーしかしPuppefileの存在意義ってなんなんだろう。上みたいな形でグローバルな設定と個人の設定は切り分けられてるわけで、各種定義もそこでやればいいのでは……)

これで

cd /opt/boxen/repo
./script/boxen

すれば諸々インストールやら設定やらされる。

尚、デフォルトだとFileVault使ってディスクを暗号化することを要求される。それが嫌な人は--no-fdeをつけてやればいい。

./script/boxen --no-fde

.bashrcか.zshrcが既にある場合は、以下を追加する

[ -f /opt/boxen/env.sh ] && source /opt/boxen/env.sh

シェルを新しく開いて、boxen --envがちゃんと動けば正しくできてる。動かなければ頑張る。

参考: Boxenを利用したMacのセットアップ | iii ThreeTreesLight

Boxenの導入(の準備)

新年、明けましておめでとうございます。

今年一年を良い年にすべく、Boxenを使ってみることにしました。

準備

boxenと干渉する可能性があるものをアンインストールする。
僕の環境ではrbenv, homebrew, nvm。なんとなく影響が小さそうなものから消していく。

nvmのアンインストール

公式にアンインストール方法が書いてなかった。

とりあえず.nvm/を消す。

% rm -rf ~/.nvm

あとは.zshrcにも数行書いてあったのでそれも消した。

rbenvのアンインストール

rbenvはbrewでインストールしたので、homebrewごと消せばいいのかもしれないけど、一応ちゃんと消す。

rbenv管理のrubyを消すには、~/.rbenv/versions/ の中にあるディレクトリを消すか、ruby-buildを使っているならrbenv uninstallで消せる。
これもわざわざやらなくていいような気はしたけど、パッチレベルも低かったのでついでに消した。

で、rbenvとruby-buildをアンインストール。

% brew uninstall ruby-build
% brew uninstall rbenv
% rm -rf ~/.rbenv

なんかよくわからないけど一回やっただけだとちゃんと消えず、何回か実行したら消えた。

homebrewのアンインストール

https://github.com/Homebrew/homebrew/wiki/FAQに書いてあった、このスクリプトを使った。

実行したら何故かiTermのタブが閉じたりしてちゃんと消えたのかよくわからない。
which brewとかしてcommand not found: brewとか出るようになったので消えたと信じる。

これでようやく準備が整った。

JavaScriptのテスト環境を整える その3

その1 その2

モジュール単位でファイル分割する。RequireJS使う。

前々回からのbower.jsonを編集。dependenciesにrequirejsを追加する。

{
    "name": "zakuni-js-template",
    "version": "0.0.3",
    "main": "main.js",
    "ignore": [
        "**/.*",
        "node_modules",
        "components"
    ],
    "dependencies": {
        "requirejs": "latest"
    },
    "devDependencies": {
        "mocha": "latest",
        "chai": "latest"
    }
}

色々と試行錯誤した結果、こうなった。

.
├── bower.json
├── camera.coffee
├── camera.js
├── components
│   ├── chai
│   ├── jquery
│   ├── mocha
│   └── requirejs
├── index.html
├── main.coffee
├── main.js
└── test
    ├── test.camera.coffee
    ├── test.camera.js
    ├── test.coffee
    ├── test.html
    └── test.js

index.html用のメインと、テスト用のmainは別のファイルにする(main.jsとtest.js)。
あと、テストもモジュール単位で分ける(camera.jsのテストはtest.camera.jsを作るようにする)。
mocha.setupとかmocha.runはtest.jsで行う。

中身はこういう感じになっている。


https://github.com/zakuni/js-template/tree/v0.0.3
RequireJS使おうとしたら時間かかってしまって最終的にちゃんと整理しきれなかった感があるので、そのうちまたまとめ直すかもしれない(しないかもしれない)。

JavaScriptのテスト環境を整える その2

前回の続き。

あとやりたいことは、CoffeeScriptを使ってる時でも同じようにテストを書けるようにするのと、ファイル分割。
どちらを先にやるかだけど、後でわざわざ書き直すめんどくささもさることながら、それで動かなくなって悩むのは嫌なので、Coffee化を先にやることにした。
前回のmain.jsは

var a = 1;

だけだった。
これをCoffeeScriptで書くと

a = 1

となるわけだが、これをコンパイルしたmain.jsを使うようにするだけで、前回書いたテストは通らなくなる。

なぜかというと、CoffeeScriptから生成されるJavaScriptは、無名関数で囲われていて、グローバル汚染を防いでくれている。
つまり、先ほどのmain.coffeeをjsにコンパイルすると

こうなるので、変数aには外部からアクセスできず、ReferenceErrorになってしまう。

尚、コマンドラインからmochaを使ってテストする分には

% mocha --compilers coffee:main.coffee

みたいにすると中でうまいことやってくれてcoffeeでもテストを通すことができる。
(今回書いてるやつそのままでは通らない。-uオプションでtddを指定したり、chaiをrequireする必要がある)

前回は素のJavaScriptの話だったのでブラウザで実行することを重視したけど、CoffeeScript書いてるならnpmも使ってることが多いだろうし、それなら素直にコンソールでmochaを使えばいいような気がする。

そして気づいたけど、前回使ったbowerはインストールするのにnpm使ってるだろうから、ブラウザにこだわる必要はないような気もしてきた。
ただ、mochaとかchaiをファイルでダウンロードしてきて使う人とかもいるだろうと思えば、意味はあるので一応続ける。

無名関数の中で宣言されているのでアクセスできないことについては色んな解決方法があると思う。
簡単な方法の一つは、windowオブジェクトのプロパティにしてしまうこと。

window.a = 1

テストコードは変えないままグリーンになる。

というわけでこういう風に書ける

ここではやってないけど、テストもcoffeeで書けばいいと思う。

そしてひと区切り。あとはファイル分割する。

ここまでまとめたやつ。
https://github.com/zakuni/js-template/tree/v0.0.2

JavaScriptのテスト環境を整える

クライアントサイドJavaScriptでBackbone.jsとかのフレームワーク使いつつrequire.jsでファイル分割しつつ、更にそれらをCoffeeScriptで書いていた場合にテストを書こうと思ったら軽く発狂しそうになったので、一つずつ解決していくことにした。

個人的な趣味等を鑑みて前提条件は以下のような感じになった。
・CoffeeScriptでも同じような構成で使える
・ファイル分割できる
・テストがブラウザ上でも動作する

自動化は今回の範疇にはない。

後からテストが書きづらかったということに端を発するので、テスト駆動で開発する。

% bower install mocha

mochaを選んだ理由は、expect.jsとかQUnitとかと組み合わせやすそうなことと、ブラウザとコンソール両方で動かせるのと、Nodeでも使えるから。
npmじゃなくbowerでインストールしているのは、クライアントサイドのことはなるべくクライアントサイドで完結させたいので、なるべくNodeと切り離したいのがあるから。

mochaのサンプルを見ながらテスト用ページのひな形を作る。mocha.setupをbddでなくtddにしたのは趣味の問題。

これをブラウザを開いてみると、passes: 0 failures: 0 duration: 0s とか出てるはず。

assertionのために別のライブラリを使う。色んな書き方に対応してるChaiを使ってみることにした。
あと、ここでbower.jsonを作った。

% bower init

ちょっと編集する。
mochaもchaiもテストで使うものなのでdevDependenciesに入れた。

{
  "name": "zakuni-js-template",
  "version": "0.0.1",
  "main": "main.js",
  "ignore": [
    "**/.*",
    "node_modules",
    "components"
  ],
  "dependencies": {
  },
  "devDependencies": {
    "mocha": "latest",
    "chai": "latest"
  }
}

HTMLを編集して、テストを書く。

これでブラウザリロードして、グリーンになってればOK。

namespace的なこととか考えないならたぶんこれで充分テストを書いていける。
ひとまずここで一区切り。

ここまでをまとめたのが以下のもの。
https://github.com/zakuni/js-template/tree/v0.0.1

chef-solo使い始める

さくらのVPSで使ってるUbuntuをまた壊してしまって直らない。
それならいっそ何度再インストールしようが痛くないようにchef使っておくことにした。

knife-soloを入れる。

% gem install knife-solo

何故かやたら時間かかった。

Chefレポジトリを作成する。

% knife solo init chef-repo

作成はされたけどwarningが出てた。

WARNING: No knife configuration file found

設定しておく。

% knife configure

色々聞かれたけどとりあえずreturnを連打してデフォルト設定にした。

とりあえず練習を兼ねてnginx用のクックブックを作る。

% cd chef-repo
% knife cookbook create nginx -o site-cookbooks


そうすると site-cookbooks以下にnginxフォルダとか出来る。

site-cookbooks/nginx/recipes/default.rbを編集して、

package "nginx" do
    action :install
end

とか書くと、サーバーにこのレシピを適用したときにOSの違いとか吸収してnginxをインストールしてくれるはず。

クライアント側からサーバーにchefをインストールさせることができる。

knife solo prepare user@host

sshと同じように -i とか -pとか -Pを付けて実行できる。

この時のユーザーはsudoできるユーザーじゃないといけない(たぶん)。

上の例だとクライアント側のnodesフォルダ内にhost.jsonっていうJSONファイルが生成されているはず。
こいつを編集してやって、どのレシピを使うかを指定する。

{"run_list":[]}

とかなってると思うので、こうする。

{"run_list":["nginx"]}

そしてサーバーにレシピを適用する。

% knife solo cook user@hoge

prepareの時と同じで、ここでもsshで接続するときと同じようにオプションを指定する。

ここまで正しくできてればnginxがインストールされる。
同じように他のレシピも作っていく。

MacRubyでCocoaPodsのインストールができなかった

CocoaPodsをインストールする。

普通のrubyでもいいらしいが、macrubyのほうが相性が良さそうな気がするのと、元々macrubyで使おうと思っているのでrbenvでmacrubyに切り替えてgem installする。
尚、rbenvとかrvmじゃないときはmacgem installする。

% gem install cocoapods

 あとこれも必要

% pod setup

 そしたらエラーが出た。

fork() function is unimplemented on this machine

とか出てる。ええー?

よくわからんので一回普通のruby1.9.3でgem installとpod setupしたらすんなりいけた。ええー?

rvmからrbenvに乗り換え

年越し環境構築を。
rvmからrbenvに乗り換えてみる。

まずはrvmをアンインストール。
rvmをアンインストールするにはrvm implodeもしくはrvm seppukuコマンドを使う(切腹ってなんだよ)。

% rvm seppuku

zshrcとかに書いてあるrvm関連の行も消す。

続いてrbenvとruby-buildのインストール、Homebrewで。

% brew install rbenv ruby-build

eval "$(rbenv init -)" をzshrcとかzshenvとかに書く(僕はzshenvに書いた)。

rbenv installでrubyをインストールする

% rbenv install 2.0.0-preview2

自分でコンパイルして ~/.rbenv/versions/ に置いてやるんでもいいらしい。

追記:
ruby2はMacデフォルトのopensslとは互換性がないとかなんとか。
https://github.com/sstephenson/ruby-build/issues/197

なのでopensslもhomebrewでインストールして、rubyもオプション付けてインストールし直した。

% brew install openssl
% brew link openssl
% RUBY_CONFIGURE_OPTS=--with-openssl-dir=`brew --prefix openssl` rbenv install 2.0.0-preview2

2013/04/21 追記
readlineも指定してやらないとirbとかpryで日本語使えなかった

% brew install readline
% CONFIGURE_OPTS="--with-openssl-dir=`brew --prefix openssl` --with-readline-dir=`brew --prefix readline`" rbenv install 2.0.0-p0

インストールしたら、rbenvでは以下のコマンドが必要になるそうな。

% rbenv rehash

rbenvではこれをよく使うらしく、新しくrubyをインストールしたときとか、実行可能なgemをインストールしたときにもrehashしてやらないといけないらしい。
(rbenv-rehashっていうgemを各rubyに入れておいてやることで勝手にやってくれるようになるらしいが、まあなんとなく鬱陶しいな)

デフォルトで使うrubyのバージョンはrbenv globalで指定する。

% rbenv global 2.0.0-preview2

β版的なものをデフォルトにするのは止めたほうがいいと思う。

尚、MacRubyに関しては、rbenv-macrubyというプラグインがあり、こいつを使えばMacRubyもrbenvで管理できる。

[Mac]Guardによる自動テスト

久々に環境構築おじさん的なことを。

これまでRSpecとautotest(zentest)を使ってたのだけど、最近はみんなminitestだな、とかなんとか聞いたのでminitestも使ってみる。
で、自動実行するためにGuardを使う。Rails4とかで使われてるのかな?

gemspecに書いてbundle install

gem.add_development_dependency "guard-minitest"

もちろん普通にgem installしてもいいし、Gemfileに書いてもいい。

Guardfileという設定ファイルを生成するために

% bundle exec guard init minitest

Guardfileの基本的なところについては割愛。

ファイル保存のタイミングでテストするためにrb-fsevent使う(WindowsとかLinuxの場合はほかのものを使う)

gem.add_development_dependency "rb-fsevent"

テスト書いて、

% guard

すると、ファイル保存のたびにテストされる。


以下、Growlで通知させる話。

gem growlを使う。

gem.add_development_dependency "growl"

を追加して、bundle installしてguardし直す。

が、通知されない。

Growl2.0になって、GrowlNotifyを入れてないせいだった。
http://growl.info/downloads#generaldownloads からダウンロードしてインストール。

改めて

% guard

適当にファイルいじって保存してテストを走らせる。

通知出た。
が、何故か1回ファイル保存するごとに2回ずつ通知される。
よくみたらテスト自体が2回ずつ実行されてる。

Guardfileにguard 'minitest' do endが2個あった。
guard init minitestをしたときに、Gemfileがあるならbundle execしたほうがいいんじゃない?って出力されたのでもう一回bundle exec guard init minitestしたらGuardfileに追記されていたせいだった。

もう一回guard initしてみたら3個になって、

There are 3 definitions in your Guardfile for 'minitest', you may want to clean up your Guardfile as this could cause issues.

っていうのが出てた。2回目のときにも出ていたんだろう。
必要ない分を消したらちゃんと1回だけ実行されて通知も1個になった。

[Mac]Scalaで日本語使う

日本語を出力しようとしたら文字化けした。

JAVA_TOOL_OPTIONS='-Dfile.encoding=UTF8' をつけて実行すれば文字化けしない。

% JAVA_TOOL_OPTIONS='-Dfile.encoding=UTF8' scala hoge.scala

.zshrcに以下を追加。

export JAVA_OPTS="-Dfile.encoding=UTF-8"

REPLでも日本語使えるようになるけど、書いて消すとズレたりするありがちな感じになる。

参考: Scala, Mac and -Dfile.encoding=UTF-8 - Kato Kazuyoshi

Playをインストール & Play Scala動かす

最近は仕事とかいうものにかまけていたせいでブログを書いてなかった。

% brew search play

したらplay出てきたけど、こういう一般的な言葉が名前だと合ってるのか不安極まりない。

% brew info play

play 2.0
http://www.playframework.org/
Not installed
https://github.com/mxcl/homebrew/commits/master/Library/Formula/play.rb


どうやら合っているようなのでインストールする。

% brew install play

なかなかの重量級なようでダウンロードにも時間がかかった。

と思ったらインストールが終わってた。ディレクトリを移動しただけだったようだ。


とりあえずJavaには興味がないのでScalaのプロジェクト作る

% play new calas --with scala

そしたらなんか聞かれた

What is the application name?
> calas


え?calasって言ったじゃないですか。ご丁寧にデフォルトでcalasって入ってるし。

まあプロジェクト名とアプリ名は違うこともあるか。しょうがないしょうがない。

Which template do you want to use for this new application?

1 - Create a simple Scala application
2 - Create a simple Java application
3 - Create an empty project

>


え?Scalaでって言ったじゃないですか。しかも今度はデフォルト入ってないし。
1番を選択。(2番だとどうなるんだろう)

できたら動かす

% cd calas
% play run

やけに時間がかかった。初回の初回だからか？

ポート9000で動いているようなのでlocalhost:9000にアクセス。
Playの公式サイトと同じような画面が表示される。

これはしかしなかなかの全部入り感でいじるにはちょっと萎えますね。
3番選ぶとよかったのかな。

Ubuntu + Passenger + Nginx インストール

Rubyはrvmで入れた1.9.3。

% gem install passenger
% rvmsudo passenger-install-nginx-module

そしたら
Curl development headers with SSL support... not found
って出た。

足りないのはこれだけだったので、指示に従ってインストール

% sudo aptitude install libcurl4-openssl-dev

そして改めて

% rvmsudo passenger-install-nginx-module

途中、選択肢が出るので選択する。人生は選択の連続。

インストール先も設定できるが 、何のこだわりもないのでデフォルトの /opt/nginx 。
設定ファイルの場所は /opt/nginx/conf/nginx.conf になる。

編集する。

pid /var/run/nginx.pid;

server {
listen 8080;
server_name hogehoge.jp;

# publicを指定するらしい
root /var/www/hogeapp/public;

passenger_enabled on;
}


Nginx-init-ubuntuの起動スクリプトを/etc/init.d/nginxにコピペ&ちょっと編集。

DAEMON=/opt/nginx/sbin/nginx

NGINX_CONF_FILE="/opt/nginx/conf/nginx.conf"

にする。

% sudo chmod a+x /etc/init.d/nginx
% sudo update-rc.d -f nginx defaults

参考:
Rails 3 on Ubuntu 10.10 with RVM, Passenger and Nginx « theKindOfMe
Ubuntu 10.04 TLS に nginx + passenger + sinatra を入れたメモ(1) - Moderation is a fatal thing. Nothing succeeds like excess.
Ubuntuに、passenger-install-nginx-moduleした « blog.udzura.jp

Vimでrbファイル作成時にマジックコメントつける

参考: Rubyのエンコード指定マジックコメントを##<esc>で挿入できるようにした - LazyLoadLife

~/.vim/templates/rb.tpl を作成。
中身はマジックコメント

#!/usr/bin/env ruby
# -*- coding: utf-8 -*-

で、~/.vimrc に以下を追加。

autocmd BufNewFile *.rb 0r ~/.vim/templates/rb.tpl

自動生成したファイルとか、既存のファイルにつけるにはこんなのがあった。
https://github.com/m-ryan/magic_encoding

Pryで日本語入力できるようにする

pryの読み方って「ぷらい｣なんですね。「ぷりい｣って読んでた。

% rvm pkg install readline

するとreadlineが /Users/zakuni/.rvm/usr とかにインストールされるので
そいつを使ってrubyをreinstallする

% rvm reinstall ruby-1.9.3 --with-readline-dir=/Users/zakuni/.rvm/usr

これでPryで日本語入力できる。

参考: irbやpryで日本語を入力できるようにする - IwazerReport

Vimの日本語入力がおかしかった

vimで日本語を入力しようとすると、入力してる途中で確定されてしまい、変換前のひらがなとアルファベットが入り混じることがあった。

コメントで入力しようとすると大丈夫だったりするのでAutocomplpopあたりが怪しい気もするのだけど、とりあえず以下で解決した。

.gvimrcにこれを追加

set imdisable

AutoComplPopをほんの少しいじる

tabで補完するために以下を.vimrcに書く。

"<TAB>で補完
" {{{ Autocompletion using the TAB key
" This function determines, wether we are on the start of the line text (then tab indents) or
" if we want to try autocompletion
function! InsertTabWrapper()
        let col = col('.') - 1
        if !col || getline('.')[col - 1] !~ '\k'
                return "\<TAB>"
        else
                if pumvisible()
                        return "\<C-N>"
                else
                        return "\<C-N>\<C-P>"
                end
        endif
endfunction
" Remap the tab key to select action with InsertTabWrapper
inoremap <tab> <c-r>=InsertTabWrapper()<cr>
" }}} Autocompletion using the TAB key

でしばらく使ってたんだけどしっくり来ない。

補完の第一候補が最初から選択されているので、returnキーならそのまま確定するのだけどtabを押すと二個目が選択されちゃって戻ったりしなきゃいけない。

これはストレスなので.vim/bundle/AutoComplPop/autoload/acp.vimの中身を見て、

function acp#onPopupPost()
  " to clear <C-r>= expression on command-line
  echo ''
  if pumvisible()
    inoremap <silent> <expr> <C-h> acp#onBs()
    inoremap <silent> <expr> <BS>  acp#onBs()
    " a command to restore to original text and select the first match
    return (s:behavsCurrent[s:iBehavs].command =~# "\<C-p>" ? "\<C-n>\<Up>"  : "\<C-p>\<Down>")

の部分をこう書き換えた

function acp#onPopupPost()
  " to clear <C-r>= expression on command-line
  echo ''
  if pumvisible()
    inoremap <silent> <expr> <C-h> acp#onBs()
    inoremap <silent> <expr> <BS>  acp#onBs()
    inoremap <expr> <CR> pumvisible() ? "\<C-Y>\<CR>" : "\<CR>"
    " a command to restore to original text and select the first match
    return (s:behavsCurrent[s:iBehavs].command =~# "\<C-p>" ? "\<C-n>\<Up>\<C-n>"  : "\<C-p>\<Down>\<C-p>")

最後のところは<Up>と<Down>を消すだけでもいいけど、なんとなく消すのが嫌だったのでこうした。
これで、tabを押したタイミングで第一候補から選択、returnは補完があろうがなかろうが改行になった。

参考:
autocomplpop.vimでリアルタイムにキーワード補完 - ナレッジエース
autocomplpop.vim -自動補完プラグイン- « Labs@doya.in

Vundleを使う

EmacsとVimの二刀流になるべくVimをメインに使い始めて数カ月。

プラグインを入れるのにはpathogenを使っていたのだが、どうやら近頃はVundleなるもののほうがよさげ。というわけで乗り換える。

というかpathogen使ってるのに、プラグイン追加するときgit submodule addとかするのすっかり忘れてた。意味ねー


ドットファイルをgitで管理しているのでsubmoduleとして取り込む

% cd ~/dotfiles
% git submodule add http://github.com/gmarik/vundle.git .vim/bundle/vundle

.vimrcに記述

filetype off

if has('win32') || has('win64')
  let $DOTVIM = expand('~/vimfiles')
else
  let $DOTVIM = expand('~/.vim')
endif
set rtp+=$DOTVIM/bundle/vundle/
call vundle#rc()

" let Vundle manage Vundle
" required!
Bundle 'gmarik/vundle'

" My Bundles here:
"
" original repos on github
Bundle 'tpope/vim-fugitive'
Bundle 'Lokaltog/vim-easymotion'
Bundle 'rstacruz/sparkup', {'rtp': 'vim/'}
Bundle 'tpope/vim-rails.git'
" vim-scripts repos
Bundle 'L9'
Bundle 'FuzzyFinder'
" non github repos
Bundle 'git://git.wincent.com/command-t.git'
" ...

filetype plugin indent on " required!

後半を編集して自分の入れたいものを書く。

先に:BundleInstall!してVundle自体を最新にしておいたほうがいいかも。

書いたらVimを起動して:BundleInstallすると書いたものが~/.vim/bundle/にインストールされる。

参考:
Vim-users.jp - Hack #215: Vundle で plugin をモダンに管理する
Vim のプラグイン管理を pathogen から Vundle に移行した - present
gmarik/vundle - GitHub

各種設定ファイルをgitで管理する

.emacsとか.vimrcとか.zshrcとか、それらをまとめて管理することにした。

dotfilesフォルダを作って、各種設定ファイルを突っ込み、個別にシンボリックリンクを貼る

こんな感じ

% mkdir ~/dotfiles
% mv .emacs dotfiles/
% ln -s dotfiles/.emacs ~/.emacs

で、dotfilesフォルダをgitで管理する。

Node + Nginxの設定をする

見よう見まねで設定。やたら手こずってしまった。

ExpressアプリをNginxで動かす。

/home/zakuni/hoge/ にapp.jsがあり、それをhogehoge.comで動かしたいとする。

% sudo vi /etc/nginx/sites-available/hoge

/etc/nginx/sites-available/hoge

server {
  listen 80;
  server_name http://hogehoge.com;
  access_log /var/log/nginx/hoge_access.log;
  error_log /var/log/nginx/hoge_error.log;

  location / {
   root /home/zakuni/hoge/;
   index /;
   proxy_pass http://localhost:3000;
  }
}

リンクを貼る

% sudo ln -s /etc/nginx/sites-available/domain1.com /etc/nginx/sites-enabled/domain1.com

nginxを再起動。

% sudo /etc/init.d/nginx restart

参考：
nginx @ ウィキ - nginx　バーチャルホスト
nginx設定メモ - おおにしあきらの日記
node.js + nginx - And now? - Stack Overflow