最高のアプリケーションがあっても、それが適切に構成されていないホストの上で動いているのでは十分なパフォーマンスを出す事は出来ません。この記事では、パフォーマンスチューニングの4つの主要分野とそれぞれ何を見ればいいかを紹介したいと思います。それに加えて、Javaベースのアプリーションではガーベジコレクション・サイクルのようにパフォーマンスチューニングに影響を与える前提が存在します。この記事では、ガーベジコレクションに関して知っておくべきことについても紹介しようと思います。

1. CPU（中央処理装置）
2. メモリー
3. ディスク（ディスクスペースとアクセス速度の両方）
4. ネットワーク

これらの領域はしばしば相互に影響を与え合っています。例えば、メモリーをキャッシュに割り当てることでディスクアクセスを減らすことや、ローカルディスクから読み出すのではなくネットワーク越しにリソースアクセスをすることもあり得ます。この記事では、メモリについては、JVM（Java Virtual Machine）に特に焦点を当てたいと思います。JVMには独自のメモリ管理システムが存在し、あなたはそれを監視・構成しなければなりません。

CPU

サーバーのCPUは大部分の時間を処理の待ち時間に費やしています。その中でも最も多いのが、ディスクからデータが返されるのを待つことです。マルチタスキングでは、CPUが待ち状態の時間に他のことを処理させるようとします。そのため、より早いCPUを購入することは、CPUの処理待ちに費やしていた時間を有効活用することが出来ます。

vmstatコマンドは、システムがどの作業に時間を費やしているかをリアルタイムに分解して表示してくれます。また、sarコマンドは長期のモニタリングに適したツールです。これらのツールにより、CPUが大部分の時間をユーザー時間に費やしており、アイドルサイクルが低下し続けているのが確認出来たのであれば、次の一手を考えるべき時です。このシチュエーションでは、負荷を他のサーバーに振り分けるか、CPUのキャパシティを増やす必要があります。

負荷によっては、パラレルに処理させることが不可能な場合があり、複数サーバーに負荷を分散させたり、CPUを追加することでは解決しない場合があります。その場合は、より高速のCPUを投入し、問題になっている処理のコードをより少ないサイクルで動くように最適化するのに時間を費やして下さい。

メモリー

メモリーチューニングにはいくつかの項目が関連してきます。最も単純な方法は、アプリケーションがスワップ領域を使用することがないだけの十分なRAMを搭載することです。OSの仮想メモリではアプリケーションに対して実際にシステムに搭載している以上のメモリを割り当てることを可能にします。そして、メモリが不足した場合には、ディスク上の一時的な保存領域で補おうとします。メモリのページアウトとディスクからのページインはRAMに直接アクセスした場合と比べて著しく遅くなります。そのため、この動作は出来るだけ回避すべきです。

仮想メモリについては、チューニングが必須だと言われています。それは、システムがメモリを使い切る前に、ディスクへ書き出すことが出来るためです。そして、問題が発生した時にスワップ領域を調べなくてはならなくなるのです。重要なことは、いつ仮想メモリが使われているかを突き止めることです。UNIXでは、フリーなメモリーが割り当てられる際、スワップアウトさせる候補となるメモリーページを探し出すことをカーネルは最終的には決断せざるを得なくなります。そしてその直後、処理するためにメモリへの割り当てが必要なプロセスの存在をカーネルが検知し、スワップ候補となったページのいくつかをディスクにスワップさせます。もし負荷を処理出来るだけの十分なメモリが搭載されていたら、スワップによる遅れを排除することが出来ます。

Solarisでは、/etc/systemファイルでチューニングが可能です。IBM AIXでは、vmoコマンドが利用出来ます。Linuxでは、/etc/sysctl.confです。これらの挙動はOSの進化に従い絶え間なく変化しています。そのため、設定変更の前には十分な調査を実施して下さい。

最後に、余計なメモリが手元にあるならば、ファイルシステムのファイルキャッシュやメモリのメタデータに使う事が出来ます。大部分のUNIXでは、空いたメモリはキャッシュに使おうとします。これが、システムに空きメモリがないように見える原因です。これによりディスクアクセスが減るので、ウェブサーバーへの負荷に重要な影響を与えることとなります。

【訳注】 「パフォーマンスチューニングの応用概念 Part 2」に続きます。

【訳注】 「シェルスクリプト作成のテクニック Part 3」の続きのエントリーです。

