目次

• 「Wonderful Server Life」　　　　第85回　　　田畑 英和
• 小池邦人のCarbon視点でiPhone探求
• ターミナルの向こうから　　　　　　第40回　　海上 忍　
• DEMOsa KITAレポート　　　　　　　　　　　　　　 曽我 聰起

「Wonderful Server Life」　　第85回　　田畑 英和

〜「Podcast Producer」編〜

　さて今回からPodcast Producerについて解説していきます。このサービスもiCalサーバと同様にLeopard Serverから新しく追加されたサービスの1つです。今回はまずPodcastの概要を解説し、次回からは具体的な使用方法などの詳細を解説していく予定です。

◇Podcastとは
　皆さんはPodcastを利用したことはありますでしょうか。まだ利用したことがない方は、まずは実際に利用してみると具体的にどういったものかはすぐに分かるでしょう。iTunes Storeを利用できる環境であればいつでもPodcastを楽しむことができます。iTunes Store上でのPodcastはカテゴリーごとに分類されていて、様々なコンテンツが揃っています。例えばApple関連ですと次の
ようなものがあります。

・Apple Keynotes
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=275834665
・Quick Tours Leopard Server
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=279805844

　「Apple Keynotes」では過去開催されたMacWorldやSpecial Eventのビデオが視聴でき、「Quick Tours Leopard Server」ではLeopard Serverに関する紹介ビデオを視聴することができます。
　動画コンテンツだけではなく音声のPodcastもあります。つまりInternetのラジオ／テレビ番組といえば分かりやすいでしょうか。ただし、生放送ではありませんので、コンテンツはあらかじめダウンロードしておき、いつでも再生することができます。
　iTunesでPodcastをダウンロードしておけば、そのままiPodと同期して再生ができますし、iPhone 2.2 Software UpdateをインストールしていればiPhoneやiPod touchから直接Podcastをダウンロードすることもできます。podcastはiPodとBroadcastを組み合わせた造語ですのでiPodで再生するというのは本来の姿ではあるわけですが、iPodで再生しなければPodcastではなというわけでもありません。
　またPodcastが利用できるのはiTunes Storeだけかというとそうではなく、様々なサイトでPodcastが提供されています。そもそもPodcastはWebサーバにコンテンツのデータをアップロードして配信する仕組みになっており、iTunesStoreのPodcastページは世界中に多数存在するPodcastの配信サーバへの入り口として機能しているのです。またiTunesでなければPodcastの番組を再生することができないというものでもありません。

・iTunes上でのPodcast
http://www.htabata.com/img/MXS105/podcast/iTunes_01.png

◇PodcastとRSS
　Webサーバさえあれば音声や動画ファイルをアップロードすることによってPodcastの配信を始めることができます。ただしこれだけではたんなるWebのコンテンツでしかありません。例えばiTunesでPodcastを利用すると、番組ごとにまずコンテンツの一覧を確認できますが、ただファイルをWebサーバにアップしただけではこのように整理された形で情報を取得することはできません。
　つまり標準的な形式で番組に関する情報を別途用意しておく必要があるのですが、これにはRSSを利用しています。RSSとはWebサイトの更新情報をXML形式でまとめたものです。PodcastではRSSを利用して番組の情報を整理した形で公開しているわけです。iTunesのようなPodcastに対応したソフトはRSSで情報を取得することによって番組の一覧を表示しているのです。Webサーバにデータをアップして、さらにRSSで情報をまとめることでPodcastとして成り立つわけです。

・iTunes上でのあるPodcast番組のページ
http://www.htabata.com/img/MXS105/podcast/iTunes_02.png

◇Podcast番組の制作
　このようにPodcastとはWebとRSSを利用した非常にゆるい仕組みで成り立っていますので、Webサーバさえ用意できれば比較的手軽に配信を始めることができます。とはいいましてもコンテンツを用意しなければ始まらないわけでここが最も大変なところなのですが、技術的には音声や動画をMP3やH.264といった一般的なフォーマットでエンコードして配信を行うことになります。フォーマットについてはPodcastだからこれといった厳密な決まりはありませんので、多くの人に楽しんでもらうにはiTunes/iPodに合わせたフォーマットで用意しておくのがよいでしょう。

　というわけで収録、エンコード、公開などの一連の作業によってPodcastの配信ができるようになるのです。個々の作業は個別に手作業で行ってもよいのですが、Leopard Serverに搭載されていますPodcast Producerを利用することによってワークフロー全体を自動化することができます。次回以降はPodcastProducerについて詳しく取り上げて行きます。

　最後に最近出版された書籍を1冊紹介しておきましょう。Mac OS Xのシステムを詳しく解説した「Mac OS Xシステム管理」が発売になりました。サーバの解説ではなくクライアントのMac OS Xについての解説本なのですが、その多くはサーバでも共通していますので、システムの内部についてより詳しく理解を深めたいという方にお勧めです。

「Mac OS Xシステム管理」
http://msyk.net/macos/adm/
次回へつづく　

小池邦人のCarbon視点でiPhone探求（2009/01/23）

〜　Info.plistとInfoPlist.stringsとアイコン　〜

今回は、info.plistファイルについてもう少し詳しく調べてみることにします。また、最初の仕事として、Symmetryアプリケーションのアイコン画像（PNG画像ファイル）を用意し、プロジェクトウィンドウに登録してみます。

プロジェクトフォルダに保存されている「Info.plist」（情報プロパティリスト）というXMLファイルは、iPhoneアプリケーションの環境設定ファイルのようなものです。MacアプリケーションのInfo.plistを操作した経験のある人は、その内容が似通っていますので、あまり戸惑うことはないはずです。ただし、いくつかのキーと値のペアーは、iPhoneアプリケーション固有ですので注
意が必要です。前回作成したSymmetryプロジェクトにデフォルトで保存されているInfo.plistの内容をテキストエディタでオープンしてみると、その辞書部分のキーと値は、以下の内容であることが分かります。

CFBundleDevelopmentRegion
　English
　CFBundleDisplayName
　${PRODUCT_NAME}
　CFBundleExecutable
　${EXECUTABLE_NAME}
　CFBundleIconFile
　
　CFBundleIdentifier
　com.yourcompany.${PRODUCT_NAME:identifier}
　CFBundleInfoDictionaryVersion
　6.0
　CFBundleName
　${PRODUCT_NAME}
　CFBundlePackageType
　APPL
　CFBundleSignature
　????
　CFBundleVersion
　1.0
　LSRequiresIPhoneOS
　
　NSMainNibFile
　MainWindow
　CFBundleIconFile
　Symmetry.png

