m.igrs.jp

Vimacs - VS Code で Vim と Emacs のいいとこどり

Sat, 14 Dec 2019 12:00:00 +0900

昨年からメインエディターを Vim から VS Code に移行したのですが、やはり Vim キーバインドからは逃れられず基本的には Vim 拡張を利用して過ごしています。

また普段の Vim ではインサートモード時に基本的な Emacs キーバインディングを使えるようにカスタマイズしているのですが、それは別途キーバインディングファイル（keybindings.json）をカスタマイズすることで実現できていました。

今回は、そんなニッチな設定だけど同じようなことをしている人は他にもいるはずだし、オススメのスタイルなのでぜひみんなにも使って欲しいという思いから VS Code 拡張を作ったので紹介します。

Vimacs for VS Code

VSCodeVim のインサートモードで基本的な Emacs キーバインディングを利用できるようにする VS Code 拡張です。（VSCodeVim のアイコンをベースにしてますが、作者から許可は得ています）

Vimacs for VS Code (Visual Studio Code Marketplace)
vscode-vimacs (GitHub)

Original Vimacs

Vimacs という名前ですがもともと Vim Plugin として同様の名前のものがありました。

コンセプトがほぼ同じということで for VS Code として名前を継承しつつ、よりシンプルな実装としました。

Why use Vimacs?

Vim の最大の特徴はノーマルモードやブロックモードにおけるキーバインディングにあると思っていて、学習ハードルは高いものの一度その操作に慣れるとテキスト編集ツールとしては右に出るものがないくらい強力なツールとしてその威力を発揮します。

一方、インサートモードの実装は非常にシンプルで、ノーマルモードで編集することを前提としているのでコンセプトとしては理解できるのですが、入力・修正を繰り返すようなテキスト編集を行う際に頻度の高いモード切替は煩わしく感じることがあります。

また、macOS のほぼすべてのテキスト編集コンポーネントではシンプルな Emacs キーバインドが利用できるようになっていたり、シェル操作でも Emacs ベースなものが標準的になっていたりすることもあって、文字入力においては Emacs キーバインドの方が慣れ親しまれたものとなっています。

ということで、Vim のインサートモードのときに基本的な Emacs キーバインディングが利用できるようにすることで両者のメリットをいいところどりしてちょっと幸せになれるハイブリッドスタイルを提唱します。

やりたいこと

ベースの環境としては VS Code を使いたい
カーソル操作は Vim キーバインドを使いたい
文字入力時は Emacs キーバインドを使いたい

-	命令	編集	入力
Vim	Command Mode	Normal/Visual Mode	Insert Mode
Vimacs	VS Code	Vim	Emacs

Vim がコンテキストごとに各モードを使い分けるのと同じよな感覚でに各エディターを使い分けるイメージです。

コンセプト

コマンド系のキーバインドは VS Code 標準のものを利用する
VSCodeVim をベースとして基本的にインサートモードのときだけ Emacs キーバインドを定義

できること

インサートモードで基本的な Emacs キーバインディングが使える
カーソル移動以外ではリージョン操作系にも対応
VS Code のコマンド入力やファイル選択のUIでも Ctrl+N, Ctrl+P などのカーソル移動に対応

てきてないこと

キーバインディングが重複定義されたときの優先順の制御の仕様がよくわかっておらず、意図通り動かないキーバインディングがいくつかある
- keybindings.json の方で再度定義したり邪魔なものを無効にしたりすることで回避している
Column Region Mode も実装してみたのですがまともに動いてなかったのでいったん取り下げてます

Pull Request お待ちしております

設定例

参考までに私の VSCodeVim 個人設定（settings.json）では以下のような設定となっています。Vimacs 独自の設定項目はとくにありません。

{
    "vim.useCtrlKeys": false,
    "vim.overrideCopy": true,
    "vim.hlsearch": true,
    "vim.useSystemClipboard": false,
    "vim.visualstar": true,
    "vim.handleKeys": {
        "<C-f>": true,
        "<C-b>": true,
        "<C-u>": true,
        "<C-r>": true,
        "<C-v>": true,
        "<C-[>": true,
        "<C-w>": true,
    },
    "vim.cursorStylePerMode.normal" : "block",
    "vim.cursorStylePerMode.insert": "line-thin",
    "vim.cursorStylePerMode.replace": "block-outline",
    "vim.statusBarColorControl": true,
}

その他注意点

VSCodeVim の Undo 履歴管理はちょっと挙動があやしいので VS Code 標準のキーバインド（Cmd+Z, Cmd+Shift+Z）を利用するのがオススメです

公開後の反応

昨年ひっそりリリースしてから1年以上経っているわけですが、ありがたいことに反応もあったようなのでいくつかピックアップしておきます。

#今日のVSCode
Extensionをながめていたらviemacsというすてきなものがあった。Vim+Emacsである。https://t.co/fQgcDc2pgz
— 結城浩 (@hyuki) January 11, 2019

なんと、あの結城先生が言及してくれているではないですか！！（感激）

VimacsはVimでEmacsｷｰﾊﾞｲﾝﾄﾞを使えるようにするやつだけど、VSCodeでVimのｷｰﾊﾞｲﾝﾄﾞをやるやつは活発に作られてるけど、Emacsのはなんか今いちだから（？）VSCodeのVimプラグインの上に乗っかったVimacsが出てきた…？
— Hideyuki Tanaka (@tanakh) July 18, 2018

理由はちょっと違いますが・・・

少ないですがポジティブなレビューはやはり嬉しいものです

Goodbye Vim?

Sun, 06 May 2018 12:00:00 +0900

前記事の続き。 Vim に関しては Mac よりも長い付き合いである。

主にコーディング用のエディターとして GVim をメインに利用してきたが、これまで新しいエディターが出ては試して、そして結局 GVim に戻っての繰り返しだった。

ここであえてコーディング用としているのは、コーディング用とライティング用とでエディターを使い分けているからである。