デバッグする

スクリプトを書き終えたら、プログラムを動かしてみる時間です。ところが、スクリプトを実行したところ、予期しないエラーが表示されてしまいました。原因はなんでしょう？この世の中に完全無欠な人なんていません。スクラッチからスクリプトを書き始め、エラーが出なくなるようにするまでに多くの時間と試行錯誤を要します。たいていの場合、文字が抜けていたり、間違った文字になっていたりしているのが原因で、どうしても見逃してしまうようです。それでもご安心下さい。AIXを含むUNIXやLinuxのシェルには、デバッグを助けてくれる機能があります。

Listing 10: エラーを含むスクリプトの例

#!/bin/bash

_X=1
while [[ ${_X} -le 10 ]]
do
  [[ ${_X} -lt 5 ]] && echo "X is less than 5!

  _Y=`expr ${_X) + 1`

  if [[ ${_Y} -eq 6 ]]
    echo "Y is now equal to ${_Y}"
  fi

  _X=${_Y}
done

しかし、最初にこのスクリプトを実行してむると、以下のようなエラーが表示されます。

# ./make_errors
./make_errors: line 11: unexpected EOF while looking for matching `"'
./make_errors: line 16: syntax error: unexpected end of file

あなたがすでに使っている可能性があり、それにも関わらずあまり知られていない優れたデバッグツールがVimです。Vimは強力なテキストエディターであると同時に、デバッグでも非常に役に立ってくれます。もし、あなたが.exrcや.vimrcファイルを設定し、特定のエラー状況をカラーで表示してくれるようにしているならば、Vimは図1で表示されるようにあなたの仕事の大部分をやってくれるでしょう。

図1: Vimでデバッグする

:::画像1:::

最初のエラー「line 11: unexpected EOF while looking for matching `"'」は、11行目で何かが起こっていると言っていますが、その行を見てみても、何が悪いかよく分かりません。それでは6行目を見てみましょう。ダブルクオーテーションマーク（"）がechoされている文字列の最後から抜けています。これはデバッグの際に実際にスクリプトを見ないといけないという典型的な例です。エラーとして表示される列が必ずしも実際のエラー発生行とは限りません。11行目がエラー発生行として表示されているのは、6行目でダブルクォーテーションで囲まれ始めて、11行目まで閉じられなかったからです。エラーを修正するには、6行目の最後にダブルクオーテーションを追加します。

それとは別にエラーがあると表示されているのは8行目です。ここでは、変数_Xの閉じる丸括弧「)」が赤くハイライトされています。ここではVimがあなたの代わりに何が悪いか表示してくれました。変数_Xは波括弧「{」で始まっているのに正しく閉じられていません。「)」から「}」に変更しておきましょう。

今のところ2つのエラーを修正するのによい仕事をしてくれています。それではスクリプトを再実行してみましょう。

./make_errors: line 12: syntax error near unexpected token `fi'
./make_errors: line 12: `  fi'

別のエラーがあるようです。エラーは12行目に問題があると言っていますが、そこにはif文を閉じるfiしかありません。何が駄目なんでしょうか？前のエラーの時はどんなだったか思い出して下さい。必ずしもすべてのエラーがシェルが問題があると指摘した行にあるわけではありません。シェルは単純にエラーが発生したと言っているだけで、実際のエラー原因はシェルが失敗を報告した行以前にある可能性があります。この小さなスクリプトではほぼ間違いなく、if文自体に問題があると思われます。シェルスクリプトの基本ロジックに立ち戻り、if文がifとthenとfiから構成されていることを思い出しましょう。それでは見直してみましょう。どうやらthenが抜けているようです。単純にthenをスクリプトに追加するだけです。それが完了すると、Listing 11のようなスクリプトになります。

Listing 11: Listing 10のスクリプトを修正したもの

#!/bin/bash

_X=1
while [[ ${_X} -le 10 ]]
do
  [[ ${_X} -lt 5 ]] && echo "X is less than 5!"

  _Y=`expr ${_X} + 1`

  if [[ ${_Y} -eq 6 ]]
  then
    echo "Y is now equal to ${_Y}"
  fi

  _X=${_Y}
done

それではもう一度スクリプトを実行してみましょう。

# ./make_errors
X is less than 5!
X is less than 5!
X is less than 5!
X is less than 5!
Y is now equal to 6