幾つかのキー値に${PRODUCT_NAME}や${EXECUTABLE_NAME}といった表記があります。この箇所については、ビルド時に、Xcodeのビルドオプションに設定されている内容へと置き換わり保存されます。今回の場合は両方とも「Symmetry」となります。ビルドされた「iPhoneシミュレータで起動するアプリケーション」に含まれるInfo.plistの方を調べてみると、不定であったキー値へ正式な文字列が代入されていることが分かります。以下がその部分です。

　CFBundleDisplayName
　Symmetry
　CFBundleExecutable
　Symmetry
　CFBundleIdentifier
　string>jp.co.ottimo.Symmetry
　CFBundleName
　Symmetry

オリジナルにはない2つのキーと値のペアが追加されています。これはiPhoneシミュレータ用のInfo.plistの場合です。実機へインストールした場合には、その内容が異なると予想されます（確認はしていない）。DTSDKNameキーの方には、対応するiPhone SDKのバージョンが記載されていますので、このキー内容を見ることでApp Storeの条件項目が表示されているのかもしれません。

　DTPlatformName
　iphonesimulator
　DTSDKName
　iphonesimulator2.2

Info.plistで重要なのは、CFBundleDisplayNameキーです。このキー値は、iPhoneのホームページに表示されるアイコンの「名称」を指定しています。この部分を次の様に変更すれば、名称表示は「しんぶんし」となります。名称の文字列が長すぎると、表示の途中に「…」が現れ美しくないので注意してください。アプリケーションの名称は日本語で5文字以内、英語なら12文字以内
に調整した方が良いでしょう。

　CFBundleDisplayName
　しんぶんし

アプリケーション名がワールドワイドで共通であれば問題ありませんが、状況によっては日本語圏と英語圏で別の名称にしたい場合があります。日本語名は「しんぶんし」だが、英語名は「Symmetry」にしたいといった場合です。前回、iPhoneアプリを多言語対応にしたければ、先んじて国別フォルダを用意し、その中に各国語対応リソースファイルを保存すると解説しました。例えば英語用リソースなら「en.lproj」日本語用なら「ja.lproj」フォルダです。このフォルダ名は「ISOの省略形（ISO 639-1が定義するコード）」だそうです。他の国の名称が知りたければ、関連サイトを調査すれば判明するでしょう。

ローカライズしたアプリケーション名は「InfoPlist.strings」ファイルに記述し、指定国フォルダ（ja.lprojなど）に保存した後、プロジェクトウィンドウへと登録します。例えば、Macアプリケーションでは、名称のローカライズにはCFBundleNameキーを利用しました。また、Finderの情報ウィンドウに表示させるバージョン情報などのローカライズには、CFBundleShortVersionStringやCFBundleGetInfoStringキーを利用しました。以下の様な感じです（MacのInfoPlist.stringsの例）。

CFBundleName = "しんぶんし3";
CFBundleShortVersionString = "しんぶんし version 3.0";
CFBundleGetInfoString = "しんぶんし version 3.0 Copyright 2009 by Ottimo, Inc.";

iPhoneの場合は次の様になります…。

CFBundleDisplayName="しんぶんし";

Macでアプリケーションメニュー用に使われていたCFBundleNameキーは、iPhoneでは使われていないようです。ローカライズ設定がうまく機能しているかどうかは、iPhoneの「設定」アプリケーションの「一般」「言語環境」から利用する「言語」を切り替えることで確認できます。色々と試して問題がないかチェックしておきましょう。リソースが用意されていない言語圏を指定した場合、CFBundleDevelopmentRegionキーに設定されている言語がデフォルトとして使われそうですが、残念ながらそうはなりません。デフォルトとしては、強制的に英語圏リソースが使われるようです。

続いてアイコンを登録してみます。最初に57×57ピクセルの正方形のPNG画像ファイルを用意し、ファイル名を「Icon.png」とします（先頭は大文字なので注意！）。またPNG画像ファイルを保存する時は、アルファーレイア（マスク）を持たないように調整してください。もしアルファーレイアがあるとアイコンが表示されません。アイコン画像ファイルは、プロジェクトの「Resources」フォルダへ単独で登録してください。アイコンをローカライズするケースは少ないと思いますが（辞書アプリとかは必要？）、もしそうする場合には、各国語用のアイコン画像を用意し、それぞれをja.lprojやen.lprojフォルダへ保存してからプロジェクトに登録します。また、登録アイコンのファイル名を変更するには、Info.plistのCFBundleIconFileキー値にファイル名を設定します。例えば、それが「Symmetry.png」であれば、以下の様にCFBundleIconFileキーに設定します。

CFBundleIconFile
　Symmetry.png

Info.plistでは、iPhoneのユーザインターフェース関わる設定も保有します。それらについては、必要となった時点で逐次解説したいと思います。また、Info.plistに関する詳細な情報については「iPhone OSプログラミングガイド 」の 97ページ「情報プロパティリスト」を参照してください。

次回は、しんぶんし 3（ Mac用）でImageFileクラスとして定義していたモデル・オブジェクト（メインデータ構造）を、iPhone用アプリケーションのSymmetryへと移植する作業を行いたいと思います。さて、すんなりと移植可能なのでしょうか？

ターミナルの向こうから　　　　　　第40回　　海上 忍

〜 いま敢えて学ぶTerminalのイロハ（7） 〜

・「~/.bashrc」の作りかた
　bashの初期化ファイル「~/.bashrc」は、ファイル名の先頭が「.」で始まる、いわゆるドットファイルです。Mac OS Xのシステムでも不可視属性のファイルとして扱われるため、Finder上に表示されないばかりか、アプリケーションで扱うことも困難です。たとえば、標準装備のエディタ「テキストエディット」では、「~/.bashrc」として保存することは可能（警告されます）です
が、「開く」ダイアログから選択することはできません。
　UNIXに馴染んだユーザの場合、ターミナル上から「vi」や「emacs」などのコマンド／テキストエディタを使用しますが、Mac OS Xの一般的なアプリケーションとは操作性が大きく異なるため、抵抗を感じる向きもあるかもしれません。そこで、多少の手間は必要となりますが、ここでは敢えてテキストエディットを使う方法を紹介します。

・テキストエディットで新規作成する
　「~/.bashrc」をはじめて作成する場合は、通常どおりテキストエディットを起動し、フォーマットに「標準テキスト」を選択したうえで、入力作業を行います。
　保存するときには、名前欄に「.bashrc」と入力して場所欄にホームフォルダを選択し、標準テキストのエンコーディングに「日本語（Mac OS）」を指定してください（候補に表示されていない場合は、エンコーディングリストをカスタマイズします）。そして「拡張子が指定されていない場合は、”.txt”を使用」のチェックを外したうえで、保存ボタンをクリックしてください。すると、「”.”（ドット）で始まる名前はシステム用に予約されています」と警告を受けますが、かまわず「”.”を使用」ボタンをクリックしてください。これで、ホームフォルダ上の「.bashrc」、すなわち「~/.bashrc」の完成です。

