Web制作の現場で「黒い画面」を使うことは、近年ではごく当たり前な事になってしまいました。 フロントエンドエンジニアの方はもちろん、マークアップエンジニアの方ならば抵抗は無いでしょう。 しかし、デザイナーさんには未だに「黒い画面」は苦手意識がある方も少なくないのではないでしょうか。 その苦手意識を払拭する為に、少しばかり「黒い画面」への理解を深めてみましょう。

1. デザイナーが触れる「黒い画面」
2. 「黒い画面」ことターミナルとは
3. 「黒い画面」の基本
4. 「黒い画面」の怖い話
5. Windows環境での「黒い画面」

デザイナーが触れる「黒い画面」

そもそもデザイナーが「黒い画面」に触れる事は数年前まではあまり考えられていませんでした。 黒い画面上の作業はあくまでもバックエンドエンジニアやプログラマーの領域であって、デザイナーが触れるのはPhotoshopやIllustratorといったグラフィカルなアプリケーションまでに留まっていたと思います。

ところがWebの技術が度重なる変化・進化を遂げ、JavaScriptやCSSをビルドするようになったり、Node.jsが台頭してきたりで、プロジェクトの「黒い画面」への依存度が一気に上がってきました。 マークアップエンジニアは勿論のこと、肩書がデザイナーの人間も「黒い画面」を触れるようになる必要が出てきたのです。

例えば、こんなケースであったり

人手不足でデザインに加えてマークアップもやる事になった。 CSSをビルドする為に「黒い画面」が必要だ。

また例えば、こんなケースもあるでしょう。

プロジェクトにデザイナーとしてジョインしたが、 マークアップエンジニアが作った画面をレビューする為に「黒い画面」でコマンドを叩かなければならない。

「黒い画面」ことターミナルとは

まず「黒い画面」とは何なのか。その正体について軽く触れてみます。

Macにおける黒い画面である「ターミナル」は、GUI（グラフィカルインターフェース）によらず、 CUI（キャラクタユーザーインターフェース）、つまり文字列のコマンドでコンピュータを直接操作する為の物であると理解しておけば良いでしょう。

例えばMacでファイルを探し出すのにFinderを使用しますが、これはGUIによる機能ですね。 ターミナルでは、CUIで謎の呪文こと、コマンドを打ち込む事でそれとほぼおなじ事をすることが出来ます。 （勿論CUIなので見た目はただの文字列です） Finderをはじめとした、私達が普段パソコン上で使っているGUIアプリケーションは、ターミナルで行える処理を視覚的に見やすい形、そして操作しやすい形でラッピングされているのです。

ちなみに、MacOSXは元々Unix系のFreeBSD由来のOSで、 Unix系のコマンドの多くがそのまま使用できるのはその為です。 （Windowsについては後述しましょう）

「黒い画面」の基本

まずは黒い画面を立ち上げて触ってみましょう。 Mac環境ならば「アプリケーション」 > 「ユーティリティ」 > 「ターミナル」と辿っていけば立ち上がります。 あるいは Spotlight 検索で “term” あたりまで入力すれば出てくると思います。

ここまで「黒さ」を連呼していますが、Macでのデフォルトは白ベース黒文字の「白い画面」になっています。なんとなく、怖さが少し和らぎますね。

コマンドを入力してみる

黒い画面への入力については、キーボードで文字を入力するだけなので難しいことはないでしょう。 試しに一つコマンドを打ってみましょう。

$ whoami

[your user name]

whoami コマンドは、現在ログインしているユーザーの名前を出力します。 貴方のユーザー名が表示されましたか？

「何処」で「何」を対象に「何」するか

コマンドを覚えていく前に、次の3つの事を意識するようにしてみましょう。

1. 現在どこのディレクトリにいるか
2. そこで何をするか
3. 何を対象に行うか

例えばこんなコマンドを打ったとします。

$ mkdir myfolder

上の例では、現在いるディレクトリの中に myfolder という新しいディレクトリ（フォルダ）を作成しています。

もう少し詳しく見てみましょう。 コマンドはコンピューターへの命令であり、文法で言うところの述語です。 基本的に、コマンドは英語の文法に則っていて、述語であるコマンドの後には目的語を指定します。

