目次

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

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

〜「Podcast プロデューサー」編〜

　今回はPodcastプロデューサーの稼働に必要となるXgridについて解説します。実はPodcastプロデューサーでシステムを構築するには他にも必要となるサービスがあるのですが、まずはXgridからみていくことにします。
　
◇Xgrid
　XgridはTigerで初めて搭載されたサービスで、Xgridを用いることで、ネットワーク上の複数のコンピュータで処理を分散して実行できるようになります。Xgridによるシステムを構成するには、まず次の3つのコンポーネントについて理解しておく必要があります。

・Xgridを構成するコンポーネント

クライアント：Xgridにジョブ（処理）を依頼するコンピュータ
コントローラ：ジョブを管理するコンピュータ
エージェント：タスク処理を実行するコンピュータ

　Xgridに処理を依頼するのはPodcastプロデューサーですので、この場合クライアントはPodcastプロデューサーになります。
　コントローラにはMac OS X Serverを使用します。コントローラはクライアントからジョブを受け取り、ジョブを複数のタスクに分割してエージェントに処理を依頼します。
　実際に処理を実行するのがエージェントです。エージェントにはMac OS XとMac OS X Serverの両方を利用することができ、1台のコントローラから複数のエージェントを利用することができます。エージェントの台数に制限はありませんが、エージェントの数が増えるとネットワークなどシステム全体の負荷も高まるため、単純に台数を増やせば増やすほどよいというものでもありません。

◇Xgridの設定
　それではXgridの設定方法について解説します。今回は1台のサーバをXgridのコントローラ兼エージェントとし、同一サーバ上でPodcastプロデューサーを稼働させることにします。
　Xgridサービスを設定するには「サーバ管理」を使用します。まず「サーバ管理」からサーバに接続し、左側のリストからXgridを選択します。Xgridをまだリストに表示していない場合は、リストからサーバを選択してツールバーから「設定」＞「サービス」を選択し、「Xgrid」を有効にして画面右下の「保存」ボタンをクリックします。
　Xgridの「設定」画面ではエージェントとコントローラについてそれぞれ設定ができますが、アシスタント機能を使って設定することもできます。
　アシスタント機能を利用するには「概要」画面の右下にある「Xgridサービスを構成」ボタンをクリックします。なおこのときサーバ上ではすでにOpen Directoryのマスターが稼働しているものとします。

・Xgridのサービス構成アシスタントの設定手順

1. アシスタント画面が表示されたら、「続ける」ボタンをクリックします。
http://www.htabata.com/img/MXS105/xgrid/Xgrid_admin_02.png

2. 構成画面では「グリッドを管理」を選択して「続ける」ボタンをクリックします。「グリッドを構成」を選択するとMac OS X Server上でエージェントとコントローラの両方が起動します。
http://www.htabata.com/img/MXS105/xgrid/Xgrid_admin_03.png

3. 認証画面ではディレクトリ管理者のユーザ名とパスワードを入力して「続ける」ボタンをクリックします。
http://www.htabata.com/img/MXS105/xgrid/Xgrid_admin_04.png

4. 最後に設定内容を確認すればXgridサービスの設定は完了です。

　以上の操作でMac OS X Server上でXgridのエージェントとコントローラが使用可能になります。このときエージェントはコントローラとして自分自身を使用し、認証方式にはKerberosを使用するよう設定されます。

◇Xgridの動作確認
　Xgridには管理ツールとして別途「Xgrid Admin」も用意されています。このツールも「サーバ管理」と同様にAdmin Toolsの一部ですので、クライアントのMac OS X上でも使用可能であり、「/アプリケーション/サーバ/」にインストールされます。
　「Xgrid Admin」を使用するとXgridのコントローラに接続して、Xgridの状態を確認することができます。クライアントからネットワーク経由で「XgridAdmin」を使用する場合は、まず「ディレクトリユーティリティ」を使ってクライアントをOpen Directoryのサーバに接続しておきます。これはXgridコントローラへの接続時にKerberosを使って認証するためです。

　「Xgrid Admin」が起動したらまず接続するコントローラを指定し、認証方式として「シングル・サイン・オン資格情報を使用する」を選択します。このときすでにKerberosのチケット(TGT)を取得していればそのままコントローラに接続できます。まだKerberosのチケットが取得できていない場合はKerberosの認証ダイアログが表示されて、認証を求められます。「XgridAdmin」ではエージェントの一覧などが確認できます。

・KerberosでXgirdの認証を行ったときのチケットの様子
http://www.htabata.com/img/MXS105/xgrid/Kerberos_01.png

　Developer Tools(Xcode)をインストールしている場合は、Xgridを利用したサンプルプログラムが収録されていますので、実際にXgridを使用することができます。

・Xgridのサンプルプログラムのパス
 

  /Developer/Examples/Xgrid

　サンプルプログラムは2つ収録されていますが「GridMandelbrot」は見た目も派手ですのでまずはオススメです。このサンプルプログラムを実行すると、Xgridを利用してマンデルブロ集合を描画することができます。サンプルプログラムを起動したときには「Xgrid Admin」と同様にコントローラと認証方式の指定が必要になります。

・Xgridサンプルプログラム「GridMandelbrot」
http://www.htabata.com/img/MXS105/xgrid/Xgrid_Mandelbrot03.png

　プログラムの実行中に「Xgrid Admin」をみるとXgrid全体でどれだけのCPUパワーを使っているかや、実行中のジョブを確認することができます。

・Xgrid Admin
http://www.htabata.com/img/MXS105/xgrid/AdminTool_01.png
http://www.htabata.com/img/MXS105/xgrid/AdminTool_03.png
次回へつづく

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

〜　ああ、SysBeep(1)が懐かしい！　〜

今回から、作成したモデルオブジェクトを管理し、アーカイブとしてファイルへ保存やメモリーへの読み込みを行うモデルコントローラの話に入ります。これは、Mac用のCocoaアプリケーションであれば「NSDocument」が行う仕事です。

OOPの世界では、モデル・ビュー・コントローラ（MVC）という単語がよく出てくるのですが、これは大ざっぱなクラス役割分担を指しています。大規模なアプリケーションなどでは、上記コントローラがモデル寄りの役割とビュー寄りの役割に分かれて作業分担している場合があります。片方をモデルコントローラと呼び、もう片方をビューコントローラと呼んだりします。まあ、正確なクラスカテゴリーの切り分けについては、私も勉強不足で良く理解できていませんが（笑）、例えば、Mac用Cocoaアプリケーションを開発する時に、Xcodeのプロジェクトテンプレート（雛形）から「Cocoa Documentbased Application」を選んで作業を開始すると、必ずAppKitNSDocumentクラスのお世話になります。

このNSDocumentクラスが、もっとも身近なモデルコントローラの例です。通常このテンプレートを使ったアプリケーションでは、NSDocumentクラスをスーパークラスとする独自クラスを用意し（例えばMyDocumentクラスとか…）そこで、NSDocumentクラスが実装しているメソッドをオーバライドすることで、ファイル保存されているドキュメントに対する操作（読み込みや書き出し）などを実現します。しかし残念ながら、iPhoneのUIKitには、これに準じるクラスが存在していません。まあ、iPhoneアプリでは不特定多数のファイルを同時に取り扱うケースが少ないので、モデル管理としてはSQLite（データベース用フレームワーク）があれば十分だろうと言う判断かもしれません。

しかし、今回はSQLiteを使わずに、独自でモデルコントローラを実装してみることにします。さてモデルコントローラの話へと移る前に、実際のコーディング作業を効率良く行うための準備をします。まず最初に、テキストエディターの各種設定を自分の環境に合わせることが大事でしょう。それには、Xcode環境設定の「コード入力補助」「キーバインド」「テキスト編集」「フォントと
カラー」などに含まれる設定項目の意味を良く理解し、それを自分の環境にマッチした設定に変更する必要があります。まあ、すべてデフォルトでOKな人はまったく問題ないのですが（笑）ちょっとした設定を変更するだけで、ソースコードの入力し易さが激変することがありますので、一度腰を落ち着けてチェックしてみてはいかがでしょうか？

例えば「コード入力補助」の「自動的に候補を表示」の設定ですが、これが機能するのが「大きなお世話」だと感じる人もいるはずです。その場合は「しない」に変更します。候補が表示されるタイミングも「すぐに」と「少し経ってから：」（秒数も指定可能）の2種類から選べますので、どちらが自分のキータッチのタイミングに合うのか試してみることが大事です。加えて、エディター入力時の文字サイズとカラーも環境設定の「フォントとカラー」で調整しておきましょう。大きなスクリーンを利用している人は、10ポイント文字ではさすがに小さすぎますし（老眼ではないとしても）、デフォルトもカラー設定もちょっとビビッド（笑）すぎるような気がします。結局、筆者はすべてのカラーの輝度を落とすことで再調整してしまいました。

そうそう、文字カラー変更の話が出たついでに、このカラー変更の対象となるインスタンス変数名の話もしておきます。前回、モデル（Model）クラスを定義する時に、そのインスタンス変数の先頭を「mo_」という表記で揃えました。これは「二文字＋アンダーバーが先頭についているのはインスタンス変数である」という「識別し易さ」を考慮したわけですが、これについては色々な意見があると思います。「カラーを変更すればOKでは？」と言う人もいるでしょう。Apple社のフレームワークで定義されているインスタンス変数は先頭にアンダーバーが付いていますので、それらを継承したクラスの方では一般的な変数名を付けても問題はありません。ですから、「md_name」は、単純に「name」の方が分かり易いという人もいるでしょう。