おめでとうございます！スクリプトは想定通りに動くようになりました。

set -xオプション

しかしながら、シェルスクリプトのトラブルシューティングの方法は上記の例のように単純にはいかないことがあります。予想外の失敗が発生し、壁に頭を叩きつけても、失敗の原因が分からない時、最終手段として銃を取り出すしかないのでしょうか。kshとbash、それ以外の最新のシェルにはsetコマンドに-xオプションが含まれています。このset -xオプションを使うことにより、展開や評価されるすべてのコマンドが標準出力に表示されるようになります。評価されたコードを標準出力に出力する際、set -xはPS4変数の値を使用し、すべての行が出力されているかのように表示します。大量のテキストが出力されるので、辛抱強く内容を追いかけないといけないことは覚えておいて下さい。

以前取り上げたスクリプト例のループカウント数を少し減らし、set -xをスクリプトの冒頭に追加し、コメントも付けてみました。その後、これを実行してみます。Listing 12が修正したスクリプトです。

Listing 12: set -xの例

#!/bin/bash

set -x

# loop through and display some test statements
_X=1
while [[ ${_X} -le 4 ]]
do
  [[ ${_X} -lt 2 ]] && echo "X is less than 2!

  _Y=`expr ${_X} + 1`

  if [[ ${_Y} -eq 3 ]]
  then
    echo "Y is now equal to ${_Y}"
  fi

  _X=${_Y}
done

スクリプトを実行する前に、PS4変数の値を標準出力に表示させたいものに変更します。

# export PS4="DEBUG => "

次に、Listing 13のようにおそらく有益であろう情報の爆撃を自分自身に向かって送り付けてあげましょう。

Listing 13: set -xの出力例

# ./make_errors
DEBUG => _X=1
DEBUG => [[ 1 -le 4 ]]
DEBUG => [[ 1 -lt 2 ]]
DEBUG => echo 'X is less than 2!'
X is less than 2!
DDEBUG => expr 1 + 1
DEBUG => _Y=2
DEBUG => [[ 2 -eq 3 ]]
DEBUG => _X=2
DEBUG => [[ 2 -le 4 ]]
DEBUG => [[ 2 -lt 2 ]]
DDEBUG => expr 2 + 1
DEBUG => _Y=3
DEBUG => [[ 3 -eq 3 ]]
DEBUG => echo 'Y is now equal to 3'
Y is now equal to 3
DEBUG => _X=3
DEBUG => [[ 3 -le 4 ]]
DEBUG => [[ 3 -lt 2 ]]
DDEBUG => expr 3 + 1
DEBUG => _Y=4
DEBUG => [[ 4 -eq 3 ]]
DEBUG => _X=4
DEBUG => [[ 4 -le 4 ]]
DEBUG => [[ 4 -lt 2 ]]
DDEBUG => expr 4 + 1
DEBUG => _Y=5
DEBUG => [[ 5 -eq 3 ]]
DEBUG => _X=5
DEBUG => [[ 5 -le 4 ]]

ご覧の通り、大量の情報が表示されます。すべてのコマンドが評価され、実行されています。また、デバッグ情報ではコメント行の内容が出力されていないことにも気付くはずです。これはコメント行の文字列といのは評価はされるけど、実行されていないからです。ありがたいことに、最初に修正して以降もスクリプトには問題はないようです。

一つだけ覚えておいて欲しいのは、set -xを使用した際、そのスクリプトに内部関数がある場合に、set -xオプションは子供の関数にも引き継がれるということです。しかし、set -xが内部関数にしか含まれない場合、その内部関数で実行されるコードとその子供の関数にしかデバッグオプションは引き継がれず、親のスクリプト部分には影響を及ぼしません。そのため、子供の関数が呼び出したルーチンが何をしているのか分からなくなります。

結び

私たちはシェルスクリプトであれ、Cであれ、Javaであれ、その他の言語であれ、プログラミング技術を向上させようとしています。コードは簡潔にし、明快かつ柔軟性を持ち、文書化を怠らないという基本ルールを守っていれば、あなたが学んだデバッグ手法から学ぶことがほとんどないような優れたシェルスクリプトを書けるようになるはずです。頑張ってください！

【訳注】 「シェルスクリプト作成のテクニック Part 2」の続きのエントリーです。

文書化、文書化、文書化