・テキストエディットで内容を変更する
　テキストエディットの「開く」ダイアログには、ドットファイルが表示されません。そのためホームフォルダを選択しても、候補に「.bashrc」が現れることはありません。TinkerTool（http://www.bresink.de/osx/TinkerTool.html）などのユーティリティを利用すれば可能ですが、「~/.bashrc」ひとつのためにそのような設定を行う必要はないでしょう。
　そこで使うテクニックが、「openコマンド経由で開く」ことです。openコマンドは、オプション「-e」を使うと、引数に与えたファイルをテキストエディットで開くよう動作するため、問題なくドットファイルを開くことができます。

- - - - -
$ open -e ~/.bashrc
- - - - -

・~/.bashrcに何を書くか
　これで「~/.bashrc」を作成／編集するための準備は整いましたが、肝心なのは内容です。シェルの環境設定は奥が深く、徹底的に解説しようとすると本を1冊書けるほどですから、ここでは必要最低限の事柄について取りあげます。
　1行目は、使用するロケール（言語情報）を設定します。Mac OS Xでは、ファイル名のエンコード方式にUTF-8を使う都合上、UTF-8で統一されることが望ましいため、LANG環境変数に「ja_JP.UTF-8」を設定しておきます。
　2行目は、ページャ（テキストファイルやオンラインマニュアルの閲覧に使用されるテキストビューア）の「less」で使うエンコーディング形式を設定しています。Leopardに収録されているlessコマンドには、エンコーディング形式の自動判別機能が搭載されていませんが、このように設定しておけばUTF-8のテキストファイルをTerminal上で閲覧できます。
　3行目は、コマンド入力待ちのとき表示される「プロンプト」を定義するためのbashのシェル変数です。ここで紹介している内容は、まるで呪文のようですが、「09:39 AM shinobu@MBPro ~/Desktop」のように、現在時刻／ユーザ名@コンピュータ名／カレントディレクトリのパスを表示したうえで、改行して「$」を表示する働きがあります。筆者が長年愛用している設定ですから、どうか安心してお使いください。
　4行目では、コマンドの別名「エイリアス」を定義しています。このように設定しておけば、bashで「ls」を実行したとき、「ls -GF」に置き換えて実行されます。ディレクトリやファイルが色分けされて表示されるので、なかなか便利です。

- - - - -
1: export LANG=ja_JP.UTF-8
2: export LESSCHARSET=utf-8
3: export PS1=' [ e[34m ] @  [ e[33m ] u@ h  [ e[32m ] w e[0m n $ '
4: alias ls="ls -GF"
- - - - -

DEMOsa KITAレポート　　　　　　　　　　　　曽我 聰起

DEMOsa KITAに参加して

1月24日、札幌市の「かでる2・7」で開催された「DEMOsa KITA」に参加してきました。当日は晴天にも恵まれ、多数の来場がありました。今回の「DEMOsa KITA」では、プログラム開発などに限定されない、幅広い分野での発表が多数ありました。実際に参加してみると、期待を裏切らない充実したプレゼンテーションの数々に圧倒された、そんなイベントでした。

私自身も、拙いながらプレゼンテーションさせた頂いた一人です。通常、私が参加する学会発表などでは、だいたい15分から20分程度の発表と5分ぐらいの質疑応答が一般的な形式だと思いますが、「DEMOsa KITA」は僅か10分間という限られた時間でのプレゼンテーションです。しかし、発表する側はともかく、この短い時間が聴取にはほどよいテンポとリズムだったように思います。
また、今回は発表者に断った上でYouTubeでのストリーミング映像も収録されました。未だに学会ではこうした取り組みが少ないのですが、参加できなかった方には参考になるのではないでしょうか。

さて、内容の詳細はWebやYouTubeでの映像をご覧頂くとして、ここでは私の感想を述べさせていただきます。プレゼンテーションでは、開発関係の皆さんから新製品情報や開発秘話を聞くことができました。かつてMacWorld Expoなどのイベントでは、開発者の方に直接話を伺う事が楽
しみの一つでもあったのですが、最近ではイベントの数が少なくなってしまっただけに、DEMOsaのような場は貴重な存在です。今回は、iPhoneアプリに関する話題も多く、そちらを目指されている企業や学生さんには役立つ情報が多数あったのではないでしょうか。また、様々な現場におけるコンピュータや機材、プログラムを利用した活動や事例報告も多数あり、感心する事が多数ありました。実際、自分が発表する際に、前に立つと今回の参加者の皆さんが実に真剣な表情をなさっていることに驚きました。メモを取られている方も多く、この点は日頃の学会とは異なる雰囲気を感じました。

個人的に感心したのが、学生さんたちによる社会活動のプレゼンテーションです。こういう学生さんたちの姿を見ると“中高年はしっかりしなければ”と反省しました。
今回の司会はMacの雑誌などでもおなじみの大谷和利さんでした。ご自身も最後にプレゼンテーションをなさるというハードな状況の中で、この幅広いジャンルの発表に一つずつ丁寧にインタビュー、コメントされて頂いたのですが、大谷さんならではと感心いたしました。懇親会では、10分間で話しきれなかった話題について参加者と発表者が和気あいあいと話し合う姿が多数見られました。こうした会話の中から新しいアイデアが生まれる事があると思います。私も懇親会での会話から、現在のシステム運用に置ける改善方法を思いつきました。人が集まる空間が生み出すエネルギーのなせる技なのかも知れません。

早速、本日の地元新聞の夕刊には「DEMOsa KITA」で発表された学生さんの活動が取り上げられていました。私にとって、コアな人たちと過ごすことができる貴重な経験でした。
運営にあたられたMOSAの方がたには、大変お世話になりました。改めてこの場をお借りしてお礼申し上げます。また、次の機会にお目にかかれる事を楽しみにしております。

◆執筆者プロフィール：
北海道文教大学　外国語学部　教授
コンピュータシステムの会社を退職後、北海道旭川の情報系専門学校教員として教職畑に入植。その後、札幌の北海道文教短期大学を経て現在に至る。激動の90年代マルチメディアの洗礼を受ける。特にHyperCardの強烈なパンチを浴び、目が覚める。Mac歴20年。一般情報処理教育を担当しつつ「楽しい情報教育」の実現に向け、CIEC（コンピュータ利用教育協議会）北海道支部にて世話人を務める。