今までMac用Cocoaアプリケーションを開発する時には、ほとんどの場合はアクセッサを用いてインスタンス変数にアクセスしました。ですから、対象クラスの外でインスタンス変数を記述するようなことは滅多にありませんでした。しかし、プロパティ宣言ができるようになり、ドット演算子によるアクセスが可能となって、インスタンス変数名がソースのあちらこちらに登場するようにな
りました。この状況で各クラスに同じインスタンス名があると、その名称をエディターで一括変換（全ソース対象）したい場合に問題が生じます。まあ、これはアクセッサメソッド名の一括変換についても同じことが言えるのですが…。とにかく「変数名についてはこうだ！」「メソッド名はこうだ！」と、自分の中で一貫したルールを決めておくことが重要なのかもしれません。

続いてもう一つ！　CocoaにはNSLog()という便利なコンソールへのログ書き出しルーチンが存在します。これをうまく活用して何らかの情報を表示すれば、デバッグを効率良く行うことができます。しかし、筆者も含めて昔から簡単なデバッグにビープ音を使っている人も多いと思います（本当か？）。「その処理を通ったのか、通らなかったのか？」「どの処理まで入ってきたのか？」
「そこを何回通ったのか？」などなど、ビープ音による識別は、コンソールをオープンせずともちょっとしたチェックが可能で大変便利なのです。ところが、iPhoneのUIKitにはCarbonのSysBeep(1)やMac版CocoaのNSBeep関数が存在しません。つまり簡単にビープ音を鳴らすことができないのです。

ならばと言うことで、AudioToolboxのAudioServicesCreateSystemSoundID()ルーチンを使い、以下の様なビープ音を鳴らすルーチンを作ってみました。ビープ用のサウンドファイル（bp.wav）をプロジェクトのResourcesグループに登録しておき、アプリから呼び出して使います。

SystemSoundID   sys_sound;