自分のキャリアを振り返ってみた時、この問題の犠牲にならなかった人がいないはずがありません。もしかしたらあなたも、すでに退職された方が書いた10年前のスクリプトを調べてもらえないかとお願いされたことはありませんか？その時、「ええ、いいですよ」と快諾出来ましたか？問題ない場合もあるでしょう。しかし、そのスクリプトが複雑だったり、あなたにとって馴染みのないコマンドが使われていたり、あなたが慣れ親しんだものとはまったく異なるスタイルだったり、単純に動かなかったりした場合、作者がスクリプトを作成した時に何を意図していたかヒントが記述されていれば、本当に助かるものです。あるいは、貴方がスクリプトを作成し、それは一回限りのもので二度と使うことはないとします。その場合も文書化は必要ないと言い切れるでしょうか。また、数週間の用途で巨大なスクリプトを作成し、あなたはその動作のすべてを把握している場合でも、他の人がそれを見ることになった場合、その人は困惑してしまうかもしれません。ここではスクリプトの文書化がユーザーだけでなく開発者にとっても重要である理由をいくつかの例から紹介していきたいと思います。

Listing 6: コメントのないスクリプトの例

confirm_and_exit() {
  [[ ${_DEBUG_LEVEL} -ge 3 ]] && set -x
  while [[ -z ${_EXIT_ANS} ]]
  do
    cup_echo "Are you sure you want to exit? [Y/N]  
        \c" ${_PROMPT_ERR_ROW} ${_PROMPT_ERR_COL}
    ${_TPUT_CMD} cnorm
    read ${_NO_EOL_FLAG:+${_READ_FLAG:-'-n'}} ${_NO_EOL_FLAG} _EXIT_ANS
    ${_TPUT_CMD} civis
  done

  case ${_EXIT_ANS} in
    [Nn])  unset _EXIT_ANS; return 0;;
    [Yy])  exit_msg 0 1 "Exiting Script";;
       *)  invalid_selection ${_EXIT_ANS}; unset _EXIT_ANS;;
  esac
  return 0
}

あなたがスクリプトに精通されている方なら、これを読むことが出来ると思います。しかし、スクリプトの勉強中の方がこれを見た場合、この関数が何をしているのか分からないかもしれません。数分間の時間を確保してスクリプトにコメントを追加するだけで、状況は一変します。Listing 7ではコメントを付けた同じ関数を表示しています。

Listing 7: コメントの付いたスクリプトの例

#########################################
# 関数名 confirm_and_exit
#########################################
confirm_and_exit() {
  # デバッグレベルが 3 以上に設定されている場合は、評価されたすべての行が標準出力に出力されます
  [[ ${_DEBUG_LEVEL} -ge 3 ]] && set --x

  # ユーザーが正しい回答を入力されるまで、プロンプトを表示し続ける
  while [[ -z ${_EXIT_ANS} ]]
  do
    # スクリプトを抜けるかどうかユーザーにプロンプトを表示する
    # 関数 cup_echo は tpu cup   をコールします
    # 構文:
    # cup_echo <表示させる文字列> <表示させる行番号> <表示させる列番号>
    cup_echo "Are you sure you want to exit? [Y/N]  
        \c" ${_PROMPT_ERR_ROW} ${_PROMPT_ERR_COL}

    # tput を使ってカーソルを通常に戻す
    ${_TPUT_CMD} cnorm

    # ユーザーが入力した値を読み取る
    # 変数 _NO_EOL_FLAG が設定されている場合は、_READ_FLAG の値か、"-n"を使う
    # 変数 _NO_EOL_FLAG が設定されている場合は、read から読み込まれた値を文字列として用いる
    # ユーザーが入力した値を変数 _EXIT_ANS に設定する
    read ${_NO_EOL_FLAG:+${_READ_FLAG:-'-n'}} ${_NO_EOL_FLAG} _EXIT_ANS

    # tput を使ってカーソルを非表示にする
    ${_TPUT_CMD} civis
  done

  # ユーザーが"n"を入力した場合は、リターンコード 0 を返し、コードの一個前のブロックに戻る
  # ユーザーが"y"を入力した場合は、スクリプトを抜ける
  # ユーザーがそれ以外の値を入力した場合は、関数 invalid_selection を実行する 
  case ${_EXIT_ANS} in
    [Nn])  unset _EXIT_ANS; return 0;;
    [Yy])  exit_msg 0 1 "Exiting Script";;
       *)  invalid_selection ${_EXIT_ANS}; unset _EXIT_ANS;;
  esac

  # リターンコード 0 を返して関数を抜ける
  return 0
}