◇MOSAからのお知らせと編集後記は割愛します◇

目次

• りんご味Ruby　　　　　　　　　第39回　　藤本 尚邦
• 藤本裕之のプログラミング夜話　　　#152
• 高橋真人の「プログラミング指南」　　第150回

りんご味Ruby　　　第39回　　藤本 尚邦

真偽値アクセッサを宣言するための疑似構文 attr_predicate のオープンクラスによる実装:

--------------------------------------- attr_predicate.rb ---
Module.class_eval do
 def attr_predicate(*names)
   names.each do |name|
     define_method("#{name}?") do
       instance_variable_get("@#{name}") ? true : false
     end
   end
 end
 private :attr_predicate
end
----

のうち、前回は、クラスやモジュールの定義を追加・変更するためのメソッドであるModule#class_eval (別名module_eval) と、メソッドをプライベート宣言するためのメソッド Module#private について説明しました。今回は、attr_predicate の定義の中身を見ていきます。

■ 可変長引数

Rubyでは、def構文によるメソッド定義の仮引数に、可変長引数を含めることができます。attr_predicate の定義:

 def attr_predicate(*names)
   names.each { |name| name のアクセッサを定義する }
 end

この仮引数 names のように、仮引数の名前の前に `*’ を付けると、その引数は可変長引数(呼び出された時に初めて引数の数が決まる引数)を意味するようになります。メソッドが呼び出され実行されるとき、可変長引数には、複数の実引数の値が入った配列オブジェクトが渡されます。

可変長引数は、メソッド定義の仮引数リストの中で、通常の仮引数の並びの最後に1つだけ含めることができます。例えば:

 def foo(a0, a1, *rest)
   p a0, a1, rest
 end

の場合、fooは2つ以上の引数をとり、3つめ以降の値は、rest に配列として入れられます:

　$ irb --simple-prompt
　>> def foo(a0, a1, *rest) p a0, a1, rest end
　=> nil
　>> foo(11, 22, 33, 44)
　11
　22
　[33, 44]
　=> nil

attr_predicate を使って:

 attr_predicate :done, :important

と真偽値アクセッサを宣言した場合には、attr_predicate が呼び出されたときに実引数の names には

 [ :done, :important ]

つまり宣言されたアクセッサ名2つを要素に持つ配列がセットされて、それぞれのアクセッサ名について、アクセッサメソッドを定義することになります。

■ define_method によるメソッドの動的な定義

 define_method("#{name}?") { `name?'アクセッサの実装 }

Module#define_method は、そのクラス(モジュール)のインスタンスメソッドを定義するためのメソッドです。通常、メソッドの定義に用いられる def 構文(疑似ではなく本物の構文です)との違いは、メソッドの名前や実装の手続きそのものを決めなければいけないのはいつか？というところにあります。

・def構文では       → プログラムコードを書いたときに決まる
・define_methodでは → 実行中、define_methodが呼ばれたときに決まる

もし、真偽値アクセッサの定義をすべてをプログラムコードに直接記述するのであれば、以下のようにどちらを使っても大差ありません。

# def構文を使って定義
 def done?
   @done ? true : false
 end

 # define_methodを使って定義
 define_method "done?" do
   @done ? true : false
 end

ですが、attr_predicate の実装では、define_method が呼び出されたときに、変数 name の値を文字列化してその末尾に `?’ を付けた文字列を生成して、それをアクセッサメソッド名として渡しているわけです。

def構文では、メソッド名を文字列で指定するようなことはできないので:

 names.each do |name|   # アクセッサ名が初めてわかる
   def "#{name}?"       # `?'付きアクセッサ名を生成 → 構文エラー
     ...
   end
 end

と書くことはできないのですが、define_methodを使うと:

 names.each do |name|                   # アクセッサ名が初めてわかる
   define_method "#{name}?" do          # `?'付きアクセッサ名を生成
     instance_variable_get("@#{name}") ? true : false
   end
 end

のように書くことが可能なわけです。

■ インスタンス変数の値の読み書き

インスタンス変数の値の読み書きをするためのメソッドとして以下の2つがあります:

 instance_variable_get(インスタンス変数名)           # => 現在の値
 instance_variable_set(インスタンス変数名、新しい値) #    値を変更する

アクセッサメソッドの実装手続き本体は:

@done ? true : false     # インスタンス変数の真偽により
                          # trueかfalseを返す

というようなコードになるでしょう。ところが、attr_predicate 自体の実装を書いているとき、肝心なインスタンス変数の名前はわかりません。メソッド名の場合と同様、それがわかるのは attr_predicate によってアクセッサが宣言されたとき、つまり attr_predicate が呼ばれたときです。なので:

 instance_variable_get("@#{name}") ? true : false

のように instance_variable_get を使い、変数nameの値を元にして、インスタンス変数の値を取得しているのです。

藤本裕之のプログラミング夜話　#152

　かなり遅くなってしまったが明けましておめでとうござる。年末から年明けにかけて、派遣切りだの年越し派遣村だの、明日は我が身というか一寸先は闇というか、身につまされる話題てんこ盛りでおめでとうもないもんだが。え、オレたちはホームレスでもなければそうなる可能性があるハケンですらない。2009年、行く手には明るい未来が待っているのだお前と一緒にするなって？

　いや一応オレとてホームレスでもなければただいま現在ハケン社員でもないんだが、昨今話題の派遣労働という問題、われわれプログラマという職業の者が来し方行く末を考える上で避けて通れぬハナシなのである。

　突然メタな話をはじめるが、昨年1年、この場で埒もないことを書かせていただくうち、タカハシ編集長が何をオレに書かせたいかとは別に、オレがここで何を書くべきかというのがだんだん明確になってきたのである。

　前にも一度書いたと思うが、当初タカハシ編集長がオレに提示したテーマは「アプリケーション・プログラマは絶滅危惧種なのか？」というもんだった。これに応えるつもりでオレは、オレの頭のなかにいる「アプリケーション・プログラマ」という存在が現在のコンピュータシーンで生きていけるのかという問いに対し、手がかりになりそうなコトガラを思いつくままに調べ、考え、こ
こに開陳してきた。

　そうして1年が経ち、ようやく気がついたのは、これが「アプリケーション・プログラマ」という、その他の「プログラマ」との境界線がとっても曖昧な存在に固有の問題ではなく、より一般的な「プログラマ」という存在全般に関わる問題であり、またその視点で考察しないと本質が見えてこないというコトであった。

　で、その「気づき」の契機がいわゆる「派遣切り」問題だったのね。

　一連の報道の中で耳にした（あるいは読んだ）方もおられると思うが、そもそも今回の問題は、1986年に施行された「労働者派遣法」という法律がそのハジメである。