コーディング用
- プログラミング等
- 全体を眺めて考えたりする時間が長い
- 新規入力より編集が多い
- 日本語の入力が少ない
ライティング用
- メール・議事録・メモ等
- 思いついたらすぐ入力
- 新規入力が多い
- 日本語の入力が多い

ちなみに IntelliJ IDEA や Eclipse などの IDE はエディターとして含めていない。IDE とエディターは別物だ。

モダンエディターの登場

Vim / Emacs 以外の選択肢としてのモダンエディター的な存在は TextMate が走りだったと記憶している。イケてる Web エンジニアは Mac 使って Ruby on Rails でアジャイル開発していて、動画で紹介されるチュートリアルではなにやらモダンでいかにも便利そうなエディターを華麗に操り、このエディターとフレームワークさえ使えば誰もが幸せになれるのではないかと世界中のエンジニアが思ったものだが、その時のエディターが TextMate だった。

以降、登場したモダンエディターとしては以下が代表的なものとして挙げられるだろう。

TextMate (2004) Mac Only
Sublime Text (2008)
Atom (2014)
Visual Studio Code (2015)

どれも Vim に変わる存在としての可能性を探るために、それなりに使っては評価してきたが、1か月も続かないものばかりだった。リリース当初だけの評価ではなく、それぞれ継続的にメジャーバージョンアップが行われる度に乗り換えては評価してきた。

コーディング用のエディターに求めること

ここで僕がコーディング用のエディターに対して求めることを整理しておくと、以下がポイントとなる。

Vim キーバインド
軽量さ・軽快さ
クロスプラットフォーム
拡張性
将来性

そう、僕が一番大切にしているのは Vim ライクな操作ができるかどうかであって、結局 Vim からは脱却できていないのだ。

なぜ Vim を使い続けてきたかというと一番快適に Vim キーバインドが使えるエディターは Vim だったというだけの理由である。次点で、軽量さ・軽快さ・クロスプラットホームをクリアーしているからだ。拡張性・将来性に関しては Atom / VS Code あたりの方が高くみえるし、そうみえるから乗り換えようとしている。

最近のモダンエディターは質の差はあれど Vim ライクなキーバインドを実現するプラグインは大抵存在する。Atom に関してはどうも軽量さ・軽快さに欠けていたので、ひととおり条件をクリアーしてそうなエディターとして VS Code に可能性を求めることにした。（Sublime Text 3 に関しては最近評価できてないのでもしかしたら可能性あるかもしれないけど、現時点ではあまり興味ない）

Visual Studio Code の所感

まず軽量さについては、Vim のそれには圧倒的に劣るが他のモダンエディターに比べてもかなり軽い部類だ。拡張性については Vim に比べて用意されている UI コンポーネントが多いこともあって UI 的な表現力が高く、またそれを TypeScript で書けるのは Vim script と異なり馴染みがあってとっかかりやすい。 Vim キーバインドについては VSCodeVim がなかなか頑張っていて他エディターの Vim プラグインより出来がよい方だと感じたし、割と違和感なく使えるものになっている。

総合的な所感としては、Vim を超えているというよりは Vim が無くても生きていける環境がようやくできたという感触。一応コーディング用のエディターに求めるものはひととおり揃っていて、実際ここ1か月くらいはほぼ VS Code だけで生きていけている。

Visual Studio Code の微妙な点としては、

日本語の単語区切りに対応していない
VSCodeVim について
- undo / redo の挙動がおかしい
- Multi Cursor が考慮されてない

などがあって割とツラいのだがなんとかしのいでいる。

いざとなったら Open in Vim というプラグインがあるのでいつでも本物の Vim に逃げることはできる。

なので、暫く VS Code メインで使っていこうとは思っているが Vim も引き続き使っていくことにはなりそうだ。

Vim は不滅だ。

ライティング用のエディターについて

かなり特殊な例なのかもしれないけど、僕はコーディングの時は Vim、メール・メモなどの文章を書く時は Emacs を使いたいのだ。これもまた本物の Emacs である必要はなくて、Emacs キーバインドが使えれば良いだけなんだけど、これに関しての話もいろいろあるのでまた別記事で書きたいと思う。

Goodbye Mac and Vim

Sat, 05 May 2018 12:00:00 +0900

趣味的にいろんな OS やエディターに手を出しつつも、わりと長い間 Mac と Vim をメインの開発環境としてきたのだが、ここ最近その牙城が崩れ今ではすっかり Ubuntu と VSCode 中心な環境にシフトした。

わりと長い間というのは十数年なので僕のエンジニア人生の大部分を占めることになり、節目感じたので残しておく。

Mac に求めていたこと

僕が開発環境として求めていたのは一言でいうと、
「実用的な GUI を備えた UNIX 互換環境」
である。

当時(2000年代前半)、Windows + Cygwin (+ GVim) な環境で頑張っていたのだが、UNIX 互換環境としては制限が多く、一方その点においては完璧な Linux 系 OS も実用的な GUI を備えてなかったので常用するには厳しかった。そんな中、出てきた OS X(macOS)は両者を備えた環境として理想的で魅力的な存在だったし、ついでにカッコよかったので、Intel Mac の到来と共に僕は MacBook Pro を購入した。そしておそらく同じ理由で世界中の開発者もこぞって Mac を選び始めた。

求めるものの変化〜仮想化とクラウドの時代

時代と共に仮想化技術が発達し、開発環境として求めるものが UNIX 互換環境からコンテナ実行環境に変わってきた。 Docker for Mac などの存在はあるもののホストとのファイル共有において速度的なボトルネックが発生してしまうため快適に利用することは難しく、これは Windows においても同様である。となると選択肢としては Linux 系 OS に限られてきて、 Ubuntu でも Gentoo でも Arch Linux でもなんでも良いのだが一番使い慣れているということから今は Ubuntu を選択している。 GUI としては、Win / Mac には劣るものの、一昔前に比べて様々なものがクラウド化しブラウザさえあればなんとかなるものが増えてきていることもあって実用性としては低くはない。