この目的語は「引数（ひきすう）」と呼ばれ、上の例では myfolder が引数に値します。 つまり、 myfolder という名前で、ディレクトリを作る命令（ mkdir ）を行ったわけです。

また、命令によっては目的語を持たない（あるいは省略できる）場合もあります。

$ # ユーザー名を出力するだけなので引数が必要ありません
$ whoami
$ # 引数を省略すると、ユーザーのホームディレクトリに移動します
$ cd

さらにまた、目的語を二つとる命令もあります。

$ # 目的語1（foo.txt）を、目的語2（bar.txt）として複製する
$ cp foo.txt bar.txt

ファイルやディレクトリを引数にする

先程言ったように、コマンドには目的語である引数を渡す事が多いのですが、 その引数となるのはファイル名やディレクトリ名がほとんどです。

$ rm ./needless.txt

上の例では、今いるディレクトリにある “needless.txt” という名前のファイルを削除しています。 ファイル名の前についている “./” は一体なんでしょうか？ これは「今いるディレクトリにあるファイル」という事を明示的に指定しています。

Unixのファイルシステムでは、ファイルの場所（パス）について次のような表現を用います。

• “.” … 現在のディレクトリ
• “..” … 一つ上のディレクトリ
• “/” … ディレクトリの境目
• 一番頭が “/” … ルートディレクトリからの絶対パス

つまり上の例では、「現在いるディレクトリ下にあるneedless.txt」を指定しているわけです。

ここで「”./”は要らないのではないか」という疑問が浮かんだのではないでしょうか。 その通り、”./” は省略でき、次のように表現しても同じ処理を行います。

$ rm needless.txt

省略できるのならば、なぜ例示でわざわざ “./” を付けたのかというと、その方が安心出来るからです。 ファイルを指定する時は、”./” や “../” からはじまる相対パスで表現する事をお勧めしたいです。

特に、上で例に挙げている rm コマンドはファイルやディレクトリを削除してしまう破壊的なコマンドです。 必ず “./” ではじめる事を意識すれば、現在いるディレクトリを誤ったり、朦朧としながら作業をしていて操作ミスをしたりして、処理してはいけないファイルを処理してしまう危険性をわずかばかりではありますが、和らげる事ができます。

$ rm /the/path/to/target # NG
$ rm target # NG
$ rm ./target # Good

「どのように」行うか（オプション）

多くのコマンドは、「オプション」を渡すことで挙動をコントロールする事ができます。 ここでは ls コマンドを例に上げてみます。このコマンドは、ディレクトリ内にあるファイルをリスト表示してくれます。

$ ls
bar.txt         directory       foo.html

何もオプションを渡さない場合、ただファイルの名前のみが羅列されます。 ファイル名だけだと情報が足りないので、l オプションを追加してみましょう。

$ ls -l
total 16
-rw-r--r--@ 1 mach3  staff  212 12 12 16:03 bar.txt
drwxr-xr-x@ 2 mach3  staff   68 12 12 16:02 directory
-rw-r--r--@ 1 mach3  staff  248 12 12 16:03 foo.html

色々な情報が詰まったフォーマットで出力されました。 さらにドット（”.”）からはじまる隠しファイルも表示する為に、くわえて a オプションを指定してみます。

$ ls -la
total 16
drwxr-xr-x@ 6 mach3  staff  204 12 12 16:19 .
drwxr-xr-x@ 8 mach3  staff  272 12 12 16:01 ..
-rw-r--r--@ 1 mach3  staff    0 12 12 16:19 .hidden
-rw-r--r--@ 1 mach3  staff  212 12 12 16:03 bar.txt
drwxr-xr-x@ 2 mach3  staff   68 12 12 16:02 directory
-rw-r--r--@ 1 mach3  staff  248 12 12 16:03 foo.html

またさらに、t オプションを追加して更新時間順にソートしてみましょう。 （デフォルトでは名前順です）