　この法律成立以前は、江戸時代から続く「口入れ屋」（ジョージ秋山の「浮浪雲」である）的システムが産む劣悪な労働環境、暴力的な労務管理、過剰な中間搾取を防ぐため、職業安定法という法律によって派遣労働、雇用者側からいうと間接雇用になるんだが、というものは全面的に禁止されていた。

　ここで「え？」と思った人もいるのではないか？　オレがガッコを出て最初の会社に就職したのは1983年だが、その会社は明らかに今でいう「派遣」をやっていた。ただその呼び名が「出向」だっただけ、顧客企業に「出勤」し、そこでタイムカードを押してそこの上司（このヒトも別の会社からの「出向」だったりしたんだが）から指示を受けてた。

　早い話、禁止されている間接雇用を、名目だけ「業務処理請負」ということにして行っていたわけである。いや、オレもこれでした、1984年から85年までね。別に咎められないんだからそのままにしといてもよかったんぢゃないかと思うが、1986年にこの「黙認されている違法行為」を合法化するために作られたのが先の「労働者派遣法」だったのだ。

　日本が前年に「女性差別撤廃条約」てのを批准し、「男女雇用機会均等法」というのを施行したせいで、秘書とか受付嬢とかを「女性に限って」募集できなくなったためという話もあるが（ほら、ハケンなら派遣会社に「女性が欲しいんです」っていうのは違法ぢゃないわけ）、ホントかどうかはわからない。

　とにかくこの1986年の「労働者派遣法」により天下晴れて「派遣が可能」になった業種の一つが（当初は全部で13の職種しか認められていなかった）、われわれ「コンピュータ関係職」であり、それには「専門性が強くかつ一時的に人材が必要となる職種であるから」という理由付けがされていた。

　いっすか、もう一度書くよ。「専門性が強くかつ一時的に人材が必要となる職種であるから」われわれコンピュータ技術者は「派遣になれる」コトになったのである。この、まるで「派遣になれる」のが立派なコトみたいだったという事実をよーく噛みしめつつ次回を待て。
（以下次回　2009_01_16）　

高橋真人の「プログラミング指南」第150回

これから始めようとする人へ(1)

　皆さんこんにちは、高橋真人です。
　さて、昨年からこの連載では、「新年の最初は新年にふさわしく」ということで、この連載の初心に立ち戻ってプログラミングの初心者・入門者の方々に向けた“道案内”の記事をお送りすることにしています。
　今年は、新年に当たって新たにMacのプログラミングに挑戦してみようと考える皆さんにお送りする「Macプログラミングの道案内」です。

　昨年は、日本でのiPhoneの登場と、ネイティブアプリ開発のためのSDKが登場したという私たちにとって大きな出来事があったため、MOSAにおいてもたくさんの“初めて”のあった年でした。そんな中、私が以前から関心を向けてきたプログラミングの入門者／初心者の層においてもiPhoneの影響は表れていたようです。
　私の参加したMOSAのイベント等で、「これからiPhoneの開発をやってみようと思う」とか「最近Mac上での開発を始めた」とおっしゃる方に数多く出会い、お話しする機会を得ましたが、そんな方々は大体以下の二つに分類できたのです。

・他の環境で既にプロとしてやってきている方
・今まではプログラミングに興味を抱いたことがなかった方

　これらのパターンの方が以前はいらっしゃらなかったというわけでは決してないのですが、昨年は特にこれらの方々が多く目立ったのです。これは、今までは余り見られなかった傾向です。
　さて、この二つのパターンのうちの前者ですが、“他の環境でプロとして”という方々は、さらにゲーム系とWeb系とに分けることができました。
　ゲームプログラマーの方は、開発環境としては主にWindowsということでしたが、そもそもゲームの場合、対象となるマシンの能力を極限まで引き出すような開発を要求されることも少なくないので、たとえ「Macはよく分からない」と言われていたとしても、それはあくまで「使い方が分からない」という程度の話であり、おおよそ初心者／入門者の分類に入れられるものではありま
せん。
　それに対してもう一方のWeb系プログラマーの場合は、少し事情が異なります。数多く手がけている案件のうちの一つがWebの仕事であるとか、過去に様々な開発を経験してきて、今はたまたま流れでWebの仕事をしているという方を除くと、Web開発者と言われる方の多くが、スクリプト言語のみの経験しかないようなのです。

　スクリプト言語というと、MacではAppleScriptを最初に思い浮かべる方もいらっしゃるでしょうが、Web系において真っ先に出てくるのはPHPでしょう。後は、今やAJAXになくてはならないJavaScriptと、Ruby on RailsでおなじみのRubyといったところが、現在のWeb系開発に用いられるスクリプト言語だと思われます。
　インターネットが一般化する以前には、スクリプトというのはマクロの一種といった位置付けで、UNIX界隈でこそPerlの登場により、スクリプトの可能性が飛躍的に高まったとはいえ、基本的には補助的な役割を担っていたと思います。
　WebにおいてCGIという仕組みが登場してからは数多くのCGIがPerlで書かれましたが、「Perlはインターネットの世界でのグルー言語」と言われていたように、あくまでそれは“糊付け”をするための補助的な役割だったのです。
　しかし、Webにおける動的な処理への要求が高まってくるにつれ、CGIでは賄い切れない高度で複雑な処理に対するニーズから、Webアプリケーションと呼ばれるカテゴリーが現れました。これの元祖がWebObjectsであることは皆さんご存じの通りです。
　このWebアプリケーションという仕組みは、Javaという、登場時にマルチプラットフォームを標榜していたものの、当時は中途半端な立場に甘んじていた言語／技術にとって非常に適した分野だったようで、Webアプリケーションと呼ばれるもののほとんどがJavaで書かれるようになりました。WebObjectsもバージョン5.0からJavaで全面的に書き換えたほどです。（スタート時は
Objective-Cでした）

　しかし、Webがこの世に登場したころの設計意図を大きく踏み越えて巨大化、多様化、高機能化していくにつれ、Javaも巨大化、複雑化することを余儀なくされました。それは大掛かりなWebシステムを構築するためには避けられない進化の道だったのかもしれませんが、同時に、Javaという技術への新規参入者にとっての敷居を高くして行ったことも事実です。それは、登場時に「複
雑化したC++からの複雑な部分を取り除いてシンプルにした」と言っていたJavaにとっては皮肉なことのように感じます。
　そうした中、「すべてのWebシステムが巨大化・複雑化したわけでもないのだから、Javaを使わなくてもWebアプリケーションは作れるだろう」と登場したのがRuby on Rails（以下RoR）に代表されるスクリプト系のWebアプリケーションです。RoRの成功により、Javaとは別の路線でずっと使われ続けてきたPHPなども含めて、スクリプト系のWeb開発というのが、世の中の一画を築くようになってきたのだと思います。