ハードウェアとしての Mac

ハードウェアとしての Mac を考えてみると、Touch Bar が搭載されて以降、欲しいと思えるモデルがなくなってしまった。今では大多数の人が Mac を使う世の中になってしまったこともあり所有欲的なものも薄れてきた。一方、Windows マシンの方がバリエーション豊かでコストパフォーマンスもよく自分にあったマシン探しを楽しめる環境にある。（洗練された良いモデルは少ないが）

僕が今メインで利用しているのは Lenovo ideapad 720S (13.3インチ) だが 10万円切る価格で十分満足いくボディとスペックである。(できればメモリ16GB欲しいところではあるが)

エディターについて

常用エディターを GVim から Visual Studio Code にスイッチした件も書くつもりだったが長くなってきたので別に書くことにする。

Setup Jekyll and GitHub Pages Again

Fri, 20 Apr 2018 12:00:00 +0900

これまでさくらのVPSで運用していたのですが、更新忘れて契約が切れいつの間にかサーバ毎消えてしまっていました。 8ヶ月ほどサイトダウンしていたようです。それまで利用していた Octopress もすっかり息を潜めたのでこれを気に原点に戻って素の Jekyll ベースで構築し直しました。

構成

今回はメンテナンスレスにしたかったので GitHub Pages でホスティングすることにしました。

_site => ../migrs.github.io

のようシンボリックリンク貼って、コンテンツの出力先を GitHub Pages のディレクトリに設定しておき、あとは、

記事書いて
bundle exec jekyll build して
migrs.github.io で変更コミットして
git push

で記事の公開完了です。

最近、小ネタ溜まってきてるのでちょいちょい更新していこうかなと。

リポジトリ

Amazon EC2 で複数ホスト一括処理するなら ec2-pssh がとっても便利

Mon, 17 Feb 2014 10:00:00 +0900

（前記事の続きです）

複数のホストに対して同時にコマンドを実行するツールはいくつかあるのですが Amazon EC2 向けのものがなさそうだったので作ってみました。

できること

とある名前やタグが付いたインスタンスに一括でコマンド発行したり
とある Auto Scaling group や ELB に属したインスタンスのログを同時に眺めたり
とあるグループのインスタンス内の特定ファイルを一度に収集したり

いろいろ便利なことが簡単に実現できます。

Parallel SSH

まず前提として PSSH: Parallel SSH Tools を利用するので詳しくは pssh について詳しいページを参照のこと。

Mac 環境なら sudo easy_isntall pssh で入ります。

思想としては ec2-ssh と同じく極力シンプルにするため pssh の単純なラッパーコマンドとして実装しており利用方法やパラメータ等は pssh 互換です。一括処理するグループを指定するためオプションだけを加えてます。

オプション

-S / --as : Auto Scaling グループ名を指定
-N / --name : インスタンス名を指定(同じ名前のインスタンスが複数ある場合)
-T / --tag : タグを指定 (Key=Value)
-F / --filter : フィルタを直接指定 see. ec2-describe-instances
-L / --elb : ロードバランサー名を指定

使い方

ロードバランサー lb-web 配下に属するサーバ群のアクセスログを同時に眺める

ec2-pssh -L lb-web -P tail -f /var/log/nginx/access.log

Auto Scaling グループ名 as-api に属するサーバ群の負荷状況をリアルタイムで確認

ec2-pssh -S as-api -P vmstat 1

api という名前が付いたサーバのディスク利用率を一度に確認

ec2-pssh -N api -i df -h

等々

他の PSSH コマンド群

Parallel SSH Tools には pssh 以外にもいくつか便利コマンドが用意されているのですが、それらのラッパーも用意しました。

ec2-pscp (一括ファイル送信)
ec2-pslurp (一括ファイル収集)
ec2-prsync (一括ファイル同期)
ec2-pnuke (一括プロセス終了 pkill)

一括ファイル送信

ec2-pssh -N api -i df -h

一括ファイル収集

ec2-pssh -N api -i df -h

その他の付属コマンド

ec2-ssh (前記事参照)
ec2-host (インスタンス名解決)

hoge という名前の付いたインスタンスは誰？

ec2-host hoge

Auto Scaling グループ名 as-api に属する全てのサーバ名を取得

ec2-host -S as-api

ec2-host は他のコマンドとの組み合わせて使うと便利です。

cat ~/.ssh/id_rsa.pub | ssh -i ~/ec2.pem ec2-user@`ec2-host hoge` 'cat >> ~/.ssh/authorized_keys'

Amazon EC2 で SSH するなら ec2-ssh が便利

Thu, 14 Mar 2013 09:00:00 +0900

AWSを本格的に使い始めて約3ヶ月になる新参者です。便利過ぎて今までの時間を返して欲しいくらいなのですが過ぎたものは仕方ないので前に進みましょう。

EC2 への SSH 接続

Amazon EC2 上のインスタンスにSSH接続するベーシックな方法は

ssh -i /path/to/pk.pem ec2-user@ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com

ですが、これでは何のサーバに接続しているのかさっぱり分からないのでこのまま運用している人はまずいないでしょう。 (AWS Management Console から毎回コピペでがんばっている人はいそう)

~/.ssh/config

おそらく多くの人は ~/.ssh/config の設定にそれぞれ工夫を凝らしているのかと思われますが、インスタンス数が増えてくると ~/.ssh/config の更新も煩わしくなります。また Auto Scaling 等のダイナミックな運用になるととても追いつきません。

既存サポートツール

ec2ssh

その煩わしさを解消するツールとして ec2ssh という ~/.ssh/config の更新を半自動化してくれるものがあります。 (see. Amazon EC2インスタンスに簡単にSSHできるようになるツールec2sshを公開しました)

ただこれもコマンド一発とはいえ更新作業が必要になり、私にはこれも煩わしく感じました。更新を忘れると期待と異なるサーバにアクセスしてしまう可能性もあります。