こんな小さな関数に対してやるには極めて退屈で過剰な作業かもしれませんが、コメントに記載されている内容は、初心者のシェルスクリプターや関数の内容を調べる人間にとって極めて有益な情報と言えます。

他にシェルスクリプトのコメントの有効活用の例としては、リターンコードと変数の説明が挙げられます。

Listing 8はあるシェルスクリプトの冒頭部分です。

Listing 8: 文書化されていない変数の例

#!/usr/bin/bash
trap 'exit_msg 1 0 "Signal Caught. Exiting..."' HUP INT QUIT KILL ABRT
trap 'window_size_changed' WINCH

_MSG_SLEEP_TIME=3
_RETNUM_SIZE=6
_DEBUG_LEVEL=0
_TMPDIR="/tmp"
_SP_LOG="${0##*/}.log"
_SP_REQUESTS="${HOME}/sp_requests"
_MENU_ITEMS=15
LESS="-P LINE\: %l"
export _SP_REQUESTS _TMPDIR _SP_LOG _DB_BACKUP_DIR 
    export _DEBUG_LEVEL _NEW_RMSYNC _RMTOTS_OFFSET_COL

繰り返しになりますが、これらの変数が何を目的として、どんな値が入るのかを理解するのは極めて困難です。スクリプトを全部読んでみない限り、これらの変数だけでは何も分かりません。それに加えて、このスクリプトで使われているリターンコードに関する言及はありません。こうなるとシェルスクリプトのトラブルシューティングは必要以上に難しいものとなります。Listing 8にリターンコードの意味を説明したセクションを追加して、紛らわしさをなくしましょう。Listing 9を見て下さい。

Listing 9: 文書化された変数の例

#!/usr/bin/bash
#########################################################################
# trap
#########################################################################
# ユーザーがスクリプトを抜ける際のtrap
trap 'exit_msg 1 0 "Signal Caught. Exiting..."' HUP INT QUIT KILL ABRT
trap 'window_size_changed' WINCH                # ユーザーがウインドウをリサイズした時のtrap
#########################################################################

#########################################################################
# 定義済み変数/export された変数
#########################################################################
_MSG_SLEEP_TIME=3             	       # すべてのメッセージで使われる sleep の秒数
                                      # (未定義の場合、デフォルトは 3 秒になる)
_CUSTNUM_SIZE=6                       # この場所での顧客番号の長さ
                                      # (未定義の場合、デフォルトは 6 になる)
_DEBUG_LEVEL=0                        # デバッグメッセージをログする。ログレベルは累積
                                      # (例： 1 は 1、2 は 1 と 2、3 は 1 と 2 と 3 )
                                      # (未定義の場合、デフォルトは 0 になる)
                                      # ログレベル:
                                      #  0 = メッセージなし
                                      #  1 = 簡単なメッセージ (スクリプトの開始やエラーなど)
                                      #  2 = 環境の設定 ( set や env )
                                      #  3 = set -x を実行 (しつこいくらいメッセージが出る)
_TMPDIR="/tmp"                        # 作業ファイルや一次ファイルを格納するディレクトリ
                                      # (未定義の場合、デフォルトは /tmp になる)
_SP_LOG="${0##*/}.log"                # スクリプトファイルのログ
_SP_REQUESTS="${HOME}/sp_requests"
			               # 顧客レコード要求のファイル
                                      # 開始時に読み込まれる
_MENU_ITEMS=15                        # ページ単位に表示するアイテムのデフォルト数
                                      # (未定義の場合、デフォルトは 10 になる)
LESS="-P LINE\: %l"                   # 'less'プロンプトをフォーマットする。詳しくは MAN less を参照


# 上記で定義した変数を export する
export _MSG_SLEEP_TIME _CUSTNUM_SIZE _DEBUG_LEVEL _TMPDIR 
    _SP_LOG _SP_REQUESTS _MENU_ITEMS
#########################################################################

分かりやすくなりましたか？すべての変数が組織化と詳細化されたため、初めてこのスクリプトを読む人でもこのプログラムが何であるか判断しやすくなったはずです。