　ところでスクリプト言語は、ネイティブ系の言語に比べると処理速度においてどうしてもハンディがあります。しかし、実行時に動的に命令を与えられるとか、豊富かつ使いやすい機能が最初から備わっているなどの利点もあって、習得も比較的容易なことから、一般にネイティブ系の言語に比べて敷居が低いと言われています。特に、メモリの管理に関しては実行環境が面倒を見てくれ
ることもあって、その意味でも“気軽に”取り組める開発環境と言えます。
　ですから、速度の面でハンディを背負っていたとしても、それに引き換えて余りあると判断した人たちからは選択肢として充分に意識される位置付けにあるというのが、今のスクリプト系の開発環境です。
　しかしながら、ことiPhoneを対象に考えた場合、マシンの能力が非力である以前に、現在のiPhoneでは一切の処理系が動作しませんから、JavaScriptで書いたコードをWeb経由で動かすというのでもない限り、今のiPhoneでスクリプト言語の出る余地はありません。
　さて、このような状況において、スクリプト系の開発者がiPhoneの開発に取り組むにはどのようなアプローチがよいのでしょうか？　また、今まで全くプログラミング的なものにかかわってこなかった人にとって、新たにMacやiPhoneの開発を学ぼうとする場合、どのような手順で進んで行くのがよいのでしょうか？

　次回は、その辺をさらに解説していきたいと思います。

◇MOSAからのお知らせと編集後記は割愛します◇

目次

• 「Wonderful Server Life」　　　　第84回　　　田畑 英和
• 小池邦人のCarbon視点でiPhone探求
• ターミナルの向こうから　　　　　　第39回　　海上 忍　

「Wonderful Server Life」　　第84回　　田畑 英和

〜「新春」編〜

　皆様明けましておめでとうございます。アップルが参加する最後のMacWorldではサーバ関連の発表はなにもありませんでしたが、17インチMacBook ProやiLife ’09、iWork ’09などの発表がありました。
　さて、今回は今年初めての連載になるわけですが、いつもとは少しおもむきを変えてみたいと思います。新しい年を迎えると1年の目標をたてたりするわけですが、サーバ管理もぜひなにか目標をたててスキルアップをしたいものです。そこで資格取得を目指してみてはいかがでしょうかというのが今回のテーマです。

◇Apple技術者認定資格
　ご存じない方も多いかと思いますが、技術者を認定するAppleの資格制度があります。認定資格にはPro App系のものもありますが今回ご紹介するのはいわゆるIT系の認定資格になります。IT系の認定資格は次の3つがあります。

・Apple Certified Support Professional 10.5(ACSP)
・Apple Certified Technical Coordinator 10.5(ACTC)
・Apple Certified System Administrator 10.5(ACSA)

　資格の名称にはそれぞれバージョン番号が付いていますが、OSのバージョンアップとともに資格もバージョンアップしています。まず最初のACSPですが、こちらはMac OS Xのユーザをサポートするヘルプデスク担当者向けの資格です。ACTCはサーバ管理者向け、ACSAはより上級のサーバ管理者向けの資格になっています。
　資格を取得することのメリットなのですが、資格を取得したことで自分のスキルを客観的にアピールできるといったことももちろんあります。ですがそれ以上に、資格取得のために学習したことで自分自身のスキルを向上できることが一番のメリットであると思います。

◇認定試験
　では資格を取得するにはどうすればよいかですが、認定試験に合格することにより資格を取得できる仕組みになっています。IT系の認定試験は全部で5種類あり、資格と試験の対応は次のようになっています。
　
・ACSP 10.5取得に必要な認定試験
   Mac OS X Support Essentials v10.5(90問、73%)
・ACTC 10.5取得に必要な認定試験
   Mac OS X Support Essentials v10.5(90問、73%)
   Mac OS X Server Essentials v10.5(90問、69%)
・ACST10.5取得に必要な認定試験
   Mac OS X Server Essentials v10.5(90問、69%)
   Mac OS X Directory Services v10.5(74問、68%)
   Mac OS X Deloyment v10.5(64問、70%)
   Mac OS X Advanced System Admin v10.5(90問、70%)
※括弧内は出題数と合格ライン

　つまり資格によっては複数の試験に合格する必要があるということです。それぞれの試験の内容は次のようになっています。

・Mac OS X Support Essentials v10.5
　　Mac OS Xのシステム管理、インストールからトラブルシューティング
　　までを幅広くカバー
・Mac OS X Server Essentials v10.5
　　Mac OS X Serverのシステム管理、インストールや主要サービスの管理
　　方法について
・Mac OS X Directory Services v10.5
　　Macのディレクトリサービスについて、Active Directoryなど他の
　　プラットフォームとの連携についても含まれる
・Mac OS X Deloyment v10.5
　　Macを効果的に導入するための管理手法について
・Mac OS X Advanced System Admin v10.5
　　システム管理に関する様々なトピックについて

　これらの試験をどこで受験できるかですが、全国的に受験可能な会場としては、様々な資格試験を提供しているプロメトリックで受験することができます。ただし1つ大きな問題がありまして、Tiger(10.4)の認定試験は日本語でも受験できたのですが、残念ながら現時点ではまだプロメトリックではLeopard(10.5)の認定試験は英語でしか受験できず、Support EssentialsとServer Essentialsの2種類の試験しか受験することができません。また受験料金もTigerのころと比べると値上がりしており1回の受験料が23,100円（税込み）となっています。

・プロメトリックでのApple関連の試験一覧
https://www1.prometric-jp.com/exam_list/exam_list.asp?client_top_no=AE&client_no=AE

　こういった状況ですので、受験するにはまず英語というハードルがあるわけですが、認定資格や試験に関する情報もまたAppleの英語ページでないと確認できません。

・Training and Certification（英語）
http://training.apple.com/certification/macosx

　すべて英語の情報ということになってしまうのですが、出題の傾向を解説したドキュメントやサンプルテストを入手することができます。また各認定試験に対応した解説書（またまた英語です）がPeachpitという出版社から出版されています。PDFで販売されている書籍もあり、この出版社は他にもMac関連の書籍を多数出版しています。
・Apple Training Series: Mac OS X Support Essentials, 2nd Edition
   http://www.peachpit.com/store/product.aspx?isbn=0321489810
・Apple Training Series: Mac OS X Server Essentials, 2nd Edition
   http://www.peachpit.com/store/product.aspx?isbn=0321496604
・Apple Training Series: Mac OS X Directory Services v10.5
   http://www.peachpit.com/store/product.aspx?isbn=0321509730