$ ls -lat
total 16
drwxr-xr-x@ 6 mach3  staff  204 12 12 16:19 .
-rw-r--r--@ 1 mach3  staff    0 12 12 16:19 .hidden
-rw-r--r--@ 1 mach3  staff  248 12 12 16:03 foo.html
-rw-r--r--@ 1 mach3  staff  212 12 12 16:03 bar.txt
drwxr-xr-x@ 2 mach3  staff   68 12 12 16:02 directory
drwxr-xr-x@ 8 mach3  staff  272 12 12 16:01 ..

オプションを指定するルールがお分かりいただけたでしょうか。 オプションは主に1文字の英数字や短い言葉で指定し、 ダッシュ（”-“）の後ろに続けて打ち込む事で複数のオプションを合わせて利用する事ができます。 （このルールに則らないコマンドも存在するのでご注意ください）

各々のコマンドは、それぞれのオプションを持っています。 とても全てを覚えきれる物ではないので、その説明は次回に持ち越す事にします。

「黒い画面」の怖い話

「黒い画面は怖くない」と言いたいところですが、残念な事に「黒い画面」は怖いのです。

GUIのアプリケーションで警告が発せられるような処理でも、「黒い画面」は警告を発してくれません。 GUIのアプリケーションなら行わないような危険な処理も、「黒い画面」は実行してしまいます。 良く知らないままにコマンドを実行して、環境を壊してしまうなんていう悲劇も往々にしてあり得る事です。

うまく動かないからネットで検索したコマンドコピペして実行したら、パソコンが起動しなくなった

ジョークみたいな話ですが、実際に私の観測圏内で起こった出来事です。

ネットで拾ったコマンドを調べずに実行しては絶対にいけません。 コマンドがどのような処理を行う物なのか、渡している引数は何なのか、どのようなオプションで実行されているか、コピーしたコマンドはつまるところどういう命令なのか、 それらを調べて理解したうえで実行しましょう。 そして、インターネットは怖いところだという事を肝に銘じておきましょう。

Windows環境における「黒い画面」

Windowsにおける「黒い画面」は「コマンドプロンプト」と呼ばれる物ですが、これはおすすめできません。 WindowsはUnix由来でない為、Macで使えるような基本的なコマンドも使用できず、そもそもコマンド自体が非常に少なく、使い勝手がよくないのです。 「他と違う」という事は、つまり問題が起きた時に調べても解決策にたどり着きにくいという事です。

いくつか代替の手段があるので、そちらを使うようにした方が良いでしょう。

1. Git Bash

Windows環境で開発作業を行うのならば Git for windows は恐らくインストールされているはずなので、 これにバンドルされている「Git Bash」を活用します。 インストールされてない場合は、インストールしましょう。Gitはもはや開発環境に無くてはならない存在です。

Git Bash は msys と呼ばれるエミュレータで動いており、いささかLinuxやMacとは使い勝手が違いますが、基本的なコマンドは使用する事ができます。 （msysは、昔なつかしのcygwinからのフォークです）

Git Bashのメリットは、Windowsにおける実行ファイル（.exe）が容易に呼び出せる点です。 ショートカット（.lnk）もちゃんと追随してくれるので、「好きな名前で好きなアプリを立ち上げる」なんていう設定も簡単にできます。（ここでは説明は割愛します）

$ # 現在いるディレクトリでエクスプローラーが立ち上がります
$ explorer .

2. Bash on Windows

Windows10ならば、Windows上でUbuntuが動作します。 Windows Subsystem for Linux（WSL）と呼ばれる仕組みで、まさにLinuxがWindows上で動作していると思って良いでしょう。

中身はUbuntuなので、apt で楽々パッケージを追加インストールできるのが大きな魅力で、 参考になる情報もネットで収集しやすいです。

• Bash on Ubuntu on Windowsをインストールしてみよう！ – Qiita

前編まとめ

• デザイナーも「黒い画面」が必要な時代になった
• 「黒い画面」の基本的な使い方を学ぶ
• 「黒い画面」は怖いので用法を守って正しく使う
• インターネットの情報は鵜呑みにしてはいけない
• Windowsでの「黒い画面」は Git Bash または Bash on Windows を活用しよう

後編では最低限覚えておくと捗るコマンドと使い方を書くかもしれません。

やりたいこと

例えば、

• hoge.js
• fuga.js
• foo.js
• bar.js