void sysBeep()
{
   NSString    *path;
   NSURL       *url;

   if( ! sys_sound )       
   {
       path=[[NSBundle mainBundle] pathForResource:@"bp" 
                                                     ofType:@"wav"];
       if( url=[NSURL fileURLWithPath:path ) 
            AudioServicesCreateSystemSoundID( (CFURLRef)url,
                                                       &sys_sound );
   }
   if( sys_sound )
       AudioServicesPlaySystemSound( sys_sound );
}

AudioServicesPlaySystemSound()は短い（5秒以内）サウンドを鳴らすための便利なルーチンです。ところが、現在のiPhoneシミュレーターは、このルーチンでは音がでません（実機は大丈夫）。シミュレーターで鳴らせなくてはデバッグ時には活用できません。Core Audioを使いサウンドを鳴らすクラスを実装すればOKなのですが、処理が少々大げさでビープルーチンとは言い難くなります。困っていたところ、iPhone OS 2.2からAVFoundationと呼ばれるフレームワークが登場し、そこに含まれるAVAudioPlayerクラスを使うと、シミュレーターでも簡単にビープ音が鳴らせることが分かりました。現在では、このルーチンをデバッグにフル活用しています。Objectibve-Cにおいても、こうしたユーティリティ的なルーチンはCルーチンとして実装しておく方が便利です。

AVAudioPlayer    *sys_beep;

void sysBeep()
{
   NSString    *path;
   NSURL       *url;

   if( ! sys_beep )
   {
       path=[[NSBundle mainBundle] pathForResource:@"bp" ofType:@"wav"];
       if( url=[NSURL fileURLWithPath:path] )
           sys_beep=[[AVAudioPlayer alloc] initWithContentsOfURL:url
                                                               error:nil];
   }
   if( sys_beep )
   {
       sys_beep.currentTime=0;
       [sys_beep play];
   }
}

ちょっと寄り道をしましたが、次回から本格的にモデルコントローラクラスを実装していきたいと思います。まずは、モデルのアーカイブ化を行うために、NSCodingプロトコルに準拠したencodeWithCoder:とinitWithCoder:の2つのメソッドを用意することから始めたいと思います。

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

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

　コマンドは、ターミナルの画面上で手入力されるだけの存在ではありません。システム運用の実際では、むしろ「シェルスクリプト」の形で利用されることが多く、その使い方と基本的な記述方法は知っておいて損のないものです。ターミナルシリーズ9回目となる今回は、シェルスクリプトについて説明します。

・シェルスクリプトとは
　シェルスクリプトとは、かんたんにいえば「コマンドのら列」です。実行順にコマンドを並べたテキストファイルがシェルスクリプトの本質であり、拡張子などファイル名に関する命名規則もありません。後述しますが、ファイルに実行権限を与えれば（実質的に）コマンドとして機能します。
　それでは、ごくかんたんなシェルスクリプトで説明してみましょう。標準出力（初期値はターミナルの画面）に「MOSA」という文字列をアウトプットする、わずか1行で構成されるものです。ファイル名は、仮に「mosaout.sh」としておきます。適当なテキストエディタで以下の行を入力し、ホームフォルダ直下へ保存してください。

- - - - -
echo "MOSA"
- - - - -

　作成したシェルスクリプトは、シェルに引数として渡すことで実行します。一般的に、シェルスクリプトはどのシステム（歴史的経緯からUNIX系OSが前提）にも備え付けられている「sh」で実行されることが想定されているので、ここでも「sh」で実行することにします。ターミナルを起動し、以下のとおりコマンドラインを実行すれば、シェルスクリプト（mosaout.sh）の内容が実行
されたことがわかります。

- - - - -
$ sh mosaout.sh
MOSA
- - - - -

・実行権限を与える
　シェルスクリプトは、ファイルに「実行権限」を与えることで、あたかも（バイナリ形式の）コマンドであるかのように振る舞うことが可能です。実際、Mac OS Xにもzles（/usr/bin/zless）やapropos（/usr/bin/apropos）など、コマンドとして使われているシェルスクリプトが多数存在します。
　ファイルに実行権限を与えるには、chmodコマンドを利用します。オプションに「+x」を与え、引数に先ほどのシェルスクリプトを指定すればOKです。参考までに、実行権限を与える前後のファイル詳細情報を添えておきますが、与えたあとは「x」が増えていることがわかるはずです。

- - - - -
$ ls -l mosaout.sh 
-rw-r--r--  1 shinobu  staff  12  2 22 08:01 mosaout.sh
$ chmod +x mosaout.sh 
$ ls -l mosaout.sh 
-rwxr-xr-x  1 shinobu  staff  12  2 22 08:01 mosaout.sh*
- - - - -

　実行権限が付与されたあとは、起動用のシェル（sh）を指定することなく、現在実行されているシェル（bash）でシェルスクリプトが実行されます。ちなみに、Mac OS Xに収録されている「sh」は、bash（/bin/bash）のファイル名が変更されたもので機能差はなく、「shmosaout.sh」としたときと同じ結果を得られます。
　ただし、カレントディレクトリにコマンドサーチパス（第38回を参照願います）は通っていないため、ファイル名だけではシェルスクリプトを実行できません。パスの指定、この場合カレントディレクトリ直下のファイルであることを示す「./」を、ファイル名の先頭に加える必要があります。なお、このファイルをパスの通ったディレクトリ — /usr/binや/usr/local/bin — へコピー
すれば、当然ながらこの記号を入力する必要はありません（「mosaout.sh」と実行するだけでOK）。

- - - - -
$ ./mosaout.sh
- - - - -

　もう少しシェルスクリプトらしい体裁も施しておきましょう。シェルスクリプトが実行された場合、インタープリタである（現在実行中の）シェルはスクリプトの1行目に記述されている内容を判断し、子プロセスとして実行するためのバイナリを決定するため、1行目にはシェルスクリプトを実行したいシェルのフルパスを記述しておくことが「お約束」となっているからです。
　前述したとおり、シェルスクリプトはUNIX系OSならばほぼ確実に収録されている「/bin/sh」で実行されるため、1行目には「/bin/sh」を指定する記述を加えておきます。つまり、mosaout.shは以下の内容で一応の完成を見ることになります。
　1行目の記述を変更すれば、他のスクリプト言語も実行できます。たとえば、Perlは「#!/usr/bin/perl」、Rubyは「#!/usr/bin/ruby」となります。なお、他の言語の場合も実行権限の付与は必要です。

- - - - -
#!/bin/sh
echo "MOSA"
- - - - -

　シェルスクリプトでなにか処理を行おうした場合、重要な役割を果たすのが「シェル組み込み（ビルトイン）コマンド」です。シェルには、条件分岐やループ処理などの機能を持つコマンドが多数装備されているので、それを活用してプログラミングを行えば高度な処理が可能になります。次回は、構文ルールなどの解説とともに、参考となる書籍やWebサイトを紹介する予定です。

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

目次

• iPhoneデベロッパープレゼンテーション in サンフランシスコレポート
• りんご味Ruby　　　　　　　　　第41回　　藤本 尚邦
• 藤本裕之のプログラミング夜話　　　#154
• 高橋真人の「プログラミング指南」　　第152回

iPhoneデベロッパープレゼンテーション in サンフランシスコ　レポート

株式会社ジェイズアヴェニュー　今村 哲矢
株式会社ロイヤルガジェット　高浦 二三康
株式会社GClue　佐々木 陽

■はじめに

（今村）
1月7日、サンフランシスコのSix Apart社の会議室で、日本のiPhoneデベロッパーの一員としてプレゼンを行なってきました。初めてのアメリカで初めての英語でのプレゼンという事で、とても緊張しましたが、とても良い経験を得る事ができました。

今回のプレゼンは、サンフランシスコで1月5日〜9日まで開催されていたMacworld Conference & Expo 2009に合わせて、ジャーナリストの林信行氏が発案されたものです。昨年の12月24日には、都内の老舗旅館に集まり、事前の打ち合わせが行なわれました。その時には、プロモーションビデオの撮影も行なわれました。

◎iphone demo event promo video on Vimeo
http://vimeo.com/2627240

■プレゼンで紹介したアプリ

（今村）
私は、第5回のDEMOsaに出演させて頂いたのですが、その時に発表した3Dシューティングタイプのデモに加えて、育成ゲームタイプのデモを用意しました。どちらのデモも、秒間60フレームの3Dグラフィックスを実現し、iPhoneの傾きを検出して上下左右を見回せるようになっています。

◎Realtime 3D graphics on iPhone
http://www.jsavenue.co.jp/en/news/sanfra_presen.pdf

（高浦）
てるてる坊主をモチーフにしたアプリを3本紹介しました。WeatherChanger　てるてる坊主をiPhoneに移植したアプリ。逆さにすると雨が降ります。

TeruTeru　　　　iPhoneを傾けててるてる坊主を操作し、雨を避けて飴をとるミニゲーム。
TeruMemo　　　8種類のてるてる坊主が登場するかわいさがウリのメモ帳アプリ。

せっかくいただいたSFでのプレゼンの機会、ただ弊社のアプリを紹介するだけではつまらない、何かテーマが必要であろうと思いました。そこでアメリカであまり知られていないてるてる坊主をモチーフにしたアプリを開発し、紹介しようと考えました。これによってアメリカでてるてる坊主を知っている人が増えれば大成功です。

(佐々木)
iKoto、Geishaのアプリの2本を紹介しました。

Geisha　 Geishaが画面で踊るアプリです。
iKoto　　 琴演奏アプリです。

現地会場には、リアル琴の演奏に日本人琴サークルの方々が来てくれました。そのため、日本の伝統的な楽器をiPhoneで再現したiKotoはすぐ理解してもらえました。Geishaは、米国人もみな知っており、$1で芸者が手に入りますと説明すると、会場で笑いを取ることができました。

■現地での顔合わせ（5日）

（今村）
1月5日の午前中にサンフランシスコ空港に一人で到着した私は、到着ロビーの上の階の駅から電車に乗り、市の中心へ。駅を出てすぐにホテルにチェックインしました。部屋にはLANケーブルがあり、MacBookを繋いで使用手続きをして、早速メールチェックを行ないました。インターネット共有を行なう事で、iPhoneもWiFi経由でネットに接続する事ができました。ちなみにMacworldの会場では無料でWiFi回線が開放されていたので、大助かりでした。

午後には、参加者やご支援をして頂ける方達と合流しました。打ち合わせ後には、Macworldの会場であるMoscone Centerに徒歩で向かい、会場のパスを入手しました。夜には、サンフランシスコ在住のdrikin氏のご自宅にお邪魔して、リハーサルをさせて頂きました。翌々日に本番を控え、皆さんの表情には緊張と興奮がありました。

(佐々木)
日本の成田で、同じ便になった、a2c氏と株式会社エイチアイの高橋憲一氏と合流し、一同でサンフランシスコへ。今回は、宿泊費を抑えるためにa2c氏と相部屋にし、1人1泊7000円ぐらいでした。現地について、林氏に連絡すると、みんなでご飯を食べているとの事で、早速合流しました。その後、Moscone CenterでMacworldのレジストをし、drikin氏の家に。早速、現地MacworldのUEIブースでのプレゼンの説明や、Six Apart社でのプレゼンの相談などをし、1回目のリハーサルをおこないました。正直、英語でプレゼンなので、大学生以来だったので、かなり緊張しました。

■Macworld会場でのプレゼン（6日〜9日）

（今村）
Macworld開催期間中には、UEIの清水亮氏のご支援により、Macworld会場のUEIブースでもプレゼンをさせて頂ける事になりました。会場を歩いている人に向かって英語でプレゼンをするのはとても緊張しましたが、大きな自信を得る事ができました。

（高浦）
UEIのブースにて2回プレゼンを行いました。1回目はてるてる坊主というものを詳しく説明してみましたが、ただ説明するだけではアメリカ人の興味を引く事ができず、最後まで見ていてくれた人はいませんでした。プレゼンとしては失敗です。そこで2回目は紹介するアプリをTeruMemo1本に絞り、まず最初にこれはこんなアプリだと提示し、見ている人にフライヤーを渡してそれから少しだけ補足説明を加える作戦に出ました。おいしいところは後にとっておくのではなく、最初に出してしまってお客さんの気持ちをつかむ方がプレゼンとしては良いのかと感じました。インパクトを出す事の大切さを知りました。

(佐々木)
UEIのブースで1回プレゼンをさせてもらいました。プレゼン内容は、iKotoで米国国歌の演奏です。演奏していてとても気持ちよかったです。UEIブースでは、一言も英語をしゃべらずにiKotoだけでプレゼンに挑戦しました。

■Six Apart社でのプレゼン（7日）

（今村）
いよいよ1月7日の夜、会場である赤レンガのおしゃれなSix Apart社に集まりました。招待に応じて来て頂いたプレスやブロガーの方達は30名を超え、会場は満員状態。Ustreamでネット中継される中、プレゼンが始まりました。

私の番では、この時の為に進めて来たいろいろな準備や、ご支援を頂いた方々、そして会社のメンバーの姿が頭に思う浮かびました。おかげ様で、プレゼンは盛況に終わりました。他の発表者の方達も、とても素晴らしい出来映えでした。

（高浦）
いよいよSix Apart社のオフィスでのプレゼンです。「詳しい説明よりもインパクトを」これがMacworldでのプレゼンで学んだ事なので、スライドを切り替えるタイミングを事前によく考え、バスタオルで作った大きなてるてる坊主など小道具も用意してプレゼンに望みました。その甲斐あってスライドのメインとなる一枚を開いた瞬間笑いをとる事ができました。実機でのデモも楽しんでみてもらう事ができたので自分としては合格点です。

ただ、撮影していただいたビデオを後で見てみるとやはり英語がメチャクチャでした。英語に関してはこれからも勉強が必要ですが、発音の上手い下手よりもスラスラ喋れているかどうかの方が重要だと思います。スムーズにはなせていれば発音が下手でも多少はそれらしく見えると思います。

(佐々木)
Six Apart社のオフィスのプレゼンは、今回の主目的だったので大変緊張しました。私の出番は2番目。とりあえず、会津から大量に持参した「アカベー(次世代あかべこ)」を使って場を盛り上げ、Geisha、iKotoのデモンストレーション。Geishaは、日本を代表する文化だけにみなさん大盛り上がり。iKotoは、私のぎこちない米国国歌演奏を聴いてもらいました。かなり緊張しましたが、大変貴重な経験になりました。また、当日は林氏、外村氏、UEIの清水氏、drikin氏をはじめ様々な方にサポートしてもらい、大盛況なうちにプレゼン会を終えることができました。

◎iPhone DEMO in S.F. vol.1, drikin Ustream.TV: .（開始は0:29:00付近からです）
http://www.ustream.tv/recorded/1037486

◎iPhone DEMO in S.F. vol.2, drikin Ustream.TV: .
http://www.ustream.tv/recorded/1037787

■その他

（高浦）
・iPhoneフル活用
異国の地でもiPhoneは大活躍でした。特に実感したのはWiFiの威力。日本ではSoftBankの電波があるのでWiFiを利用する必要は特にありませんでしたが、SFではデータローミングをオフにしてWiFiを利用。快適なネットワーク環境でした。普段はiMacで開発を行っており、ラップトップのマックを持っていなかったので、メールチェックやアプリのSales/Trend Reportsのチェックなど必要な仕事のほとんどはiPhoneで行いました。他にもマップアプリのおかげで道に迷う事もなく、記念撮影もiPhoneで。もう海外に行くのにiPhoneは手放せません！　そんな大活躍の私のiPhoneがひったくられるという事件がありましたが・・・走って取り返しました(笑) 悲しいですがこれもアメリカの現実なのでしょう。WiFiの電波を探して夜のSFの街を歩くのは危険です。

（高浦）
・SFの携帯事情SFの街を歩いていると、いわゆる普通の携帯電話を持っている人はあまり見か
けず、iPhoneやその他のスマートフォンを操作している人の方が多いように見えました。日本もいずれこうなると思います。スマートフォン元年といわれる2009年、今のうちにスマートフォン向けのプログラミングを勉強しておこうと思いました。

■最後に

（今村）
アメリカで弊社（ジェイズアヴェニュー）のアピールが出来た事に加えて、実際にアメリカでiPhoneが普及している様子を見た事、アメリカでのiPhoneに対する関心の高さに触れた事が、大きな収穫でした。そして何より、iPhoneを通して多くの人に出会えた事が、代え難い大きな収穫になりました。

現在私は、iPhoneアプリをAppStoreに並べるべく開発を進めています。ご支援を頂いた方達の期待に応えるべく、努力を続けてまいります。弊社に関心のある方は、是非ご連絡をくださいませ。それでは、よろしくお願い申し上げます。

（高浦）
今回のSFでのプレゼンは私にとりまして大変貴重な経験になりました。私以外にプレゼンをされました多数の優秀なiPhoneディベロッパーの仲間に入れた事を誇りに思います。今回のイベントを発案されました林信行氏、Six Apart社の皆様、Macworldにてプレゼンの場としてブースを提供していただきましたUEIの清水亮氏、その他大勢のお力添えをいただいた方々に深く感謝いたしま
す。

(佐々木)
iPhone世代からは、自分の意思さえあれば、世界と勝負できる時代になったのだなと改めて実感しました。また、米国でのプレゼンの機会は非常に貴重な経験になったと同時に、これからどんどん米国や世界に向けていろいろとアピールしていかなければと強く感じしました。

また、当日UEIブース、Six Apart社でのプレゼンをサポートしてくださった方々に深く感謝いたします。次回は、WWDC近辺で、また米国でいろいろTryできればと思います。それまでに英語を上達させておきます。

■懇親会のお知らせ

（今村）
来る2月28日に、プレゼンの打ち上げを兼ねて、iPhoneデベロッパの懇親会を開催いたします。詳細は、iPhone Developer Japanで確認できますので、ご興味のある方はアクセスしてみてください。

◎iPhone Developer Japan | Google グループ
http://groups.google.co.jp/group/iphone-developer-japan

■執筆者プロフィール

株式会社ジェイズアヴェニュー　　今村　哲矢
http://www.jsavenue.co.jp/
ファミリーベーシックでゲーム作りを体験して以来、ゲームを制作する仕事が将来の夢に。大学卒業後にゲーム会社に就職。その後、現在の会社に転職をし、iPhone向けのゲームの開発を行なっている。

株式会社ロイヤルガジェット　　高浦　二三康
http://royal-gadget.co.jp/
高校時代、iモード向けにiアプリを開発していた事でプログラミングの楽しさを知る。2008年9月、iPhoneアプリを作りたくて社会人1年目にして起業。現在9本のアプリをリリース。

株式会社GClue　　佐々木　陽
http://www.gclue.com/
携帯電話アプリ開発一筋9年目です。9年の中でiPhoneアプリを作っている今が一番楽しいです。現在までに17本のiPhoneアプリをリリースし、今後もどんどん新作をリリースしていく予定です。

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

今回は、ブロック付きメソッドの定義方法についてです。これを覚えてしまえばRubyプログラミングは格段におもしろくなりますよ。

■ ブロック付きメソッドの定義

◇ ファイルの各行をブロックで処理するメソッド

まず、比較的単純な例として、引数で指定されたテキストファイルの中のそれぞれの行に対して、ブロックで渡された手続きを実行するというメソッドについて考えてみましょう。ファイルのオープン・クローズなどの定型処理を隠蔽して、各行の処理だけに集中するためのメソッドです。これをFileクラスのeach_line_for という名前のクラスメソッドとして実装しましょう。以下のような仕様にします:

File.each_line_for(ファイルへのパス) do |1行分の文字列, 行番号|
　　それぞれの行に対する処理
　end

具体的には

　File.each_line_for("/etc/services") do |str, index|
　　printf("%5d: %s n", index, str)　# 行番号付きで出力
　end

のように使います。まずは、この例を既存のメソッドだけを使って書いてみます:

File.open("/etc/services") do |io|   # ファイルを開く
   index = 1                          # 行番号の初期化
   io.each_line do |str|              # それぞれの行について...
     str.chop!                        #   改行文字を取り除く
     printf("%5d: %s n", index, str)  #   渡されたブロックの中身
     index += 1                       #   行番号を更新
   end                                #
 end                                  # ファイルを閉じる

上のプログラムの printf の行の部分が、File.each_line_for の実装では、ブロックとして実行時に渡されるということになります。では、さっそくFile.each_line_for を実装してみしょう:

 def File.each_line_for(path, &block)
   File.open(path) do |io|            # ファイルを開く
     index = 1                        # 行番号の初期化
     io.each_line do |str|            # それぞれの行について...
       str.chop!                      #   改行文字を取り除く
       block.call(str, index)         #   渡されたブロックを実行
       index += 1                     #   行番号を更新
     end
   end                                # ファイルを閉じる
 end

いかがでしょうか？　この2つを見比べて違うのは printf の行のところだけですね。

each_line_for の引数リストの最後にある &block が、ブロック付きでeach_line_forが呼ばれたときのブロック手続きそのもの(Procクラスのインスタンス)になります。blockに対してcallメソッドを呼ぶことにより、ブロックの中身を実行しているわけです。

このように、ブロック付きメソッドを実装するときには、もともとのプログラムの中からブロック手続きとして抽象化したい部分を抽出して、その部分をblock.call のように置き換えることになります。

◇ ブロックの省略

次に、ブロックが省略された場合、各行を行番号順に並べた配列を返すという仕様を each_line_for に追加してみましょう:

　File.each_line_for(ファイルへのパス) 
　　=> [ 1行目文字列, 2行目文字列, 3行目文字列, ... ]

これはブロック付きの each_line_for を使って実装することができます:

 ary = []                               # 空配列を生成
 File.each_line_for(path) do |str,idx|  # それぞれの行について...
   ary << str                           #   配列に追加  
 end
 ary                                    # 完成した配列

これを each_line_for に組み込みます:

 def File.each_line_for(path, &block)
   if block_given? then               # ブロック付き
     File.open(path) do |io|
       index = 1
       io.each_line do |str|
         str.chop!
         block.call(str, index)
         index += 1
       end
     end
   else                              # ブロックなし
     ary = []
     File.each_line_for(path) { |s,i| ary << s }
     ary
   end
 end

組込みメソッドの block_given? によりブロックの有無を判断しています。ブロックがなければ、今度は、配列への追加手続きを行うブロックを付けて、自分自身をもう一度呼び出し直すわけです。「ブロックの省略＝デフォルトのブロック手続きとして配列への追加を選択」したのだと考えてもいいでしょう。

次回は、/Developer/Examples/Ruby/RubyCocoa/Scripts/circle.rb に入っている CoreGraphics を使ったPDFファイル生成スクリプトを元ネタにして、PDFファイル描画生成DSL を作ってみようかと思います。

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

　タイムリーというかシンクロニシティというか、先日テレビで1986年に施行された労働者派遣法成立に関する裏話みたいな番組をやっていてとても興味深かった。それによると労働省（当時）は、当初からこの派遣法の眼目を（1）横行している偽装請負（受託業務と称して人員を派遣する、つまりオレがやってたヤツですな）の現状を追認すること、および（2）労働者の流動性を高めるための登録制派遣（働きたいヒトが派遣会社に「登録」し、仕事があるときだけ働く形態。これの究極が「日雇い派遣」になる）に道を開くこと、としていたらしい。

　しかし労働組合の強健な反対が目に見えていたため、とりあえず（2）は封印し、（1）に関しても現状追認と見えないように、例の「高度で専門的な知識や経験を要する」という文言を入れたんだ、と。

　トロイの木馬は「秘書」と「ファイリング」で、これについて労働者側には「単なるタイピストや通常事務ではない専門的な職種」と説明しつつ、実質的には派遣業者に単なる事務員を派遣する口実を与えるためのものだったんですな。派遣会社のエライさん（あるいは当時エライさんだったヒト）が画面に登場して「とにかく『秘書』と『ファイリング』を入れてくれ」と運動した」と言っていた。

　早い話、一度法律が施行されて派遣が始まってしまえばその拡大解釈はなしくずし的に「秘書」あるいは「ファイリング」という「高度で専門的な知識や経験を要する職種」が「単なる事務」を意味することになるだろってことだった、と。そんでその読みは的中した。オレの仕事場でも事務をやってたサイトーさんが産休を取ったとき派遣会社からオカザキさんって女の子に来てもらったもんね。彼女は実によくやってくれたけど、こっちだって決して彼女に「高度で専門的な知識や経験」を要求しはしなかったよ。

　話が逸れた。何が言いたいかというと、上の経緯を聞く限り当時派遣法に定められた13業種の中で、我らが「ソフトウエア開発」というのは「秘書」とか「ファイリング」といった「トロイの木馬」ではなく、心底から（かどうかは分からないが）多くのヒトがホントに「高度で専門的な知識や経験を要する職種」だと思っていたらしいよね、ということである。

　ここで皆さんにちと考えていただきたいのだが「高度で専門的」ってどんなことだね？ いやさ、この言葉が具体的に意味するのはどんなこと？ ……試しにYahoo!辞書を引いてみるとこう書いてある（ここに当てはまらないaltitudeの方は省いた）。

こう-ど【高度】　［名・形動］程度の高いこと。また、そのさま。せんもん‐てき【専門的】　［形動］ある分野に特にかかわりのあるさま。ある分野に精通しているさま。

　たとえば「程度が高い」だ。「高い」というのはね、もっと「低い」ところがあるから存在するのである。マシン語、あるいはアセンブリの存在を踏まえてCやPascalは「高水準言語」（「高級言語」って訳語は適当でない、と中村正三郎氏に叱られたので使わない）なのである。「専門的」もそうでしょ？ みんながその分野に関して同じ程度の知識や技量を持っていたら……いや、みんなが持っていなくても、持っているヒトの方が多かったら、それは「専門的」ではないのである。リクツだよね？

　つまり「高度で専門的である」ことの価値ってのは、イコール希少価値なのである。数が少ないってこと。

　最近とんとご無沙汰だが（年齢ですわな）、30代の半ばごろまでは結構友人の結婚式に出る機会があった。当然ながらオレの友人というのはオレと同じプログラマ、あるいはコンピュータ関係の仕事についているヤツが多く、そういう席で仲人のおっさんが挨拶をする。この仲人というのがワレワレの業界のニンゲンではない場合、ほぼ100％の確率で「新郎はコンピュータ関係の仕事、いわば最先端の仕事をしているわけでして」とか言ったもんなのね（今でも言うのかしら）。

　それを聞いてるオレたちは失笑しながら「ずいぶん太い『最先端』だこと」とか思ってたんだが、その通り、この「最先端」は時とともにどんどん太くなり、それに従ってこの仕事の「高度で専門的」な度合い……というかそれに付随する希少価値というものが下がってきちゃったわけである。
（以下次回　2009_02_12）

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

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

　皆さんこんにちは、高橋真人です。
　さて、前回「低レベル」のプログラミング言語について説明をし、今回は「より上のレベルへ」と言いましたが、「低レベルの上には中レベルがあって、そのまた上には...」ということではなく、低級言語の上はいきなり高級言語となります。
　もっとも、高級言語と言われるものは多岐にわたり、高級言語の中にも、さらにマシンに近い比較的低級なものから相当程度高級なものまでと様々なレベルのものが存在しています。
　では、高級言語の定義は何かと言いますと、「マシンの動作をそのまま記述」するものを低級言語と呼ぶのに対して、「意味的な内容」を記述することでプログラミングをするものということになります。
　意味的な内容と言われても分かりにくいかもしれませんので、例を挙げてみます。以下は、Perl（「パール」と読む）というスクリプト言語で書いた簡単なプログラムです。

for ($a = 10; $a > 0; --$a) {
   print "$a, ";
}

　このコードが表現しているのは、

・aという変数（数の入れもの）を用意し、
・最初に10を入れておいてから、
・順に1ずつ減らしながら画面に数字を出力することを繰り返す。

ということです。プログラミングに馴染みのない方には、これでもかなり違和感があるかもしれませんが、よく観察してみるとそれなりに上記の処理を表しているように読み取れませんでしょうか？
　では次に、これをCというプログラミング言語（そのまま「シー」と読みます）に書き直したものを紹介します。

#include 
int main(void)
{
   int a;
   for (a = 10; a > 0; --a) {
       printf("%d, ", a);
   }
   return 0;
}

　初めに紹介したPerlのスクリプトに比べて、より多くの記述が必要になっていますが、forから始まる3行の部分が極めて似ていることもお分かりになるでしょう。
　どちらのプログラムも実行した結果得られるものは同じで、以下のようになります。

10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 

　しかし、両者の実行のさせ方はかなり違います。折角ですので、実際に試してみましょう。
　アプリケーションフォルダの中にあるユーティリティフォルダを開くと「ターミナル」というアプリケーションがありますので、それを立ち上げておきます。
　次に、適当なテキストエディタを使って、上記のコードを入力します。もしテキストエディタをお持ちでない場合には、Mac OS Xに標準で入っているテキストエディットでも構いませんが、その場合、新規書類を作った後に、フォーマットメニューから「標準テキストにする」を選ぶことを忘れないでください。
　Perlのスクリプトはshinan.plという名前で、Cのコードはshinan.cという名前で保存します。これらのファイルは必ずホームフォルダに保存するようにしてください。
　では、まずはPerlの方を実行してみます。ターミナルで

perl shinan.pl

と打ってリターンキーを押します。これだけですぐにプログラムが走って、前述の数字の羅列を表示します。
　次にCの方を実行します。まず、ターミナルで

gcc shinan.c -o shinan

と打ってリターンキーを押します。次に、

./shinan

と打ってリターンキーを押すと、Perlの場合と同様に数字の羅列が表示されます。

　さて、実際に二通りのプログラミング言語を使ってプログラムを走らせてみたわけですが、それぞれは実行のさせ方に違いがありました。
　Perlの方は、perlというコマンド名のあとにスクリプトファイルを指定することで、そのまますぐに実行されたのに対して、Cの方は、まずgccというコマンドによってshinanという名の実行ファイルを作成して、次にそれを直接実行させたのです。
　高級言語は、大きく分けるとコンパイル型というのとインタープリター型というのに分かれるのですが、Perlはインタープリター型で、Cはコンパイル型となります。
　コンパイル型のプログラミング言語は、コードが書かれているファイルをコンパイラというプログラム（上記の例ではgcc）を使ってコンパイルし、さらにリンクという処理を行って実行ファイルを作成します。コンパイルというのは、コードを解釈してマシン語に翻訳する処理、リンクというのはプログラムが動作できるようにシステムの機能と結びつけること、というように考えておいてください。
　これに対して、インタープリター型のプログラミング言語の場合、インタープリターというプログラム（上記の例ではperl）が直接スクリプトファイルを解釈して、そのまま動作する形になります。

　コンパイル型の言語の場合、コンパイラが最終的に実行ファイル、つまりアプリケーションを生成してくれるので、実行ファイルは単独で動作します（つまり、実行時にはコンパイラはいらない）。
　それに対して、インタープリター型の言語では、スクリプトファイルはただのテキストデータですから、単独では動作できません。かならずインタープリターの力を借りなければ動作しないということです。

　私がプログラミングを学んだころは、コンパイラはまとめて変換してから実行し、インタープリターは1行ずつ通訳しながら実行する（実際、interpreterは通訳という意味）といった説明を受けたものですが、今やそんな単純な話ではなくなりました。
　Perlも内部的にはコンパイルをしているようですし、Javaのようにコンパイル型の言語であるにも関わらず、実行時にjavaというプログラムが別途必要になるものもあり、高級言語と一口に言ってもその成り立ち方は様々で、簡単にひとくくりできる時代ではなくなりました。

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

目次

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

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

〜「Podcast プロデューサー」編〜

　Podcast プロデューサー編の第2回目です。前回はPodcastの概要を解説し次のような手順で制作を行うことを確認しました。

　収録　＞　エンコード　＞　公開

　もっとも収録前には企画などの作業が発生しますし、それなりに露出するにはプロモーション活動も別途必要になってきます。また複雑な編集作業が必要になる場合もあるでしょうが、ここではPodcast制作のためにLeopard Serverで登場した「Podcast プロデューサー」に的を絞って解説していきます。
　まずは収録をしないことには話が始まりませんが、Podcastには大きく分けて音声のみの場合と、ビデオの場合があります。またパソコンの画面をキャプチャして制作する場合もありますがこちらはScreencastとも呼ばれています。

◇まずは収録
　ビデオカメラやテープレコーダ（最近はあまり見かけませんが）を使って収録してから、パソコンにデータを取り込むといったやり方でもかまわないのですが、Podcast プロデューサーを使用する場合はあらかじめ収録用のソフトが用意されています。
　Leopardであれば「アプリケーション」＞「ユーティリティ」フォルダに「Podcast キャプチャ」という名前のソフトがインストールされています。このソフトを使って音声、ビデオ、画面キャプチャのPodcast用コンテンツを収録することができます。Macにマイクやカメラが内蔵されていればそれらを利用することもできます。
　「Podcast キャプチャ」はLeopard Serverにもインストールされていますが、このソフトは収録したデータをネットワーク経由でサーバにアップロードする機能がありますので、収録にはクライアントのMac OS Xが利用できます。

　ここまで読んで「Podcastはやらないんだけれどもキャプチャ用のソフトとして使えるかな」と思った方もいるのではないでしょうか。ところがそんなに甘くはありません。起動してみるとすぐ分かるのですが、実際に使用するにはまず認証が求められるのです。

・「Podcast キャプチャ」の起動画面（認証）
http://www.htabata.com/img/MXS105/podcast/Capture_01.png

　ここでやみくもにローカルアカウントで認証しようとしてもダメですし、そもそもサーバのアドレスも指定する必要があります。認証画面にも説明が表示されますが、ここで指定するサーバのアドレスとはPodcast プロデューサーが動作しているMac OS X Serverのアドレスになります。つまり「Podcast キャプチャ」を使用するには、あらかじめサーバ側でPodcast プロデューサーの準備をしておく必要があるということが分かります。

◇やっぱりサーバの設定から
　というわけで、ここは早く収録したいという焦る気持ちを抑えてまずはサーバ側の準備からみていきましょう。「サーバ管理」を使ってPodcast プロデューサーを設定していきます。デフォルトの状態でもサービスを開始することはできるのですが、これでは正しく動作しません。デフォルトのままサービスを開始するとエラーログにxgridに関するメッセージが出力されていることが分かります。
　ここで初めてXgridという言葉を聞く方は「？？？」となるわけですが、Xgridとは分散コンピューティングのためのサービスです。ネットワーク上の複数のコンピュータで分散して負荷のかかる処理を行う場合に使用します。
　実はPodcast プロデューサーはエンコードのよな負荷のかかる処理をXgridの仕組みを利用することで、ネットワーク上のコンピュータで分散して実行することができるのです。なんだかなかなかPodcastにたどり着けませんが、Xgirdの準備をしないことにはPodcast プロデューサーは使えませんので、まずはXgridの設定から始めて行く事になります。

　Xgridを使うのなら処理用のコンピュータを複数用意しなければいけないかというと必ずしもそうではありません。もちろん本当に負荷を分散させるのであれば用意したほうがよいのですが、とりあえず試しに使ってみるというのであれば1台のサーバをPodcast プロデューサー兼Xgrid用のサーバとして使用することができます。では今回はここまでとなりますが、次回はXgridの具体的
な設定方法について解説します。

◇書籍紹介
　前回に引き続き書籍を1冊紹介しておきましょう。第84回の連載でApple技術者認定資格についてご紹介したときに参考文献（洋書）の紹介もしましたがその日本語版がいよいよ出版されます。今回出版されるのはMac OS X Serverについて解説したアップル認定公式トレーニングシリーズの1冊です。タイトルに第2版とついていますが、これはLeopard Serverを解説した内容になって
います。同じタイトルで第2版がついていない書籍もありますがこちらはTigerServerの内容になっていますので購入するさいには間違えないように注意してください。待望の日本語版が出版されることで認定資格を取得する環境も徐々にではありますが整いつつあります。

「Mac OS X Server Essentials 第2版」
http://www.borndigital.co.jp/book/detail.php?id=160
次回へつづく

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

〜　まずはモデルクラスを移植する　〜

今回は、「しんぶんし 3」でImageFileクラスとして定義したモデルクラス（メインデータ構造の定義）を、iPhone用アプリケーションの「Symmetry」へと移植する作業を行いたいと思います。

モデルクラスの話へ入る前に、前回積み残した話題をひとつだけお話します。iPhoneアプリケーションのローカライズですが、日本で開発したものであっても、少なくとも「英語」だけには対応しておきたいところです（Symmetryはそうする予定）。当然、日本語環境でしか意味を持たないアプリ（そんなに多くはない）つまり日本でしか販売を考えていないものなら日本語のみでOKですが、ワールドワイドでの販売を考えている場合には、英語ローカラーズに対応しておけば、それ以外の国での販売にもそこそこ対応できます。当然、フランス語、スペイン語、イタリア語、ドイツ語、ポルトガル語、 ロシア語程度がローカライズできれば、間違いなく販売数増加に貢献するでしょう。

もし、外国人の友達がいれば、そうした人達にちょっとローカライズ作業を手伝ってもらうのが良策ですね（笑）。翻訳が正しいかどうか分からない状況下では、自動翻訳ソフトや無料Webサービスを使うのはやめた方が良いでしょう。みっともない翻訳を掲載すれば、そのアプリケーションの評判まで落としかねません。例えば、アプリケーションの内容解説やユーザインターフェース回り
の簡単な文字列については、有料（わりと低価格）で翻訳サービスを提供しているサイトが幾つかあるようです。筆者は利用したことがないのですが、そうした翻訳サービスをうまく活用することもアリでしょう。ちなみに、以前に「DYS: Translations」というサイトを利用している方の話を聞いたことがあります。

http://www.dystranslations.com/

さて「しんぶんし3」でのモデルクラス ですが、 ImageFileという名称で、以下の様に定義（ImageFile.h）していました。このクラスのインスタンス（メンバー）変数は、すべてプロパティ宣言されています。

#import 
#import 

@interface ImageFile : NSObject　
{
   NSString          *path;
   NSString          *type;
   CGRect            srt;
   unsigned int      flag;
   int               kind;
   int               para;
}

@property(retain)NSString          *path;
@property(retain)NSString          *type;
@property(assign)CGRect            srt;
@property(assign)unsigned int      flag;
@property(assign)int               kind;
@property(assign)int               para;

@end

実際の実装（ ImageFile.m）では、各プロパティは@synthesizeディレクティブで宣言しておきます。これにより、プロパティのgetterメソッドとsetterメソッドを用意する必要がなくなります（コンパイラが適切に用意してくれる）。ちなみに、readonlyプロパティの場合はgetterメソッドのみが用意されます。

#import "ImageFile.h"

@implementation ImageFile

@synthesize path,type,srt,flag,kind,para;

// ここに必要なメソッドを実装する！

@end

#importの内容などを書き替えれば、このままの状態でiPhone用ソースコードとして利用してもほとんど問題ありませんが、先を見越してiPhone用に少しだけ改造しておきます。クラス名は分かり易くModelと変えます。よってクラス定義ファイルはModel.hとなります。まずは#import ですが、は不必要となりだけでOKです。Mac用Cocoaアプリケーションでは、CGRect構造体がQuartz.hに定義されているためにimportが必要でしたが、iPhone用アプリで使うUIKitでは、CoreGraphicsフレームワークが常用されるので、特別呼び込む必要がないわけです。また、NSUIntegerはunsigned int、NSIntegerはintと定義されています（現状）。

#import 

@interface Model : NSObject  
{
   NSString      *md_name;
   NSString      *md_type;
   UIImage       *md_image;    
   CGRect        md_rt;
   NSUInteger    md_flag;
   NSInteger     md_kind;
   NSInteger     md_para;
}

@property(nonatomic,retain)NSString    *md_name;
@property(nonatomic,retain)NSString    *md_type;
@property(nonatomic,retain)UIImage     *md_image;
@property(nonatomic,assign)CGRect      md_rt;
@property(nonatomic,assign)NSUInteger  md_flag;
@property(nonatomic,assign)NSInteger   md_para;
@property(nonatomic,assign)NSInteger   md_kind;

- (id)initWithName:(NSString *)name type:(NSString *)type;

@end

プロパティの属性としてnonatomicが宣言されていますが、これはプロパティへのアクセスに対してマルチスレッド環境を想定していないことを意味しています。その代わりに高速なアクセスが約束されます。将来的には、幾つかのプロパティについてnonatomic宣言を外すかもしれませんが、現状はこの状態としておきます。以下が、実際のクラス実装となるModel.mです。とりあえず、
初期化メソッドとしてinitWithName:type:をひとつだけ用意してみました（そのまま使うかどうかは？です）。NSCodingプロトコルに準拠した、encodeWithCoder:とinitWithCoder:の2つのメソッドについては、モデルのアーカイブ化を行う時に実際に実装したいと思います。

#import "Model.h"

@implementation Model

@synthesize md_name,md_type,md_image;
@synthesize md_rt,md_flag,md_kind,md_para;

- (id)initWithName:(NSString *)name type:(NSString *)type
{
   if( self=[super init] )
   {
     self.md_name=name;
     self.md_type=type;
   }
   return self;
}

- (void)dealloc
{
   [md_name release];
   [md_type release];
   [md_image release]; 
   [super dealloc];
}

- (void)encodeWithCoder:(NSCoder *)coder  // アーカイブ・エンコード用
{
   // 後ほど実装する
}

- (id)initWithCoder:(NSCoder *)coder      // アーカイブ・デコード用
{
   if( self=[super init] )
   {
       // 後ほど実装する
   }
   return self;
}

@end

Model.mで注目すべき記述は以下の箇所です。

 self.md_name=name;
 self.md_type=type;

ドット演算子を使って代入していますので、値の代入時にプロパティの属性で定義したretainをsetterメソッドが実行します。これを、md_name=name;と記述すると（記述は可能）md_nameに対してretainは行われず、メッセージ（引数）として渡されたnameがreleaseされると同時に、モデルオブジェクトに蓄えたmd_nameもメモリーから解放されてしまいます。くれぐれも御注意ください。

次回は、作成したモデルオブジェクトを管理し、アーカイブとしてファイルへ保存やメモリーへの読み込みを行うモデルコントローラを用意してみます。これは、Mac用のCocoaアプリケーションであれば「NSDocument」が行う仕事と同じです。

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

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

・よくお世話になる「ページャ」
　数多あるUNIXコマンドのなかでも特に利用頻度が高いのが「ページャ」です。ページャとは、テキストを画面に出力する機能を備えたコマンドで、「more」と「less」がその代表的存在といえます。
　ページャでは、ファイルの形で存在するプレインテキストのほか、他のコマンドから「パイプ」を経由して受け取ったテキストデータを表示することができます。ソースコードや「README」といったテキストファイルの閲覧はもちろん、「ls」（ディレクトリの内容をリストするコマンド） など大量のテキストを出力するコマンドの結果をバッファリングできるという点が、ページャの
利用頻度が高い理由の1つです。
　その「ls」を例に、ページャの使い方を説明してみましょう。ファイルが大量にあるディレクトリで「ls」を実行すると、画面がスクロールしてしまいますが、lsの結果をページャに引き渡す（パイプ）ことにより、スクロールアウトさせることなく目を通すことができます。lsコマンドの結果（「-l」オプションはファイルの詳細情報を出力する）をページャの「less」にパイプする例は、以下のとおりです。

- - - - -
$ ls -l | less
- - - - -

・moreとless、どちらがいいか
　Mac OS Xに標準装備されているページャは、「more」と「less」の2つです。どちらもページャとしての基本機能を備えていますが、後発の「less」のほうが多機能です。ちなみに、命名は「less is more」とのことで、謙遜した表現になっています。
　moreとlessの決定的な違いは、バックスクロール機能の有無にあります
（moreは非対応）。また、テキストデータを最後まで表示したあと、moreは自動終了してしまうのに対し、lessはユーザが終了の操作（「q」を入力）を行わないかぎり終了しません。データの先頭／末尾へのジャンプも、lessのみに実装された機能です。
　つまり、lessはmoreの上位互換機能を備えています。moreはUNIX草創期からあるコマンドで、その存在と機能を理解しておく必要はありますが、実際にページャとして利用するのはlessで十分です。オンラインマニュアルを表示するコマンド「man」など、いくつかのコマンドは表示／検索をページャに依存しますが、Mac OS Xなど多くのUNIX系OSではlessがデフォルトで設定されています。

・more／lessの使い方

　moreとlessは、テキストファイルを引数として与えるか、パイプで他のコマンドの実行結果を引き渡すかの2通りで実行されます。前者の場合、「less README」などと実行すれば、画面にテキストが表示され、lessの内部コマンド入力待ちの状態となります。
　必ず覚えておきたい内部コマンドは、「SPACE」と「q」の2つです。SPACEを何度か押してページを読み進め、用が済めば「q」（quit）で終了する、という流れが利用の典型パターンです。他の内部コマンドについては、表を参照してください。
　検索機能も、ぜひ覚えておきましょう。使い方は、第37回で紹介した「man」と同じ（manがlessの機能を利用しているので当然です）で、［/］キーを押し画面左下に表示された「/」に続けてキーワードを入力、［enter］キーを押して検索を開始します。ヒットした箇所は反転表示されるので、［n］キーを押して次のヒット位置へと移動し、目的の情報にたどり着きます。

▼▼▼
SPACE、C-v   1画面分下方へスクロール
d   半画面分下方へスクロール
enter、C-n  1行分下方へスクロール
b、M-v  1画面分上方へスクロール
u   半画面分下方へスクロール（lessのみ）
y、C-p  1行分上方へスクロール（lessのみ）
g   データの先頭へ移動（lessのみ）
G   データの末尾へ移動（lessのみ）
/文字列 指定した文字列をカーソル以降で検索
?文字列 指定した文字列をカーソル以前で検索
<   先頭行に移動
 最終行に移動
n   文字列の再検索
h   ヘルプを表示
q   終了
▲▲▲

・日本語テキストを表示する
　Mac OS X Leopardに標準装備の「less」は、UTF-8に対応したバージョン（v394）が採用されているため、日本語テキストを表示することが可能です。以下のコマンドをシェルで直接実行するか、bashの初期化ファイル（「~/.bashrc」など）に記述しておけば、LESSCHARSET環境変数に「utf-8」が定義され、UTF-8エンコードのテキストファイルを適切に表示できます。

- - - - -
$ export LESSCHARSET=utf-8
- - - - -

　しかし、標準装備のlessには、文字コード自動識別機能が装備されていません。EUCやS-JISでエンコードされた日本語テキストを表示する場合には、文字コードを自動識別するためのパッチが当てられたlessを追加インストールすることになります。
　そこでお勧めしたいのが「lv」です。操作方法（内部コマンド）はlessと同じで、かつ文字コード自動識別機能が装備されています。ソースコードの入手とインストールの手順は、以下のとおりです。

○LV Home Page
http://www.ff.iij4u.or.jp/~nrt/lv/index.html

- - - - -
$ curl -O http://www.ff.iij4u.or.jp/~nrt/freeware/lv451.tar.gz
$ tar xzf lv451.tar.gz
$ cd lv451/build
$ ../src/configure; make
$ sudo make install
- - - - -

　これでlvのインストールは完了ですが、出力する文字コードをターミナルの設定にあわせることと、デフォルトのページャとして使用するための設定が必要です。以下に示すコマンドを、~/.bashrcなどのシェル初期化ファイルに記述しておきましょう。次回ターミナルを起動したときから、「less」で「lv」の機能を利用できるようになります。

- - - - -
export LV='-z -la -Ou8'
export PAGER=lv
alias less=/usr/local/bin/lv
- - - - -

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

目次

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

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

前回までに実装してきた、真偽値アクセッサ宣言のための疑似的な構文糖衣attr_predicateは、アクセッサ名を列挙するだけというとてもシンプルなものでした。しかし私としては、ブロック付きの構文糖衣にこそ、Rubyに新しいDSL(Domain-Specific Language)を導入するときの醍醐味があると思います。ということで、今回はブロック付きの構文糖衣を取り上げます。

■ ブロック付きの構文糖衣の例

ブロック付きの構文糖衣が導入されるのはどんな場合でしょうか？　2つほど実例を上げていきます。

◇ rakeコマンド

Leopard には、Rubyで実装されたrakeというコマンドが入っています。以下はrakeコマンドのマニュアル(ターミナルで man rake を実行して見ることができます)からの抜粋です:

 Rake is a simple ruby(1) build program with capabilities similar to the regular make(1) command.

ここにあるように、rakeは、makeコマンドのような機能を実装したコマンドです。何かの手順を実行するタスクや各タスク間の依存関係を、Rakefileと呼ばれるタスク記述ファイルにあらかじめ記述しておくと、rakeコマンドを呼び出すことによって、各タスクを適切な順序で実行させることができるというものです。

rakeの最大の特徴(makeとの違い)は、タスク記述ファイル(Rakefile)の構文にあります。以下はRakefileのごく簡単な一例です:

--------------------------------------- Rakefile ---
task :default => :now

desc "時間を読み上げる"
task :now do
 t = Time.now.strftime('%H:%M')
 puts t
 sh "say #{t}"
end
----

いかがでしょうか？　タスクの説明や内容が読みやすく表現されていると思いませんか？　実はこれはRubyのプログラムそのものです。ここの task や desc は、rake によってRubyに導入された構文糖衣(あるいはDSL)なのです。この種の記述ファイルの表現にはXMLが用いられることが多い昨今ですが、人が読み書きするという観点から考えると、DSLを導入したRubyプログラムで表
現するという方法もなかなか良いと思いませんか？

上のRakefileをどこか適当な所(以下の例では /tmp)に保存して、ターミナルでそのディレクトリに移動すると、以下のようにrakeコマンドを実行することができます:

 $ cd /tmp
 $ rake -T                       # タスクの一覧を表示
 (in /private/tmp)
 rake now  # 時間を読み上げる    # 表示されたタスクの一覧
 $ rake                          # デフォルトのタスクを実行
 (in /private/tmp)
 12:49                           # 時間を読み上げる

◇ RubyCocoa の ib_action

もうひとつの実例として、RubyCocoa に含まれている構文糖衣 ib_action が導入されたときの流れを見ていくことにします。

Cocoaのアクションは、単なるObjective-Cのメソッドにすぎませんから、RubyCocoa ではもともと単なるメソッドとして定義すればよいものでした:

def buttonPressed(sender)
   # ボタンが押されたときの処理
 end

その後Leopardになって、Interface Builder と Xcode のバージョン3からは、ソースコードをパースして発見したアクションをnibファイルに自動的に反映するという機能が加わりました。しかし、上のようにアクションを単なるメソッドとして定義しただけでは、InterfaceBuilderは、どのメソッドがアクションなのか知る術がありません。そこで、ソースコード中にアクションの宣言に相当する記述が必要だということになり、アクションを宣言するためだけの構文糖衣が導入されました:

 def buttonPressed(sender)   # アクションの定義
   ...
 end
 ib_action :buttonPressed    # アクションの宣言

(注: アクションの宣言は、Interface Builderやその他の解析ツールなどに情報を与えるためだけに記述されていて、実行時には何もしません)

ここで、定義と宣言のために アクション名(buttonPressed) を2度重複して書くのは無駄だし、タイプミス(typo)によりバグの原因になることもあるかもしれません。そこで、構文糖衣ib_actionのブロック部にアクションメソッドの定義を書くことができるようにしました:

 # アクションの宣言と定義
 ib_action :buttonPressed do |sender|
   ...
 end

■ ブロック付きメソッドの定義

Rubyにおいて、疑似的な構文糖衣のその実体はメソッドの呼出ですから、Rakefile の task によるタスクの記述や RubyCocoa の ib_action によるアクションの宣言・定義も、実際にはメソッドの呼出ということになります。したがって、ブロック付き構文糖衣を導入するということは、ブロック付きメソッドを定義するということになります。

これまで、ブロック付きメソッドの使い方(呼び出し方)については何度も書いてきましたが、ブロック付きメソッドの定義方法についてはまだ触れていません。ということで次回に続きます。

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

　承前。1986年に成立した「労働者派遣法」によって派遣が可能になった「高度で専門的な知識や経験を要する」13職種というのの内訳は以下のようなものだった。

　ソフトウェア開発／事務用機器操作／通訳・翻訳・速記／秘書／ファイリング／調査／財務処理／取引文書作成／デモンストレーション／添乗／建設物清掃／建築設備運転・点検・整備／案内・受付・駐車場管理等。

　どっすか？　あなたの尺度でこれらの職種「高度で専門的な知識や経験を要する」と思いますか？　オレの極く個人的な印象を言わせていただけば、この中でそう思われるのは「通訳・翻訳・速記」、「財務処理」、「取引文書作成」、「建築設備運転・点検・整備」くらいである。……いやもちろん「ソフトウェア開発」も入れたいが、派遣ではない正社員でありながら、どう贔屓目
に見ても「高度で専門的な知識や経験」をお持ちとは思われないヒトをたっくさん知っているし、以下の議論をより客観的なものにするため敢えて外した。

　これらの職種の「専門性」というものを考えてみよう。

　たとえば通訳である。これがかなり専門的な仕事であることは誰にでも分かる。もちろん個々人を見ればピンキリで、かつてWWDCでセッションの日本語同時通訳をやってたヒトの中には画面に現れるアイテムとしての「Window」を全部「ウインドウズ」と訳したすっとこオヤジもいたし（自分がどんなイベントに呼ばれたのかくらい認識しろよ、と思ったな）、「Harddisk」を「堅い円盤」と言ってわれわれの失笑を買ったお姉さんもいたが、それでもあのスピードで喋り言葉を日本語に置き換えて行けるというのは「高度で専門的」なコトだと思う。

　あるいは速記。子供のころ欲しかった玩具に「スパイ大作戦手帳」（だっけ？）というのがあって、水に溶ける紙だの犬にしか聞こえない笛だの（あれはホンモノだったんだろうか？　ニセモノでもこっちにはわかんないわけだが）そうした怪しいアイテムの中のひとつに速記記号の表（何式だか知らない）があって、20分ほど練習して挫折した憶えがある。あれ実はちゃんとした速記士という資格があるのだが、テープレコーダ……いまはICレコーダだな、が普及した今となっては法廷と議会くらいしかハタラキ口がない。でも確かに「高度で専門的」な感じがする。

　財務処理……すぐ連想するのは簿記、会計士くらいか。取引文書作成ってのは行政書士？　公証人かしら？　建築設備運転・点検・整備ってのはつまりブルドーザーだのショベルカーだのクレーンだのを操作したりってことだよね。たまにどう考えてもまずいだろってな工事をやってクレーンぶったおしちゃうヒトもいるが、いや逆にいるようだからこそこれも「高度で専門的な知識や経験」を持ってるヒトでないと困る。

　でもさ、デモンストレーションってなんすか？　これ、どう考えても展示会のコンパニオンのことだろ。建設物清掃ってのはビル掃除のおばちゃんやないの？　案内・受付・駐車場管理等っていうのもそのタグイでしょ？　ちうか、駐車場管理なんてオレだって学生時代にバイトでやったことがありますがな。事務用機器操作ってのも怪しい。1986年当時を思うとこれ、たぶんキーパンチャーとかオペレータを想定してるんだと思うけど違うかな？

　そういうことを指摘したヒトがいたのかいなかったのか、1986年当時半分会社に寝泊まりするような感じで仕事をしていたオレにはさっぱり記憶がないのだが、いまになって見返せばこれ、つまりは「展示会のコンパニオン」とか「ビル掃除のおばちゃん」とか常雇いの正社員にするとコストが掛かりすぎる職種のニンゲンを派遣で済ませるために、実際には派遣会社なんかにマネージ
メントされなくても仕事が見つかる通訳とか会計士とかを混ぜ込んで「高度で専門的な知識や経験」という包装紙でくるんで見せたものだったんだとわかる。そうでしょ？

　で、もちろん問題はわれわれが属する「ソフトウェア開発」である。この職種はこの法律に「展示会のコンパニオン」側として入れられたのか「通訳や会計士」として入れられたのか、というハナシだ。そんなのわかりきってるぢゃないかって？　そりゃ今となれば前者であることは明白なように思われる。が、1986年という時期を考えると、施行時からそう考えられていたと断言できないフシがあるんだよね……。
（以下次回　2009_01_30）

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

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

　皆さんこんにちは、高橋真人です。
　さて前回、Mac以外の環境でプロとしてやってきた経験のある人の中から、特にWeb系のそれもスクリプト言語オンリーでやってきた人を取り上げて、これらの人々がiPhoneのプログラミングに取り組むにはどのようなアプローチがよいのか、という疑問を提示しました。
　今回はその延長線上で話を進めていこうと思いますが、同時に前回の冒頭に掲げた「今までプログラミングに触れたことがなかった人」に対しても参考になるような形でお話を続けていきたいと思います。

　さて、「スクリプト言語がプログラミング言語とどう違うのか」と聞かれてもよく分からない人もおいででしょう。前回は“ネイティブ系のプログラミング言語”という言い方でスクリプト言語と対比させてみましたが、そもそもこれらはいったい何なのでしょうか？

　プログラミングということを意識している人であれば、コンピューターがCPUという電子部品によって動いていることはご存知でしょう。CPUはCentral Processing Unitの略で、日本語では中央演算処理装置などと表現されたりします。要は、コンピューターが各種の処理を行うための中核部分ということになります。
　また、コンピューターの中ではすべてのものが数値で表されます。「コンピューター」というとよく「デジタル」という言葉が付いて回りますが、そもそもデジタルとはdigitという数字を意味する言葉から派生した語ですので、数値がすべてであるコンピューターにとってデジタルという言葉が付いて回るのは当然です。

　私が一般の方にコンピューターのことを説明していると「プログラミング言語でコンピューターって動くんでしょ？」とおっしゃる方は多くいます。もしかしたら、皆さんの中にもそう思っている方がおいでかもしれません。しかし、CPUが直接プログラミング言語を理解するのではないのです。CPUが理解できるのはあくまで数値だけなのです。

　細かくて申し訳ないのですが、ここでちょっとお断りを（笑）。
　CPUが理解するのは数字ではなく、数値です。以下にも「数値」と「数字」という言葉が頻繁に出てきますが、両者は意図的に使い分けられていますので、どうか違いを意識して読んでください。

　さて、「CPUは数字ではなく数値を理解する」ということは、つまりCPUは123456…という数字を直接理解できるわけではなく、あくまで電気的に表現された数値を受け取って動くということです。
　コンピューターの中では数値は2進数で表されます。0と1だけを使って数値を表すのが2進数です。分かりますか？　例を挙げます。私たちが日常使う10進数を2進数で表すと、55は110111となりますし、100は1100100となります。
　なぜ2進数なのかといいますと、今のコンピューターではこの形で数値を扱うしか、高速で精度を保った処理をこなせないからです。コンピューターの中では2進数は具体的には電圧の高低によって表現されたりします。
　余談ですが、「デジタルって何？」と問いかけると、「0と1でうんたらかんたら…」なんて答えられる方がいらっしゃいますが、これもこのCPUが2進法で数値を扱うというところからきているのだと思います。しかし、0と1に特別な意味があるわけではなく、コンピューターにとって数値は0と1でしか表せないというだけのことです。
　ですからCPUがいくら0と1で数値を表すからといっても、人間までがそれに合わせる必要はありません。0と1だけが延々と羅列されているとケタを読み違えたりしやすいですから、通常プログラマーは16進数というのを使います。「なぜ、いちばん馴染みのある10進数じゃないの？」と疑問に思われるかもしれませんが、コンピューターの2進数とやり取りするには16進数の方が都合が
よいのです。
　ごく簡単に説明しますと、2進数の4ケタ分が16進数の1ケタ分にピッタリと収まるのです。10進数だと端数が出てしまうために、どうしても収まりが悪いのです。具体例は省略します。ピンと来ない方はWebなどを検索してみてください。

　さて、「コンピューターには数値しか分からない」となると、改めて「プログラミング言語って何？」という疑問が湧いてくるかと思います。そこで、一般にプログラミング言語と言われるもの（ここにはスクリプト言語も入ります）を低レベルから高レベルまで順に見ていきます。低レベルや高レベルと言っても、頭がいいとか悪いという意味で使っているのではありません。
　プログラミングにおいては、低レベル言語（もしくは低級言語）や高レベル言語（高級言語）という言い方をしますが、これはCPUに近いものを低級、遠いものを高級と言っています。近いというのはつまり、人間がコンピューターに指示を与える際に、直接的に指示できるということです。逆に遠いという場合には、人間とコンピューターの間に仲介者（基本的にはソフトウエア）が何
段階かにわたって入ります。
　すぐあとで説明しますが、低級言語ですと人間が直接数値を使って命令しなければなりませんが、高級言語になると、かなり人間的な感覚で命令を記述できるようになります。語弊があるかもしれませんが、高級言語ほど人に優しいということが言えるでしょう。

　さて、CPUが直接理解できる数値による命令体系を「マシン語」または「機械語」と呼びます。低レベル言語の中でもこれはもっとも低い位置に属した言語です。「語」という文字が付いてはいますが、人間が見るとただの数字の羅列でしかありません。それをコンピューターに読み込ませる、つまり電気的な信号に変えて送り込むことによってCPUは動作します。

　マシン語からちょっとだけレベルが上がったものをアセンブリ言語と言います。マシン語が数字だけの羅列であったのから比べると、アセンブリ言語は記号めいてはいるものの、人間が見ると何らかの指示をするための文字の並びであることが見て取れます。先ほどレベルが上がると仲介者が増えると言いましたが、アセンブリ言語はそのままではCPUが理解できないので、一種の変換器
を使ってCPUが理解できるマシン語に変換をします。この変換器のことをアセンブラと言います。
　おおざっぱに言うと、アセンブリ言語は「マシン語を人間に分かりやすい表現に置き換えただけ」と言えますので、基本的には1対1の対応で変換をします。ですから、翻訳機というほどの凝った仕組みではありません。変換表を元に、単純に置き換えていくだけの作業でもありますから、量が多いのをいとわなければ人間が自分で（数値への）変換をすることも可能です。こういうのを
「ハンドアセンブル」と言います。

　さて、このアセンブリ言語の仕組みを多少知的にしたものがマクロアセンブラです。アセンブリ言語がマシン語に「そのまま」置き換わるのに対して、マクロアセンブラは少し人間に優しくなっています。
　例えば、特定のメモリ領域に名前を付けて変数という概念を表したり、特定のアドレス値にラベルを付けて、それをジャンプ（通常順に行われる処理が、特定の場所にジャンプする）する時の印にすることができたりします。

　以上が、低レベル言語と呼ばれるものです。
　次回は、もう少し上のレベルに上がっていきましょう。

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