・Apple Training Series: Mac OS X Advanced System Administration v10.5
   http://www.peachpit.com/store/product.aspx?isbn=032156314X
・Apple Training Series: Mac OS X Deployment v10.5
   http://www.peachpit.com/store/product.aspx?isbn=032150268X

　書籍はPeachpitのサイトで注文することもできますし、一部は日本のAmazonでも取り扱っています。これらの書籍にはシステム管理を行うにあたって非常に役に立つ情報が満載ですので、認定資格や試験には興味はないけれどもという方でも手元に揃えておくと有益なリソースとなることでしょう。
　というわけで試験も情報も書籍も英語だということになってしまうのですが、なにせアメリカ生まれのMacのわけですし、英語が苦手だという方でもこれを機会にチャレンジしてもるよもよいと思います。そうすれば今年の目標に英語力Upまでもれなくついてくるというわけです。もちろん英語が得意な方はぜひこれらのリソースを有効活用してください。

◇それでもやっぱり日本語
　なかなか英語まではという方もご安心ください。ようやく日本語でも認定試験を受験できる環境が整ってきました。アップル公認トレーニングセンターでもあるマイクロメイツでSupport EssentialsとServer Essentialsが日本語でも受験できます。また英語でもかまわなければすべてのLeopardの認定試験を受験することもできます。会場は東京になるのですが日本語で受験できるというのはメリットが大きいかと思います。
　またマイクロメイツではSupport EssentialsとServer Essentialsに対応したオリジナルのトレーニングコースも開催しています。

・マイクロメイツ
http://www.micromates.co.jp/05/4_school_tokyo/46_apple/463_test.html

　というわけで今回は認定資格についてご紹介しました。次回からはLeopardServerの新サービスPodcast Producerについて解説していく予定です。
次回へつづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

小池邦人のCarbon視点でiPhone探求（2009/01/09）

〜　Xcodeのプロジェクトを準備する　〜

前回の宿題「iPhone用しんぶんしの開発には、どのテンプレートを使うか？」ですが、とりあえず「Navigation-Based Application」が向いているだろうと結論付けました。途中で何か問題が発生したら、その時点で対策を講じる事にして開発をスタートしたいと思います。

さっそくXcode（最新バージョンは3.1.2）を起動し、ファイルメニューから「新規プロジェクト…」を選びます。表示されたテンプレート選択ダイアログの左側からは「iPhone OS」直下の「Application」を、右側からは「Navigation-Based Application」を選び「選択…」ボタンをクリックします。続いてプロジェクト名を入力するのですが、「しんぶんし」ではワールドワイドをターゲットとするiPhoneアプリケーションには似つかわしくないので（笑）今回からは「Symmetry」という新名称（少々イージーですが…）に変更したいと思います。この時に入力したプロジェクト名が、とりあえずのアプリケーション名（後で変更可能）となります。

この一連の作業により指定場所に「Symmetry」フォルダが作成され、その中に開発に最低限必要なソースコードファイルやnibファイルなどが保存されます。クラス定義のヘッダファイル（.h）やObjective-Cのソースコードファイル（.m）は「Classes」フォルダに保存されています。MainWindow.xibと RootViewController.xibはユーザインターフェース・オブジェクトが定義されているnibファイルです。こちらをダブルクリックするとInterface Builderを起動することができます。そうした中のひとつ、薄い青色アイコンの「Symmetry.xcodeproj」というファイルがXcodeのドキュメントです。次回からは、このファイルをダブルクリックすることでXodeが起動し、開発関連のファイル一覧を表示したプロジェクトウィンドウをオープンできます。

プロジェクトウィンドウには、フォルダ内に保存されている各種ファイルや開発で使うFrameworkなどが「Classes」「Others Sources」「Resources」「Frameworks」「Products」といったグループ（フォルダのアイコン）別に登されています。こうしたグループは、Xcodeのプロジェクトメニューの「新規グループ」で新しく追加することもできます。一覧リストに表示されているファイル名をダブルクリックすると、目的に応じてその内容がオープンする仕組みとなっています。ソースコードならテキストエディターが、nib（.xib）ファイルならInterface Builderが、Info.plistファイル（XML）ならProperty List Editorが起動します。

このプロジェクトウィンドウの形状ですが、Xcodeメニューの「環境設定…」の「全般」で切り替える事ができます。3種類のレイアウト「デフォルト」「コンデンス」「オールインワン」からひとつを選択できますが、私は昔からの習性（笑）で「コンデンス」を使っていますので、この連載も「コンデンス」レイアウトを対象とした解説となります。ご了承ください。環境設定でのレイアウト切り替えは、ひとつでもプロジェクトファイルがオープンされていると実行できませんので（ハイライト表示のまま）御注意ください。レイアウトを変更し「摘要」ボタンをクリックすれば、次回からオープンされるXcodeプロジェクトの内容は、そのレイアウトのプロジェクトウィンドウに表示されます。

プロジェクトフォルダ内に保存されている開発関連ファイルは、一般的なMac用のCocoaアプリケーションのテンプレートとよく似ています。 main.mやSymmetry_Prefix.pchファイルの役割もMac用とまったく同じです。両者の違いとしては、Mac用テンプレートの方は、リソース関連ファイルが「English.lproj」フォルダにまとめられていますが、iPhoneアプリ用のテンプレートでは、そうしたファイルがフォルダにまとめられていないことでしょう。その代わりに、クラス定義用ヘッダファイルやObjective-Cソースコードファイルの方は「Classes」フォルダにまとめられています。

Mac用テンプレートの「English.lproj」フォルダは、アプリケーションのローカライズを考慮した時に英語用リソース（nibファイルや文字列ファイル）を保存しておく場所となりました。これと同じiPhoneアプリケーションの英語用リソースフォルダは「en.lproj」となります。ちなみに、日本語用フォルダ名は「ja.lproj」です。もし多言語に対応したiPhoneアプを作成する場合には、
先んじてこうした国別フォルダを用意し、その中に各国語対応のリソースファイルを保存しておく必要があります。今回、そうした作業は開発終了時（最後）に実行することにしますので、とりあえずは「ja.lproj」フォルダだけを用意し、そこに関連リソース（日本語用）を保存することにします。

Finderで「Symmetry」プロジェクトフォルダ内に「ja.lproj」フォルダを作成し、そこへnibファイルのMainWindow.xibとRootViewController.xibを移動します。この状態で、Xcodeのプロジェクトウィンドウのファイルリストを調べてみると、両方の名称が赤色に変化していることが分かります。これは、ファイルの保存場所を変更したためプロジェクトに登録されているファイルのリンク情報（ファイルパス）が切れ、Xcodeがそれらのファイルを発見できなくなったことを示しています。まずは両方のファイル名を選択して、Deleteキー（編集メニューの削除）を押してプロジェクトウィンドウのリストから外します。