という4つのJavaScriptファイルがあるとして、
これらを順に結合して「main.js」として出力し、
さらにそれをYUI Compressorで圧縮して「main.min.js」を出力したい。

Makefileの例

makefileの基本的な書き方は、入門的な記事がいろんな所にあるのでそちらをご参考に。
上記の処理をする為のmakefileはこんな感じになります。
「Makefile」という名前でJavaScriptファイルと同じディレクトリに保存しておきましょう。

※前記事のyuicコマンドを設定してある前提です

SRC = hoge.js fuga.js foo.js bar.js
COMBINE = main.js
COMPRESS = main.min.js

all : $(COMPRESS)

$(COMBINE) : $(SRC)
    cat $^ > $@

$(COMPRESS) : $(COMBINE)
    yuic <pre wp-pre-tag-0=""></pre>amp;lt; > $@

.PHONY: clean
clean :
    rm -f $(COMBINE) $(COMPRESS)

Line 1-3

結合したいファイル群と、出力用のファイル名をマクロにつっこんでおきます

Line 7-8

catコマンドで結合したいファイル群の中身をまるっと$(COMBINE)の中につっこみます
$^ は依存ファイル全てを展開、$@はターゲットファイルを指します

Line 10-11

yuicコマンド（前記事参照）でYUI Compressorを通して圧縮した結果を$(COMPRESS)の中に突っ込みます

Line 13-15

“make clean” で出力したファイルを削除する為の記述です
$(COMBINE) と $(COMPRESS) で展開される、「main.js」と「main.min.js」を削除します

で、どうするの

make / make all

makeの使い方ですが、ターミナルでMakefileのあるディレクトリに移動し、
makeコマンドを実行するだけです。
あとはmakeの中の人が、main.jsとmain.min.jsを自動的に生成してくれます。

make

make clean

生成したファイルを消して初期化したい場合は次のようにタイプします。

make clean

注意事項

環境に注意

MacやLinuxならば、ターミナルでそのまま実行すればコンパイルしてくれますが、
Windowsではmakeはそのままでは使えず、Cygwin等に頼る必要があります。ご注意を。

結合するスクリプトに注意

単体で読み込まなければ正常に動作しないライブラリ等も存在します。
なので、結合前は動いたのにコンパイルしたら動かなくなった！なんていう事態も起こったり。
闇雲に全て結合・コンパイルしてしまうのは避けたほうが良いかも。

nave.shの導入

isaacs/nave – GitHub

私はノートのUbuntuで導入してみましたよ。
nave.shはGitに乗っかっているのでcloneしてくれば良いです。
導入先は、俺々ルールに則った~/opt/に。

cd ~/opt/ git clone http://github.com/isaacs/nave.git

とりあえず最新版のnode.jsを入れてみる

cd ~/opt/nave/ ./nave.sh install latest

基本的にnave.shに引数を渡して実行するだけです。
上のコマンド例は、最新版（latest）をインストール（install）してるわけですね。
極めてシンプル。使い方に迷ったら、黙って「./nave.sh help」。

つまづくかもしれないポイント

まず、nave.shの動作自体にcurlが必要らしいので、
入ってないのなら導入しておきましょう。

sudo apt-get install curl

他には、g++やopensslなどが要求されますので、こちらもインストール。

sudo apt-get install g++ sudo apt-get install libssl-dev

他にも不足している物があったら、エラーをみて都度導入してあげましょう。

全ての環境が完了するとインストールが始まります。
少々時間を要するので、正座して待ちましょう。

使用するnode.jsを選択する

インストールが完了しても、まだnode.jsは使えません。
useコマンドを使ってどのバージョンを使用するかを選択する必要があります。

./nave.sh use latest

これで、最新版のnode.jsへのパスが通り、
nodeコマンドが使用可能になります！おめでとう！

ただし、一度ログアウトすると未選択に戻ってしまい、毎度useしてあげないといけません。
煩わしい場合は.bashrcにでも書いておくか、usemainコマンドを使ってみるか。

注意点としては、”use latest”した時に最新版が未だインストールされてないと、
長～いインストールが開始されてしまいます。
なので、.bashrcとかに書く場合はバージョンを決め打ちしておいた方が良い気がします。

./nave.sh use 0.4.1