ec2-ssh

そこで登場するのが ec2-ssh です。(が、まだ本題ではありません！)

これは Instagram エンジニアが作ったツールで ~/.ssh/config の編集無しにダイナミックに解決するタイプになります。 (see. Simplifying EC2 SSH Connections)

私の趣味的にはこちらの方がマッチしていたので2,3日使ってみたのですが、以下の点で不満がありました。

不満点

ssh のオプションと互換性がない
ユーザ名を省略した時に ~/.ssh/config の User 設定が有効にならない
Python が必要

別に Python が嫌なわけではなくてシェルスクリプトで十分に書けるものなのにわざわざ依存関係を増やしたくないというだけです。

(やっと本題) 作ってみた

というわけで、仕様・実装ともにもっとシンプルにした yet another ec2-ssh を作ってみました。

特徴

~/.ssh/config の更新不要
ssh の単なるラッパーなので ssh と全く同じように利用可能
- ホスト名の部分を解決して置換しているだけ
Pure シェルスクリプト No Requirements
- ただしWindowsは考慮してません。Cygwin とかなら多分動く。
同じ名前が付いたインスタンスへの接続にも対応

インストール

ec2-api-tools

まず前提として ec2-api-tools が動く環境になっていることが求められますが AWS 使っている人であれば設定済みでしょう。

利用するコマンドは ec2-describe-instances のみです。

Mac なら、

brew install ec2-api-tools

で OK。

環境変数で以下を適切に設定すれば動くはずです。

AWS_ACCESS_KEY
AWS_SECRET_KEY
EC2_HOME
EC2_URL
EC2_REGION

ec2-ssh

gist に置きました。ec2-ssh

まだパッケージングしてないけどシェルスクリプト1つなので以下のような手順で。

wget https://gist.github.com/migrs/5157665/raw/736e5940279ba92040400d21071b0cf6a392ce5d/ec2-ssh -P /path/to/bin/
chmod +x /path/to/bin/ec2-ssh

利用方法

web1 という名前がついたサーバにSSH接続

ec2-ssh web1

ユーザ名を指定

ec2-ssh jonny@web1

同名インスタンスへの接続。上から3番目(作成順)。

ec2-ssh web#3

ポートフォワーディング

ec2-ssh -L 8080:127.0.0.1:80 web1

コマンド直接実行

ec2-ssh web1 ls -la
ec2-ssh web1 tail -f /var/log/nginx/access.log
ec2-ssh web1 vmstat 1
ec2-ssh web1 -t top
ec2-ssh web1 -t sudo service nginx restart

いい感じですね。

続き

新参なので知らないだけなのかもしれません。もっと良い何かがあったら是非教えてください。

この記事には続きがあります。もっと便利な何かを紹介します。

LL Decade 参加者向け - 銀座ブロッサム周辺ランチ情報

Tue, 24 Jul 2012 08:00:00 +0900

来たる8月4日に LL Decade が銀座ブロッサムにて開催されます。

ただ場所的に少し問題がありまして近隣で住んだり働いたりしたことがある人なら分かると思いますがもともと飲食店が少ないエリアな上に土日営業してない店が多いのです。少し歩いて飲食店を探しに行くことになるはずですが、行く方向間違えれば確実にランチ難民になるでしょう。

ということで銀座ブロッサム周辺で土曜日にランチ営業している飲食店マップを作ってみました。

中華・韓国定食・和食・寿司洋食ラーメンカレーカフェファストフード

こうやって見ると多く感じますが、銀座ブロッサム中心半径約150mは空洞化してるのが分かると思います。しかも近めはお高めの店が多いので注意が必要です。

おすすめエリアは歌舞伎座周辺とウィンズ銀座周辺です。ちょっと余裕があれば築地場外市場(徒歩約10分)まで足を伸ばしても良いでしょう。土曜の場外は活気があって面白いと思います(その分混雑しているので注意)。もちろん中央通り付近まで行けば迷う程お店あります。

場所柄高めなレストランも多いのですが一応そこまで高くない店をピックアップしているつもり。とある土曜日のお昼時に撮影した外観写真と食べログへのリンクを貼っているので参考まで。黒いドットが付いてる店は個人的にお勧めな店に付けようと思ったのですが適当なのであまり気にしないでください。

腹が減っては何とやら、無事美味しいランチに辿りつけることを心よりお祈りしております。

フジロックより安い！Jisan Valley Rock Festival に行こう 2012

Sat, 07 Jul 2012 05:45:00 +0900

更新情報

7/20 更新

前回情報いただいた現地在住のゆるゆるはんぐくさんのページにてさらに詳しい情報が紹介されていますので掲載させていただきます。

7/10 更新

専用シャトルバスがあるようなのでアクセス方法について更新しました。キャンプ道具も一式レンタルできるそうです。 (韓国にお住まいの方から情報いただきました。ありがとうございます！)

FUJI ROCK FESTIVAL 2012

今年は異例の開催発表で話題になった FUJI ROCK ですがいよいよ今月末まで迫ってきました。

なんと言っても今年の目玉は奇跡の再結成を果したTHE STONE ROSESと実はFUJI ROCK 初出演となるRADIOHEADでしょう。他にもたくさん魅力的なアーティストが目白押しなので非常に楽しみなのですが、毎度ながらかなりお高いですよね。。

FUJI ROCK チケット情報
- 1日券: 17,800円 (先行販売 16,800円)
- 3日券: 42,800円 (先行販売 39,800円)

毎年では無いものの結構参戦しているのですがここ最近は一日に焦点絞っての参加になることが多いです。(お値段以上の価値があるイベントだとは思いますが)

JISAN VALLEY ROCK FESTIVAL 2012

ここで本題。海を渡ったお隣韓国でも FUJI ROCK とまったく同じ日程(7/27-29)でフェスが開催されます。

Jisan Valley Rock Festival 2012