続いてドラッグ＆ドロップで「ja.lproj」フォルダ内の両ファイルを、プロジェクトウィンドウの「Resources」グループ内に登録します。この操作により、MainWindow.xibRootViewController.xibの左側に小さな「三角形マーク」が表示されるようになります。クリックしてみると、ひとつ深いレベルに「ja」という名称が表示されます。この「ja」をダブルクリックすることで、Interface Builderを起動させ、対応するnibファイルを編集することが可能になります。英語用のnibファイルを作成してプロジェクトへ登録した場合には、このレベルに「en」という名称が表示されます。英語用のnibファイルをInterface Builderで編集する場合には、こちらをダブルクリックすることになります。

ところで、プロジェクトフォルダには「Info.plist」というXMLファイルも保存されていますが、これはiPhoneアプリ自身の環境設定（プロパティ）ファイルのようなものです（Macアプリの場合とまったく同じ）。この中には、バージョン番号やディフォルトで利用する言語、iPhoneに表示されるアプリケーション名、最初に読み込まれるnibファイル名などが定義されています。例え
ば、Info.plistに以下様なタグを追加すると、iPhoneのホームに表示されるアイコンの表示形態が切り替わることになります。

UIPrerenderedIcon
　

この設定は、iPhoneアプリのアイコン表示に光沢やベベルエフェクトを付けるかどうかをブール値で指示しています。デフォルトのプロパティはfalseです。こうしたエフェクトをアイコン表示に追加しない場合は、値をtrueに設定します。例えば、iPhoneアプリの「計算機」や「メモ」は、上記と同じ指定がされています。Info.plistファイルはローカライズのために複数作成する必要はありません。

さて次回は、このinfo.plistをもう少し詳しく調べてみることにします。また最初の仕事として「Symmetry」アプリのアイコン画像（PNG画像ファイル）を作成し、プロジェクトウィンドウに登録してみます。

ターミナルの向こうから　　　　　　第39回　　海上 忍

〜 いま敢えて学ぶTerminalのイロハ（6） 〜

・初期化ファイルとは
　CocoaやCarbonを利用する一般的なアプリケーションは、各種設定を行うための画面（環境設定パネル）を備えています。多くの場合、設定情報はユーザごとに用意されているPreferencesフォルダ（~/Library/Preferences）以下に保存され、起動時に読み取り／終了時に上書きされますが、ユーザはその存在を意識する必要がありません。
　シェルの場合、CUIということもあり設定パネルという概念は存在しません。その代わり、「初期化ファイル」などと呼ばれるプレインテキストファイルを用意し、そこへ設定情報を記述しておくと、シェルの起動時に読み込まれます。性格も機能も異なりますが、ある程度コンピュータ歴が長い方ならば、MS-DOSの「CONFIG.SYS」のようなもの、といえばピンとくるかもしれません。
　初期化ファイルは、おもにエイリアス（コマンドの別名）や環境変数を設定する目的で利用されます。たとえば、第38回で「パス」の設定方法を紹介したとき、PATH環境変数の定義（例：export PATH=$PATH:/sw/bin）を行いましたが、そのコマンドラインをシェル（bash）の初期化ファイルに記述しておけば、シェル／Terminalの起動にあわせて環境変数を自動設定できることになります。

・初期化ファイルの種類
　シェルの初期化ファイルは、1つとはかぎりません。ホスト全体に適用されるもの、ユーザ別に用意されるもの、シェルの起動方法により使い分けられるもの、互換性維持を目的に使用されるものといった具合に、複数の初期化ファイルが存在します。以下、bashで使用される初期化ファイルについて説明します（「~/」はユーザのホームディレクトリを意味します）。

1) /etc/profile
　ログイン時（Terminalの起動時）に1度だけ読み込まれる、システムワイドな初期化ファイルです。Mac OS X Leopardの場合、/usr/libexec/path_helperコマンドで「パス」を設定したあと、他の初期化ファイル（/etc/bashrc）を読み込むよう記述されています。なお、全ユーザに適用される初期化ファイルであり、/etcディレクトリ上のファイルを編集する場合には管理者権限が必要になるため、シェル環境のカスタマイズには使用されません。

2) ~/.bash_profile
　ユーザ別の初期化ファイルで、bashがログインシェルとして起動されたとき1回だけ読み込まれます。先頭が「.」で始まるファイル（ドットファイル）のため、Finder上には表示されません。

3) ~/.bash_login
　ユーザ別の初期化ファイルで、~/.bash_profileが存在しないときに読み込まれます。

4) ~/.profile
　ユーザ別の初期化ファイルで、~/.bash_profileと~/.bash_loginが存在しないときに読み込まれます。

5) /etc/bashrc
　シェルがプロセスとして起動された場合に読み込まれる初期化ファイルです。システムワイドな初期化ファイルであり、シェル環境のカスタマイズには使用されません。Mac OS X Leopardの場合、/etc/profileが処理される過程で読み込まれます。

6) ~/.bashrc
　シェルがプロセスとして起動された場合に読み込まれる初期化ファイルです。環境変数の定義などシェル環境のカスタマイズを行う場合、通常はこのファイルを利用します（後述）。

・初期化ファイルの優先順位
　bashの初期化ファイルには、優先順位が設けられています。まず、ユーザがログインすると、システムワイドな初期化ファイル「/etc/profile」が読み込まれます。次に、「~/.bash_profile」を読み込みますが、存在しない場合には「~/.bash_login」が読み込まれます。「~/.bash_profile」と「~/.bash_login」の両方とも存在しない場合は、「~/.profile」が読み込まれます。

　bashの場合、シェル環境のカスタマイズを目的とした日常使用の初期化ファイルは、本来「~/.bash_profile」が使用されます。ただし、ユーザのログイン後新たにシェル（bash）を起動したとき — シェル上から子プロセスとしてbashを起動したとき — には「~/.bashrc」が読み込まれます。　この問題は、両者を個別に管理するのではなく、「~/.bash_profile」の中に「~/.bashrc」を読み込むための命令を書き加えることで対処できます。つまり、カスタマイズ目的の初期化ファイルには「~/.bashrc」を使用し、「~/.bash_profile」には以下のコマンドライン1行を用意しておけば、初期化ファイルの準備は万端です。

- - - - -
source .bashrc
- - - - -

　次回は、この「~/.bashrc」に書いておくべき内容について説明します。

◇MOSAからのお知らせと編集後記は割愛します◇