【訳注】 「シェルスクリプト作成のテクニック Part 4」に続きます。

【訳注】 「シェルスクリプト作成のテクニック Part 1」の続きのエントリーです。

スクリプトは柔軟に

初心者がプログラミングする際に直面する別の問題が、プログラムやシェルスクリプトの中に静的な値をハードコードしてしまうことです。これはスクリプトの柔軟性を損なってしまい、要するに悪いプログラミングだとみなされます。スクリプトを動かすためにシステム管理者や開発者がその都度スクリプトを修正するのではなく、他の値を与えた場合にもスクリプトが動くように、変数と引数をスクリプトや関数に追加しておきましょう。

Listing 3: 柔軟性のないスクリプトの例

#!/bin/bash

if [[ -f /home/cormany/FileA ]]
then
  echo "Found file '/home/cormany/FileA'"
elif [[ -f /home/cormany/DirA/FileA ]]
then
  echo "Found file '/home/cormany/DirA/FileA'"
else
  echo "Unable to find file FileA"
fi

このスクリプトは一つのファイルを2つの場所から探すことしか出来ない用途の限定的なスクリプトです。

もっと考え方を広げてみましょう。Listing 4では同じような動作をしますが、どんなファイルでも、どんな場所からでも探すことが出来るようにしてみましょう。

Listing 4: より柔軟性の増したスクリプト

#!/bin/bash