このフェスは FUJI ROCK 主催のスマッシュと連携しており、FUJI ROCK に出演するアーティストの多くがこちらにも出演するのです。画像にもデカデカと書いてますが上記2大アーディストも出演が決まっており、RADIOHEAD に関しては韓国初上陸とのこと。

そしてそのチケット代が円高も相まって非常にお値打ち価格なのです。

JVRF チケット情報 (100ウォン = 7円換算)
- 1日券: 140,000ウォン (約 9,800円)
- 3日券: 225,000ウォン (約 15,750円)

3日券に関しては半額以下で6割以上も安いことになります。

その差額があれば格安航空券等を利用することで交通費も賄えます。
韓国(ソウル)の格安航空券/旅行相場

苗場に向うにしてもそれなりの交通費(上越新幹線自由席東京-越後湯沢往復 11,960円)がかかるので、これは検討してみる価値がありそうです。

フェスのついでに韓国旅行も楽しんじゃおう！というノリならさらにお得に思えてくるわけで、もちろん規模も出演アーティストも FUJI ROCK の方が圧倒的に上なのですが、最低限この2バンドが拝めれば良いと思っている私のような人にとっては非常に魅力的です。

というわけで、本格的に行ってみようと先月末くらい思い立ちいろいろ調べて始めてみました。(遅いって・・・)

現地情報

開催場所

京畿道(キョンギド)利川市(イチョンシ)にあるスキー場 Jisan Forest Resort で開催されます。 FUJI ROCK が苗場スキー場で開催されるのと同じ感覚ですが、都心(ソウル市内)からの距離で比べるとより近いようです。 (会場へのアクセス情報)

アクセス方法

~~以前までは専用シャトルバスがあったようなのですが今年は無くなってしまったようです。~~ ~~交通手段としては、公共交通機関(バス)か車(レンタカー)のどちらかになります。~~ ~~(※現状どちらにするかは決めかねてます)~~

専用シャトルバスについて韓国語の公式サイトの方に告知されていました。(英語・日本語のサイトは更新されてません。)
なので現地に向かうにはシャトルバスが一番良いでしょう。

専用シャトルバス

7/5 [お知らせ]シャトルのご案内と予約申込([Google 翻訳](http://translate.google.com/translate?u=http%3A%2F%2Fvalleyrockfestival.mnet.com%2F2012%2Fnews.asp%3Fseq%3D79520&hl=ja&langpair=auto

ja&tbb=1&ie=UTF-8))

予約フォームをダウンロードし入力したものをメールで添付して送ることで予約申込となるようです。メール予約から3日以内に指定口座に料金を振り込む必要があります。料金は往復 22,000ウォン(約1,540円)です。 (振込方法については、あとで書く)

公共交通機関(バス)

東ソウルターミナルから利川(이천 イチョン)行きバスに乗って利川市外バスターミナルに向います。
- 頻繁(約15分毎?)に運行されている(未確認情報)
- 所要時間は約1時間
- 運賃は 3,800ウォン(約266円) くらい？(未確認情報)
利川市外バスターミナルから 12蕃バスに乗ってジサンマートで下車
- 比較的頻繁(約30分毎?)に運行されている(未確認情報)
- 所要時間は約40分
- 運賃は 1,200ウォン(約84円) くらい？(未確認情報)

運賃に関しては非常に安いので気にする必要はなさそうです。ただし利川市まで入ってしまうと日本語はもちろん英語の案内も無く現地の方もほぼ話せないと思った方が良いらしい。目的地をハングルでメモっておいた方が良いでしょう。

また、韓国はタクシー料金が安く、利川市外バスターミナルから会場まではタクシーで向うのが良いかもしれないとのアドバイスも貰いました。(約3,000-5,000ウォン約200-300円)

ただ行きは良いのですが帰りが問題です。終バスの時刻は21時台のようなので、その頃は一番の目的のアーティストが絶賛演奏中である可能性が高く帰れそうにありません。 (タイムテーブルまだでてない。でるのか？)

そうなると現地で夜を明かすことになるのですが現地宿泊情報は後述します。

車(レンタカー)

国際運転免許証取得して現地で Hertz あたりで借りてあとは iPhone の力でなんとか会場まで辿り着けるでしょう。(ちゃんと調べてないので適当)
車なら帰りも心配ありません。
ただ韓国の運転マナーは非常に悪いらしくどのガイドブックでもお勧めしてないそうです。

必要な手配

JVRF 2012 チケット購入
航空券の手配
宿の確保

JVRF 2012 チケット購入

公式のチケット案内から予約販売先へのリンクがあるので、好きなところから予約するのが良いですが、英語なのは以下の二つだけのようです。

注意点として YES24.COM は Windows でないと決済できない仕組みを使ってます。INTERPARK の方はまだ試してません。

チケットは会場にてIDと引き換えに渡されるようです。

航空券の手配

適当に手配しましょう。羽田発で便確定の一番安いチケットだと一人往復28,000円(燃油サーチャージ・空港使用料等込み)くらいです。

宿の確保

こちらも適当に。半分観光目的なので~~便利な明洞周辺~~(明洞周辺はちょっとお高めだったので麻浦エリアにしました)に宿泊予定です。
パックツアーを利用し航空券と合わせて手配するのも良いでしょう。

会場周辺宿泊情報

もし会場から帰れなくなったらですが、会場周辺で何とかしなければいけません。

おそらく朝までやってるので、徹夜でフェスに参加する
キャンプする
- キャンピングチケット付を購入することでキャンプができます
- ~~ただキャンプ設備を持って行けないので非現実的かと(韓国の知り合いと一緒にならアリ)~~
- キャンプ道具一式のレンタルとオプションでテントの設営までできるそうです
JISAN FOREST RESORT で宿泊
- 問合せたがキャンセル待ちとのこと
YANGJI PINE RESORT で宿泊
- 公式に宿泊案内あり
- 送迎バス付
- 予約状況は未確認
サウナ(ジンジルバン)に宿泊 (Anseong Natural Resort)
- 公式に宿泊案内あり
- 送迎バス付で一泊 20,000ウォン(約1,400円)
- 最終日は 15,000ウォン(約1,050円)(Sauna -> Fes Site の移動が無いので安い)
- 深夜 1:00 に会場まで迎えにきてくれる。(朝は 9:00 出発)
- まだ予約可能だが、この予約が大変(後述)。