すでにインストール済みのnode.jsのリストは、”nave ls”で見られます。

./nave.sh ls

ついでにnpmも入れておく

npm – Node Package Manager

npmというのは、node.js用のパッケージマネージャ。
せっかくなので入れておきましょう。
公式いくとワンラインインストールのコマンドが書いてあるので、それで瞬殺です。

curl http://npmjs.org/install.sh | sh

テストする

node.js公式にあるスクリプトでHello,Worldしてみましょう。

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

このスクリプトを「example.js」等に保存して次のコマンドを入力。

node example.js

あとはWebブラウザで「http://127.0.0.1:8124/」にアクセスして
「Hello World」が表示されれば成功です。
たったこれだけでWebサーバが立ち上がっちゃうなんて素敵ですね。

巷で話題のnode.jsを入れて、ちまちま弄ってみてます。
一体どんな事が出来るようになるのか、イベントドリブンとやらに期待が高まりますね。

ちなみに、「nvm」（Node Version Manager)なんてのもあるみたいです。
» creationix/nvm – GitHub

autocmplpop.vimを導入

AutoComplPop – Automatically opens popup menu for completions : vim online

デフォルトのままのVimでは、やの後に、
, とする事で入力候補をポップアップで表示させる事が出来ます
…が、ちょっとまどろっこしい。

これを自動的にポップアップしてくれるようにしてくれるのが
このAutoComplPopというプラグインです。
導入方法はディレクトリにコピーするだけなので割愛。

尚、当方のUbuntu環境ではl9.vimも必要とされました。
うまく動かなかったら一緒に導入してやりましょう。

L9 – Vim-script library : vim online

導入後の設定

以下が、導入後の設定を極めて分かりやすく紹介してくれている記事。

autocomplpop.vimでリアルタイムにキーワード補完 – ナレッジエース

以下、リンク先の記事より拝借・抜粋させて頂きます。

ポップアップ中でもEnterキーで候補決定しない様に設定

候補を無視して改行を入力したい場合もあるので、
ポップアップ中のEnterキーで決定しないようにします。
修正箇所は、autoload/acp.vimの192行目付近。

if pumvisible()
    " a command to restore to original text and select the first match
    return "\<C-p>"
endif

これだとEnterでポップアップが消えるだけで、その時はまだ改行は挿入されません。
私はこっちのほうが使いやすいのですが、改行を挿入したい場合はvimrcに下記を追記。

inoremap <expr> <CR> pumvisible() ? "\<C-y>\<CR>" : "\<CR>"

他にもTabで候補を巡回する為の設定等も掲載されていましたが、
私は無い方が使いやすかったので、割愛致します。詳しくはリンク先で！

『オプション ‘omnifunc’ は設定されていません』

…なんていうエラーが吐かれた場合の対処について。

当方の環境では挿入モードで「<」を入力中に上記のエラーが吐かれました。
omnifuncというのはオムニ補完、つまり入力補完のポップアップの事らしく、
これを設定してあげれば黙るかな？というわけで設定してみました。

setlocal omnifunc=syntaxcomplete#Complete

無事静かになってくれました。
参考：Ubuntu日本語フォーラム / vim autocomplpop エラーについて

ついでなのでPHPの辞書を突っ込んでおこう

異常に関数の多いPHPこそ入力補完が役に立ちますね。
辞書ファイルはただ改行で候補を連ねるだけなので、簡単に作成出来ます。

参考：Vim で PHP 関数の辞書を作成する方法についてのメモ

上記リンクより抜粋。多謝！
こちらのコードを走らせる事で辞書ファイルを生成出来ます。

<?php
$keywords = array(
    'if', 'else', 'elseif', 'endif', 'while', 'endwhile', 'do', 'as', 'for', 'endfor', 'foreach', 'endforeach',
    'break', 'continue', 'switch', 'endswitch', 'case', 'default', 'declare', 'enddeclare',
    'try', 'catch', 'return', 'exit', 'const', 'class', 'function',
    'require', 'include', 'require_once', 'include_once',
    'abstract', 'final', 'interface', 'private', 'protected', 'public', 'static',
    '__LINE__', '__FILE__', '__DIR__', '__FUNCTION__', '__CLASS__', '__METHOD__', '__NAMESPACE__'
);
$functions  = function_exists( 'get_defined_functions'   ) ? get_defined_functions()   : array();
$constants  = function_exists( 'get_defined_constants'   ) ? get_defined_constants()   : array();
$interfaces = function_exists( 'get_declared_interfaces' ) ? get_declared_interfaces() : array();
$classes    = function_exists( 'get_declared_classes'   ) ? get_declared_classes()  : array();