exit_msg() {
  [[ $# -gt 1 ]] && echo "${0##*/} (${1}) - ${2}"
  exit ${1:-0}
}

[[ $# -lt 2 ]] && exit_msg 1 "Usage: ${0##*/}  "

_FNAME="${1}"
_DNAME="${2}"

[[ ! -d "${_DNAME}" ]] && exit_msg 2 "Unable to read or find directory '${_DNAME}'"

if [[ -f "${_DNAME}/${_FNAME}" ]]
then
  exit_msg 0 "Found file '${_DNAME}/${_FNAME}'"
else
  exit_msg 3 "Unable to find file '${_DNAME}/${_FNAME}'"
fi

この例ではより柔軟になりました。ユーザーは探して欲しいファイルと探したい場所を入力できるようになりました。

オプションを追加する

シェルスクリプトを作成する際、ある人が「これがあれば便利だよね！」とか「これもやってくれるなんて凄いよね！」と言っている一方で、他の人はそんなものはいらないと思っていたり、そんな余計な動作はして欲しくないと思っていたりします。人々は選択出来ることを喜びます。それならば彼らにオプションを与えましょう。ビルトインされているシェルコマンドのgetoptはこの役割をしてくれます。

Listing 5は、AIXでgetoptがどのように動作するかを説明した例です。

Listing 5: getoptの例

#!/usr/bin/ksh

_ARGS=`getopt -o x --long xxxxx -n ${0##*/} -- "$@"`
while [[ $# -gt 0 ]]
do
  case "${1}" in
    -x|--xxxxx)  echo "Arg x hit!"; shift;;
            --)  shift; break;;
             *)  echo "Invalid Option: ${1}"; break;;
  esac
done

getoptを含むスクリプト（ここでは仮にopttestとします）を実行する際、-xまたは--xxxxxという有効な引数を与えると、getoptはswitch判定を行い、case switchの中のコードを実行します。

# ./opttest -x
Arg x hit!

今度は無効なswitchオプションを与えて実行してみます。

# ./opttest -a
Invalid Option: -a

【訳注】 「シェルスクリプト作成のテクニック Part 3」に続きます。

他のUNIXやLinuxと同じように、IBM AIXにはシステム管理者や開発者、そしてユーザーが日時タスクや業務の効率化に取り組む際に味方となる強力なツールが存在します。その一つがシェルスクリプトです。

とはいえ、UNIXと数年付き合い、シェルスクリプトに手を出してきた人でも、オペレーティングシステムの裏側については勉強中で、まだまだスクリプトをマスターとしたとは言えない人も多いと思います。この記事では、シェルスクリプトとは何かから始まり、より高度なスクリプトを書く方法をご紹介します。一般的なプログラミングの基礎から簡潔なスクリプトの書き方、より柔軟性のあるスクリプトの書き方、明快なスクリプトの書き方、スクリプト内のドキュメンテーション方法、そしてスクリプトのデバッグがその内容です。

シェルスクリプト学習の世界に入ってきた人々が直面する問題の一つが、すでにスクリプト内に記述した処理をもう一度記述しようとしてしまうことです。それらの処理をコピーして、ハードコードされた値を変更するのではなく、関数を作って両方の処理を扱えるようにすることで、スクリプトを簡潔にすることが出来ます。関数を一箇所に集めれば、スクリプトが標準化され、一定の形式を保つことが出来ます。スクリプトのある箇所から呼び出された関数が正常に動くならば、他の箇所から呼び出されても正しく動く可能性がある程度保障されます。

それでは例題です。Listing 1のスクリプトを凝縮させ、短くより明快なプログラムへと簡潔化させて下さい。

Listing 1: より簡潔に記述できるスクリプトの例

#!/usr/bin/ksh

if [[ $# -lt 2 ]]
then
  echo "Usage: ${0##*/}  "
  exit 0
fi

if [[ ! -f "${1}" ]]
then
  echo "Unable to find file '${1}'"
  exit 1
fi

if [[ ! -r "${1}" ]]
then
  echo "Unable to read file '${1}'"
  exit 2
fi

gzip ${1}
ls -l ${1}.gz


if [[ ! -f "${2}" ]]
then
  echo "Unable to find file '${2}'"
  exit 1
fi

if [[ ! -r "${2}" ]]
then
  echo "Unable to read file '${2}'"
  exit 2
fi

gzip ${2}
ls -l ${2}.gz

このスクリプトは本当にひどいと思います（有難いことにこれはただの例題です）。スクリプトは出来るだけ凝縮させましょう。読者の目の疲労も考えて、Listing 2ではより明快なバージョンのスクリプトを掲載します。

Listing 2: Listing 1のスクリプトを凝縮させたもの

#!/usr/bin/ksh

exit_msg() {
  [[ $# -gt 1 ]] && echo "${0##*/} (${1}) - ${2}"
  exit ${1:-0}
}

[[ $# -lt 2 ]] && exit_msg 0 "Usage: ${0##*/}  "

for _FNAME in $@
do
  [[ ! -f "${_FNAME}" ]] && exit_msg 1 "Unable to find file '${_FNAME}'"
  [[ ! -r "${_FNAME}" ]] && exit_msg 2 "Unable to read file '${_FNAME}'"

  gzip ${_FNAME}
  ls -l ${_FNAME}.gz
done

違いに気付かれましたか？メッセージの表示とリターンコードを返すための簡単な関数を追加しました。また、すべての引数をforループで処理させることにより、より簡潔で理解しやすくしました。

【訳注】 「シェルスクリプト作成のテクニック Part 2」に続きます。

ここ最近、ブログやTwitterやIMで私が議論してきたのは、新しくて流行っているものに人々がどれほど興味を惹かれるかということです。別にこれは批判しているわけではありません。むしろ私なんかがそんな傾向を持った人の最たるものですから。私の上司はこれを“ヒカリモノ症候群”と呼んでいます。「Freindsterを見てみろよ」「いや、これからはMySpaceだ。」「はぁ？Facebookだろ。」「これからはSecond Lifeの時代だよ。」「いやいや、Twitterでしょ。」なんてことを何度も何度も繰り返しているんです。Web 2.0の世界というのは、この「新しくてクールなもの」というミームで成り立っています。Go2Web2.0をちょっと見てください。私が何を言いたいか分かると思います。

先日のエントリーは、この現象をちょっと皮肉めかして書いたみたというわけです。もし今日、Lotus Notesが初めて発表されたとしたら、現在話題になっている機能なんて簡単に実現することが出来るんだよ、ということをちょっと強調して書いてみました（それに加えて、セキュリティ面やオフライン機能、複製機能、ディレクトリ機能などについても、今日まで発表されてきたどの製品よりも優れていると個人的には思っていますが、それはまた別の話ということで）。しかし、どの製品も成功するためには、話題性と勢いが必要です。私のIBMの同僚であるLauren Cooney（彼とはTwitterで知り合いました）が教えてくれた、ハーバードビジネスレビューのクチコミマーケティングに関する記事のように、製品の成功というのにはユーザの助けというのが不可欠なものです。

【訳注】原文はジョークに走ったところがあるので、後半部分は割愛し、それ以前のエントリーも訳者の意図で一部内容を再構成しています。純粋な翻訳ではありませんので、ご了承下さい。