サウナ(ジンジルバン)の予約

Anseong Natural Resort のサイトを見てもらえれば分かると思いますが、日本語はもちろん英語による案内もなく途方に暮れてしまいます。

そこで、京畿道のコールセンターが日本語での対応可能らしいので JVRF の宿泊情報についてダメモトで問合せてみました。すると非常に親切に対応してくれて、その担当者を経由して三者通話的に会話することでサウナの予約をすることができました。

あとは銀行の振込を持って予約完了というところまで来たけど、今まで韓国の銀行口座に振り込んだことなど無い。。幸い振込先のハナ銀行の支店が丸の内にあったので問合せることができました。振込方法については次で。

韓国への送金方法

専用シャトルバスやジンジルバンの予約申し込みに必要な銀行口座への振込ですが、どちらも同じ口座情報でした。

韓国への送金方法は以下のサイトが参考になります。
日本から韓国への送金

いくつか方法がありますが、私は丸の内にあるハナ銀行東京支店で手続きをしました。

9時-15時で営業しているのですが、ウォン建ての振り込みはレートが確定する11時以降になります。私は11時まで待てなかったので円建てで送金しました。レートが分からないので念の為少し多めに。

必要なものは、

身分証明証
印鑑
振込手数料 1,500円 + 10,000ウォン

です。

振込先(Accounting holder) がハングルでかかれてますが、アルファベットで書く必要があります。アルファベット表記は “SUNGJIN CNT” になります。

日本のアーティスト情報

日本のアーティストも多数参加されます。同じ日本人として応援しましょう。

(詳細はあとで書く)

その他の手配

モバイル環境

インターネット環境

iPhone がなれば海外旅行できないくらい非常に便利で依存してしまっているわけですが、ネットに繋がってなければほとんど意味がありません。海外パケットし放題のお陰で一日2,980円さえ払えばそれ以上料金気にすることなく利用できるようにはなったのですが、数日となるとかなり高くついてしまいます。

そこでオススメなのが、海外用モバイルデータ通信です。

いろいろ業者はあるようですが、私はグローバルデータを良く使ってます。

韓国なら一日680円で海外パケットし放題と比べてもとってもお得です。複数名で共有するならなおさらで、さらにPC等でも利用できるので海外旅行ではマストなアイテムです。

Skype Out の活用

国際電話も非常にお高いイメージですが Skype を活用することでグッと節約(1分約3円)できます。

モバイルバッテリー

iPhone を8回も充電できるらしいルックイーストの大容量モバイルバッテリーPOWER-POND を購入しました。買ったばかりなので、実力の程は不明。実力が本当ならサバイバル環境でも安心ですね！

情報交換しましょう！

私もこれから諸々の手配を始めるところなので、まだまだ間に合うはずです。

ただ未確認情報も多いので書いてること鵜呑みにせず御自身の責任で行動してください。

まだまだ不明な点もたくさんありますが、情報お持ちの方や私も行ってみたいという方はお気軽にご連絡ください！

と長々書きましたが本当に行けるのかしら・・・

※このページは開催までの間、次第随時更新予定です。

Rubyist が今すぐ Elixir を使ってみるべき理由

Mon, 12 Mar 2012 00:33:00 +0900

Elixir の読み方は多分「エリクサー」。RPGゲームのアイテムにありそうな名前だ。個人的には「エリクシール」と読みたいところだが多分「エリクサー」で良いだろう。 Elixir は最近になって開発が活発化しており、公式サイトも最近立ち上げられたようだ。

http://elixir-lang.org/

つい先週のことだが Github でも公式にサポートされている。

Elixir is officially supported on Github! Including file identification and syntax highlight: github.com/languages/Elix…
— Elixir Lang (@elixirlang) March 5, 2012

ここにきて盛り上がってきた感があるので、作者である José Valim が約1年前に書いた Why Rubyists should try Elixir という記事を訳してみた。

英語・日本語問わず語学苦手なので読み難い代物になってしまっているが間違いがあったら指摘して欲しい。

追記(2012-03-13)：