$arrays = array_merge(
    $keywords,
    $functions['internal'],
//  array_keys( $constants ),   // 定数を補完したい場合はこの行を有効にする
    $interfaces,
    $classes
);
sort( $arrays );
$arrays = array_unique( $arrays );
echo implode( "\n", $arrays );

生成した辞書ファイルをvimrcで登録しておけば完了です。

autocmd FileType php :set dictionary=~/.vim/dict/php.dict

Windowsの場合は下記のような感じ。
“$VIM”はgVim.exeがインストールされているパスです。

autocmd FileType php :set dictionary=$VIM/vimfiles/dict/php.dict

辞書は必要に応じて追加していきましょう。
ActionScriptなんかも欲しいなぁ…

ひとまずこんな感じで、Win/Linux共にまともに動いてくれています。
オムニ補完はバッファの中身のみならず、
辞書を設定しておけば辞書内からも候補を表示してくれる優れもの。
Linxではパスの入力もこれでかなり楽になりますね。

ノートでのコーディングがとても快適になりました！すごいやVim！

※Subversionが既に導入されているlinux環境が対象です。

まず、英語版の取得から。
インストールしたいバージョン（ここでは3.0.1）のリポジトリから、
現在のディレクトリにファイルをチェックアウトします。

svn co http://core.svn.wordpress.org/tags/3.0.1/ .

※ベータ版が使用したい場合は、こちらのURLを使いましょう。

→ http://core.svn.wordpress.org/trunk/

※他のバージョンを使用したい場合は、こちらから選びます。
→ http://core.svn.wordpress.org/tags/

次に日本語化ですが、こちらもリポジトリで公開されているので
一時ディレクトリ（ここでは「jp」）を作ってそこに取得します。

$ mkdir jp $ svn co http://svn.automattic.com/wordpress-i18n/ja/tags/3.0.1/ jp/

取得された日本語リソースのうち、messageディレクトリ内のmoファイルを
wp-content/languages/ にコピーします。

$ mkdir wp-content/languages $ cp jp/messages/*.mo wp-content/languages

仕上げは、wp-config.php を作成して、言語の設定をしてやります。

$ cp wp-config-sample.php wp-config.php $ vi wp-config.php

該当の部分はここ。
WPLANGの値が空白になっているので「ja」を入れてあげます。

define ('WPLANG', 'ja');

せっかくwp-config.phpを開いているので、
ついでにDBの設定なんかもやっておきましょうね。

これで無事日本語環境になりましたでしょうか。
SVNで管理しておけばバージョンの上げ下げも比較的楽になるはずですね。

参考サイトなど

• 20 Steps to a Flexible and Secure WordPress Installation | Nettuts+
• WordPress | 日本語 » 日本語リソースのインストール

追記

GitHubにも同期されたリポジトリがあるので、
より身近なgit環境で作業しても良いですね。

• WordPress/WordPress

VI Editor / Linux Terminal Cheat Sheet (PDF) – Smashing Magazine

こんなかんじに綺麗にまとめられています。
リンク先ではPDFにてダウンロード出来るので、印刷して目につくところに貼っておくと便利。
私も本当に限られた機能しか使っていなかったので、重宝しそうです。

VIのチートシートとしては、このグラフィカルなやつも結構有名ですね。

Graphical vi-vim Cheat Sheet and Tutorial

これはデスクトップの壁紙にして使えそう。

この手のチートシートで日本語で書かれたものはあまり見かけないですが、
必要とする人の多くが英語で十分だと感じているからでしょうか。
それとも面倒だからでしょうか。（まぁもちろん面倒ですが！）

面倒くさがりやの私は感謝の気持ちを胸に、
ありがたく活用させて頂きたく思います。