昨日 Elixir 勉強会(Shinjuku.ex #1)で初めて Getting Started Guide を読んだのだが、今の Elixir は訳した記事が書かれた当時とはかなりシンタックスが変更されているようだ。なので記事中のコードを最新(0.4.0.dev)に合わせて書き直した。

変更されていた点を列挙すると、

コメントアウトは % でなく #
アトムは ` (シングルクォート)ではなく : (セミコロン)
module -> defmodule
if や defmodule には do が必要
else -> else:

Diff はこちら

少し突っ込んでみて分かったこととして Erlang と Ruby だけではなく Clojure っぽさを強く感じる言語であるということ。

勉強会については @mizchi 氏のレポートがあるよ

Elixir勉強会いってきました ~~ ErlangとRubyの中間、Elixir

Rubyist が今すぐ Elixir を使ってみるべき理由 (Why Rubyists should try Elixir)

今月(※2011年3月25日現在)の初めに、私は Elixir についてのスクリーンキャストを公開している。それを見てない人向けに説明すると、Elixir は Erlangの上にシンプルなオブジェクト指向と魅力的な構文を提供することを目指している。

私の強いRuby背景に基づいて、私は何度か質問された結果、なぜ Rubyists は Elixir を使ってみるべきかについてのブログ記事を書くことにした。

Elixir が持つ Ruby から来た method missing や module eval のような多くの構文やいくつかの機能によって同じようにメタプログラミングをすることができる。

しかしながら Elixir は他の何よりも Erlang に間違いなく近い。単一代入変数、不変性、簡単なプロセス間通信、リスト、タプル、バイナリ、そしてOTPの振舞は、すべて Elixir で利用できる。したがって Elixir を使うことを通じて多くを学ぶことができるだろう。

多くを学ぶ中で私が楽しく感じたのは次のとおりだ：

パターンマッチング (Pattern matching)

私にとってパターンマッチングは関数型プログラミングの中で最も楽しい機能の一つだ。これらによって簡単にデータ構造から情報を抽出することができるようになる。

例えば、Elixir では次のように記述する：

[first, second] = [1,2]
first # => 1
second # => 2

Ruby の代入演算子を使用して全く同じように書くことができるが、パターンマッチングの利点はメソッドのシグネチャの中で利用できることで、もしメソッドのシグネチャがある特定のパターンに一致しない場合は次のメソッドが試される。

例えば、文字列のリストを反復処理しそれらを出力する方法は次のとおりだ：

defmodule Printer do
  # これは少なくとも一つの要素が存在するリストにマッチするパターンだ
  # 最初の要素が head に割り当てられ、残りは tail に割り当てられる
  def print([head|tail]) do
    IO.puts head
    print(tail) # 再帰的に tail と引数として print が呼び出される
  end

  # リストが空になったとき上のメソッドではマッチぜず、かわりにこれがマッチする
  def print([]) do
    # 何もしない。すべての出力は完了している。
  end
end

Printer.print ["foo", "bar", "baz"]

また別のクールな例はリストが別のリストの接頭辞であるかどうかを確認する再帰的なメソッドだ：

defmodule Prefix do
  # 両方のリストを反復する。もし最初の要素が等しかったら自分自身を再び呼び出す。
  # もし最初の要素(i)が等しくなかったら、このメソッドにはマッチしない。
  def is?([i|prefix], [i|list]) do is?(prefix, list) end

  # もし接頭辞が空だったらこのメソッドにマッチし true を返す。
  def is?([], _list) do true end

  # それ意外なら、false を返す。
  def is?(_prefix, _list) do false end
end

Prefix.is?([1,2,3], [1,2,3,4,5]) # => true
Prefix.is?([0,1,2], [1,2,3,4,5]) # => false

最後に、パターンマッチングは Ruby 2.0 で計画されている機能の一つであるキーワード引数を可能にする。この例は Elixir のコードそのものだ~~（Elixir のシンボルはコロンではなくシングルクォートでることに注意）~~：

defmodule Record do
  def retrieve(name, from: file) do
    # ここに実装を書く ...
  end
end

Elixir と Erlang のどちらも while のような条件ループを提供しないという事実は、あなたに異なる考え方やパターンマッチングの利用を強いることになる。

まずは Ruby で解決して、次に全く別の解決策を考え出すというように、問題について別視点で考えるということは一般的に非常に洞察的で楽しい過程だ。

また、注意として Elixir と Erlang の両方において末尾再帰最適化するので、もし Ruby で似たようなメソッドを実装するなら、巨大なスタックトレースを取得することができる場合のみ上手く動作する。

単一代入変数と不変性 (Single assignment variables and immutability)

上記例において Erlang の変数は単一代入であることをまだ見せてなかった。これにより次のエラーが発生する：

[first, second] = [1,2]
first = 10

これは bad match error を投げる。なぜなら既に first に値が割り当てられており、2行目の first = 10 は 1 と 10 を比較しているので当然ここで失敗するのだ。

変数は一度だけ割り当てられるということは、前述の prefix method のような実装が可能となり、両方のリストでマッチして i に値が割り当てられる。

また、Elixir と Erlang の両方において、オブジェクト/データ構造はその場で変更することはできない。こらは不変だ。すべての変更は新しいオブジェクト/データ構造体を生成する。

不変性は言語内部の共有状態を排除し（外部操作を実行する必要がある場合あなたはまだ状態を共有している）、Erlang と Elixir の並行性に重要な役割を果たしている。

個人的に、不変性は同時に幸福と不幸もたらすことが分かった。 Railsアプリケーションで作業するとき可変性は一般的に問題ではないが、Rails 自体や gem 等の実装においては頻繁に可変性について考える必要がある。変更するメソッドにオブジェクト（ハッシュや配列のような）を渡したときに、そのオブジェクトの中の新しい要素が結局どうなったのかを追跡するために時間を費やさなければならない。

Elixir で作業する際にすべてが不変であるので、このような場合を心配する必要はない、そう、それが気持ちいいのだ！これは C から Java に行くような感覚で、私は突然メモリ管理を心配する必要もない。

しかし、このような利点はいくつかのコードをより冗長にさせるという明らかな欠点をもたらす。

この欠点を示すために、Rails ライクな PostsController の create アクションを、不変性と単一代入変数の両方を考慮して書き直してみる：

def create
  post0 = Post.new(params[:post])
  post1 = post0.set(:published, false)
  post2 = post1.save

  if post2.persisted? do
    redirect_to post2
  else:
    render :new
  end
end

この場合 ORM はよりよい API を提供することができそうだが、これは何度も繰り返されるパターンだ。たとえば、クッキーを変更するとレスポンスオブジェクトに明示的な変更が必要になる。

response1 = response.cookies.set "tracker_code", "123456"

いずれにせよ、不変性と単一代入変数を提供する言語での作業は経験する価値がある。私が今までのブログ記事で言及したことを試してみることによって多くを学ぶことができるだろう。

追記：いくつかのコメントで指摘したように、Elixir は単一代入を削除することができて、その上で Erlang の基盤と正常にやりとりすることができる。このような理由から、Elixir は今では複数回同じ変数に割り当てることができるし、Erlang と比較すると変数のスコープ（Ruby に似ている）に関連したより柔軟なルールがある。

プロセス間通信 (Communication between processes)

パターンマッチング、単一代入変数と不変性は、プロセス間の通信のための良い基盤を提供する。もしこれらの動作に興味があるならこのスクリーンキャストを見ると良い。

異なるオブジェクトモデル (A different Object Model)

Elixir は Ruby とは異なるオブジェクトモデルを持っている。オブジェクトモデルはクラスが無いという意味では JavaScript のようなプロトタイプベースだが、JavaScript や Self のそれとは違いオブジェクトはその子供達がどのようになるかを指示することができ、必ずしも親から正確にコピーされない。

これについてのより多くの情報は Elixir の README にある。そこには、本当の private メソッド（多分それは Ruby 2.0 に含まれるかも？）やローカルメソッド呼び出しのようないくつかの他のクールな機能の情報も含まれる。

常に他のオブジェクトモデルを使用することによって多くを学ぶことができ、このチップは Elixir だけに制限されるものではない。あなたがもし JavaScript のオブジェクトモデルまたは他のプロトタイプベースの言語に精通していないのであれば、今それを学ぶことを勧める。

学ぶ (Just learn)

スクリーンキャストやREADMEで述べたように、標準ライブラリとテストの両方が Elixir 自体で書かれているので Elixir に貢献するのはとても簡単だ。さて、Elixir で Ruby のセットのような何かを実装しなければならないことを想像してみよう。

Ruby のセットについてさらに深く学ぶだけでなく、使用するための最良の構造はどうあるべきか、どのアルゴリズムがセットを更新するのに適しているか、それらのオブジェクトにアクセスするための優れた API はどうあるべきか、について学ぶ必要がある。

また、パッケージングシステム、ドキュメントパーサーやテスト·ライブラリのようにどの言語でも必要な基本的なツールだけど現在 Elixir で欠如しているこれらはあなたが実装する1つかもしれない！

結論 (Wrapping up)

私はあなたが Elixir を試してみること期待するし確信している。この言語に関してもっと知りたければ README をチェックして欲しい。

最後に、クレイジーなことをするために別のインスピレーションが必要なのであれば Forking Ruby talk by Dave Thomas を勧める。

彼が言ったように、私たちは Ruby を愛し、そこからいますぐ離れるようなことは無いが、それを分岐したり新しい物事をしようとすることは言語とそのエコシステムを改善するための素晴らしい方法であり、Elixir がそのことについてさらに考える手助けになることを期待している。

Pow をもっと便利に使うためのツール比較 - Powder / Powify Comparison

Mon, 16 Jan 2012 09:30:00 +0900

Mac and Ruby なウェブ開発者必携、37signals 謹製の非常に便利な Pow ですがみなさん活用してますか？

私はいわゆるプログラマーと呼ばれる人だけではなく、ウェブデザイナーな人たちにこそ活用して欲しいプロダクトだと思っているのですがそのことについては置いておいて（また別途）ここでは周辺ツールについて。

Pow 自体非常にシンプルでサードパーティツールの類はほとんど必要ないのですが、さらに便利に扱うためのツールがマニュアルでいくつか紹介されています。

ここにある二つのプロダクト (Powder/Powify) が非常にクリソツ（死語）で何が違うのか一目では分からなかったので（自分の為にも）表にして比較してみた。

結論から言うと両者ほとんど同じ。Powify の方が若干高機能かな〜ってくらい。

Powder / Powify Comparison

Powder	Powify
Server Commands
Install pow server ( `curl get.pow.cx \| sh` )
`powder install`	`powify server install`
Reinstall pow server
`-`	`powify server reinstall`
Update pow server
`-`	`powify server update`
Uninstall pow server ( `curl get.pow.cx/uninstall.sh \| sh` )
`powder uninstall`	`powify server uninstall`
List all pow apps ( `ls -l ~/.pow/` )
`powder list`	`powify server list`
Start the pow server ( `launchctl load ~/Library/LaunchAgents/cx.pow.powd.plist` )
`powder up`	`powify server start`
Stop the pow server ( `launchctl unload ~/Library/LaunchAgents/cx.pow.powd.plist` )
`powder down`	`powify server stop`
Restart the pow server
-	`powify server restart`
Updates hosts file to map pow domains to 127.0.0.1
`powder host`	`powify server host`
Removes pow domains from hostfile
`powder unhost`	`powify server unhost`
Shows current pow status
`powder status`	`powify server status`
Shows current pow configuration
`powder config`	`powify server config`
Tails the Pow log ( `tail -f ~/Library/Logs/Pow/access.log` )
`-`	`powify server logs`
App Commands
Create a pow app from the current directory ( ln -s `pwd` ~/.pow/[NAME] )
`powder link [NAME]`	`powify create [NAME]`
Destroy the pow app served from the current directory ( `rm ~/.pow/[name]`)
`powder unlink [NAME]`	`powify destroy [NAME]`
Clean up invalid symbolic link
`powder cleanup`	`-`
Restart pow app ( `touch tmp/restart.txt`)
`powder restart`	`powify restart [NAME]`
Always restart pow app ( `touch tmp/always_restart.txt`)
`powder always_restart`	`powify always_restart [NAME]`
Reset restart settings ( `rm tmp/always_restart.txt`)
`powder no_restarts`	`powify always_restart_off [NAME]`
Rename the pow app to [NAME]
`-`	`powify rename [NAME]`
Run the this pow app in a different environment
`-`	`powify env [ENV]`
Open a pow in the browser
`powder open`	`powify browse [NAME]`
Tail the application logs ( `tail -f ~/Library/Logs/Pow/apps/[NAME].log` )
`powder log`	`powify logs [NAME]`
Set this app as default (http://localhost/)
`powder default`	`-`
Remove current default app
`powder un_default`	`-`

Non-Japanese な人向けに gist も用意した。

Conclusion

Powify には専用の管理アプリ(powify.dev)も用意されており、以下のコマンドで設置可能。 (今のところPow情報表示するだけのシンプルなもの)

powify utils install
powify utils reinstall
powify utils uninstall

敢えて言うなら、シンプルな Powder・高機能な Powify といった感じか？
今のところ善し悪し微妙なので好き好きで！

References

Rackアプリ開発するならPowはもう常識だよね～