2007-04-17
目次
「Wonderful Server Life」 第45回 田畑 英和
〜アカウント編〜
Mac Proのラインナップに8コアが追加されました。8コアの内訳ですが、4コアのCPUが2基搭載されています。オンラインのAppleStoreでは、8コアの構成を選択できますが、クロックは3.0GHzのみとなっています。
今のところXserveに動きはありませんが、はたして1Uの筐体にも8コア時代がやってくるのでしょうか?
◇グループフォルダ
さて、前回に引き続きグループアカウントを説明していきたいと思います。前回は複数のユーザ(あるいはグループ)をグループとして管理できることを説明しました。今回はグループアカウントの機能である、グループフォルダについて説明します。
各ユーザにホームフォルダが設定できるように、グループにもグループ専用のフォルダを設定することができます。このグループ専用のフォルダのことをグループフォルダと呼んでおり、グループ間でのファイルの共有などに利用することができます。
グループフォルダの設定方法ですが、「ワークグループマネージャ」を使って設定します。ツールバーから「アカウント」を選択し、左側のリストからグループフォルダを設定したいグループを選択します。次に、右側の画面で「グループフォルダ」ボタンをクリックし、ここでグループフォルダのパスを設定します。
「グループフォルダ」設定画面にはユーザの「ホーム」設定画面と同様に、あらかじめネットワークマウントの設定をしておいたパスが自動的に表示されます。つまり、グループフォルダはユーザのネットワークホームと同じように設定することになります。また、環境設定をおこなえばグループフォルダを自動的にクライアント上にマウントさせることもできます。
Mac OS X Serverには起動ボリュームの直下にあらかじめ「グループ」フォルダが用意されていますので、グループフォルダのパスとしては、こちらを利用するのがよいでしょう。
・グループフォルダのパスの設定
http://homepage.mac.com/htabata/MXS10.3/img/WGM_Group/WGM_Group_03.png
ホームフォルダのオーナーは、自動的にホームフォルダのユーザがオーナーとして設定されますが、グループフォルダのオーナーは自動的には設定されません。
そこで、グループフォルダのパスを設定した次に、グループフォルダのオーナーを設定します。「グループフォルダ」設定画面の下に、オーナーを設定するための「オーナー名」の入力フィールドがあります。
直接オーナーのユーザ名を直接入力することもできますが、タイプミスを防ぐために「…」ボタンからユーザリストを表示し、リストからドラッグ&ドロップして設定するのがよいでしょう。
◇グループフォルダの作成
ユーザのホームフォルダは「ワークグループマネージャ」から作成することができますが、グループフォルダの場合GUI上でこれを作成する方法がありません。そのためグループフォルダの作成はコマンドライン上で実行する必要があります。グループフォルダを作成するコマンドを、ユーザのホームフォルダを作成するコマンドと併せて紹介しておきます。
・ユーザのホームフォルダの作成コマンド
createhomedir
・グループフォルダの作成コマンド
CreateGroupFolder
CreateGroupFolderコマンドはroot権限で実行する必要があります。コマンドを実行すると、グループフォルダのパスに指定したフォルダ内に、グループの「名前」をフォルダ名とするグループフォルダが作成されます。
グループフォルダ内には自動的に「Documents」「Library」「Public」の3つのサブフォルダが作成され、それぞれのサブフォルダのオーナーおよびアクセス権はデフォルトで次のようになります。
・「Documents」フォルダ
オーナー:example
グループ:sample
アクセス権:rwxr-x—
・「Library」フォルダ
オーナー:example
グループ:sample
アクセス権:rwxr-x—
・「Public」フォルダ
オーナー:example
グループ:sample
アクセス権:rwxrwxr-x
「Documents」と「Library」フォルダには、デフォルトでグループの書き込み権がありません。
グループフォルダのフォルダ名は、デフォルトではグループの「名前」が使用されますが、これをカスタマイズすることもできます。グループフォルダのパスを複製し、「パス」を変更すればグループフォルダの名前を変更することができます。
・グループフォルダの「パス」の変更
http://homepage.mac.com/htabata/MXS10.3/img/WGM_Group/WGM_Group_04.png
それでは次回はコンピュータアカウントについて説明します。
つづく
小池邦人のCarbon API 徒然草(2007/04/13)
〜 Carbonモダンアプリケーションへの道(その14) 〜
今回からCarbonのファイルシステムについて解説します。こちらもテキストやグラフィックスに負けず劣らず、時代と共に変貌してきた経緯があります。はたしてファイルシステムは、どの程度モダン化されたのでしょうか?
ファイルシステムの話を始める前に、前回解説した印刷関連の内容に訂正があります。前回「CFArrayCreate()とPMSessionSetDocumentFormatGeneration()の手続きを加えないとCoreGraphics APIでの描画が印刷に反映されない」「Mac OS X 10.5では修正して欲しい」と書いたのですが、MOSAメンバの方からご連絡が有り、この「呪文」は、すでにMac OS 10.4で解消されていることが判明しました(笑)。ご連絡、有り難うございました。
具体的には、前回最後のサンプルの「呪文的」手続き箇所とPMSessionBeginDocument()をPMSessionBeginCGDocument()に置き換え、引き続
いてPMSessionGetGraphicsContext()をPMSessionGetCGGraphicsContext( )に
置き換えればOKとなります。すべてを正しく書き直すと以下の様になります。大変すっきりしましたね。ちなみに、両APIはヘッダファイルのPMApplication.hに定義されています。
OSErr startPrint( WindowRef window,PMPrintSession pss,
PMPrintSettings set,PMPageFormat form )
{
unsigned long i,st,ed;
short err=1;
CFStringRef cfstr;
CGContextRef ctx;
CopyWindowTitleAsCFString( window,&cfstr ); // ウィンドウタイトルを得る
PMSetJobNameCFString( set,cfstr ); // 印刷ジョブ名を設定
CFRelease( cfstr );
PMGetFirstPage( set,&st ); // 開始ページ番号
PMGetLastPage( set,&ed ); // 開終了ページ番号
if( ! PMSessionBeginCGDocument( pss,set,form ) ) // ドキュメント印刷開始
{
for( i=st;i<=ed;i++ )
{
if( ! PMSessionBeginPage( pss,form,NULL ) ) // 指定ページ印刷開始
{
PMSessionGetCGGraphicsContext( pss,&ctx ); // CGContextRefを得る
// ここでHIThemeDrawTextBox()などによるテキスト描画を行う
err=noErr;
PMSessionEndPage( pss ); // 指定ページ印刷終了
}
if( err )
break;
}
PMSessionEndDocument( pss ); // ドキュメント印刷終了
}
return( err );
}
ただし、PMSessionBeginCGDocument()とPMSessionGetCGGraphicsContext()
は、Mac OS X 10.4以降でしか使用できませんので、Mac OS X 10.3も動作環境対象となっているアプリケーションでは、前回のソースコードを使うしか手はありません。御注意ください。また試した結果、SetPortTextFont()やSetPortTextSize()など、CGrafPortの参照が必要な描画関連APIは、引数のCGrafPtrにNULLを渡せば正常に動作するようです。
ところで、PMSessionGetCGGraphicsContext()でCGContextRefを得てCoreGraphics APIで描画を行う場合、用紙矩形領域の左下が原点(PostScript同等)となります。通常プリンタの印刷可能形領域は用紙矩形領域よりも狭いですので、原点付近に描画した文字や画像は途切れてしまう可能性があり、注意が必要です。
これとは異なり、QuickDraw環境では用紙矩形領域ではなく印刷可能領域の左上が原点となります。用紙矩形領域をPMGetAdjustedPageRect()で得て、その矩形を考慮して描画すれば、ちゃんと用紙内に印刷結果を納めることができます。CoreGraphics環境では、描画する前に、用紙矩形領域の原点まで座標系を平行移動させておくと便利かもしれません。
話をファイルシステムに戻しましょう。ファイルシステムを考える上で、まず最初に確認しておくべきことは、ファイルを参照するための「リファレンス」に何を使うかと言う事です。Mac OS 9の時代であればFSSpec構造体(今でも使えるが...)がそれに相当していましたが、現在ではFSRef構造体を使うことが強く推奨されています。
ヘッダファイルのFiles.hを参照すると、FSSpec構造体は以下の様な構造体メンバを持っていることが分かります。
struct FSSpec {
short vRefNum; // ボリュームリファレンス番号
long parID; // ディレクトリ番号
StrFileName name; // ファイル名
};
このうちStrFileNameはStr63と同一で、具体的にはStr63[64]と定義されていますから、ファイル名は63バイト以内でしか管理できません。またファイル名のエンコーディングはShift-JISに固定されておりユニコード文字列の扱いも不可です。続いて、FSRef構造体の方を調べてみると、以下のように定義されています。
struct FSRef {
UInt8 hidden[80]; // 中身がどう使われるかは謎?
};
構造体サイズが80バイトであることは理解できますが、その中身がどのように利用されているのかはオープンにされていません。
現在、FSSpec構造体を引数で渡すファイルアクセス関連APIは、すべてDEPRECATED指定となっています。例えば、ファイル作成に使うFSpCreate()や削除に使うFSpDelete()などもそのうちの一つです。ただし、古いアプリケーションの特定の便宜を図るために、FSSpec構造体をFSRef構造体へコンバートするFSpMakeFSRef()などの一部のAPIは、DEPRECATED指定にはなっておらず、そのまま継続して使用することが可能です。
extern OSErr FSpMakeFSRef(const FSSpec *source, FSRef *newRef)
File.hに定義されているファイルシステム関連のAPIでなくても、FSSpec構造体でファイルを参照するAPIはDEPRECATED指定のものが多いので注意してください。そうしたAPIについては、FSRefで参照する代用APIが必ず存在しています。例えば、Folder.hにはシステムで管理しているフォルダを探し出すAPIが定義されていますが、一昔前にはFindFolder()を利用していました。
OSErr FindFolder(
short vRefNum, // ボリュームリファレンス番号
OSType folderType, // フォルダの種類
Boolean createFolder, // 無い場合に作成するかどうか
short * foundVRefNum, // 得られたフォルダのボリュームリファレンス番号
long * foundDirID); // 得られたフォルダのディレクトリ番号
このAPI、FSSpec構造体を渡す必要はないのでDEPRECATED指定にはならず生き残っていますが、代わりとしてFSRef対応のFSFindFolder()というAPIがちゃんと存在しています。
OSErr FSFindFolder(
short vRefNum, // ボリュームリファレンス番号
OSType folderType, // フォルダの種類
Boolean createFolder, // 無い場合に作成するかどうか
FSRef * foundRef) // 得られたフォルダのFSRef
例えば、システム起動ボリュームにあるデスクトップフォルダのFSRefを得たい場合には、以下のように記述してやればOKです。
FSRef fsref;
FSFindFolder( kOnSystemDisk,kDesktopFolderType,kCreateFolder,&fsref );
CoreFoundation中には、特定のファイルやフォルダを参照するために、FSRefではなくてCFURLRefを用いるAPIがあります。例えば、アプリケーションバンドルのResourcesフォルダ内にアクセスするためにはCFBundleCopyResourceURL()を利用しますが、このAPIはファイル参照用としてCFURLRefを返してきます。しかし、CFURLRefのままだとファイルアクセスが面倒ですので、CFURLRefをFSRefに変換するCFURLGetFSRef()というAPIがCFBundle.hに用意されています。CFStringRefで名称を指定したResourcesフォルダ内ファイルのFSRefを得るには、以下の様に処理します。
CFStringRef cfstr; //ファイル名を代入する
short err=1;
CFURLRef url;
if( url=CFBundleCopyResourceURL( CFBundleGetMainBundle(),cfstr,NULL,NULL ) )
{
if( CFURLGetFSRef( url,fsref )==true ) // CFURLRefをFSRefに変換
err=noErr;
CFRelease( url );
}
CFRelease( cfstr );
次回は、FSRefで参照したファイルやフォルダ(ディレクトリ)への基本的なアクセス(作成、書き込み、読み込み、削除など)について調べてみたいと思います。
つづく
SqueakではじめるSmalltalk入門 最終回 鷲見 正人
前回はSmalltalkファンお手製の、OS Xで動くフリーのSmalltalk処理系をご紹介しました。今回は、一連のSmalltalk処理系のご紹介の締めくくりとして、Squeakの前身であるApple Smalltalkを取り上げます。
▼Apple Smalltalkとは
「Apple Smalltalk」は、もともと、Smalltalkシステムの売り込みに熱心だったXEROXからの技術供与と動作確認用の(純正の)仮想イメージの提供を受けて、AppleがLisa向けに開発したSmalltalk処理系です。のちにMacintoshにも移植され、旧APDA(the Apple Programmers and Developers Association)を通じて比較的安価に販売されました。残念ながら、現在は入手がたいへん困難となっていますが、1990年前半くらいまでは販売されていたので、ベテランMac開発者の皆さんの中にはインストールディスクやインストール後のフォルダを記念にとってあるよ!という方もおられるかもしれませんね。
Apple Smalltalkは非常に古いソフトですが、「Mini vMac」というMacintoshPlusエミュレータを使えば、OS Xでも制限付きながら(環境内でのファイルのアクセスに失敗する…)も、かろうじて動作させることは可能です。なおその際には、Apple Smalltalkとエミュレータソフトの他に、Macintosh PlusのROMイメージと古いMacintosh System(6.0.x未満)が必要になります。
http://minivmac.sourceforge.net/
[fig.A]Mini vMacで動作しているApple Smalltalk
▼オリジナルMacのGUIの“ルーツ”としてのSmalltalk GUIを試す
エミュレータを動作させるために使う“古い”Mac用のシステムと、起動したApple Smalltalkとの比較で一目瞭然ですが、左上を指し示す矢印のポインタ、グレイ(細かな市松模様)のデスクトップ、白地に黒の文字表示など…に象徴されるように、両者はたいへんよく似かよった部分を持っています。知らない人が見たら、SmalltalkとやらはMacのソフトっぽく見えるように、実にうまくしつらえられているのだな…と本来とは逆のことを考えてしまうかもしれませんね。
[fig.B]両者間で似た部分のあるGUI要素
当時のSmalltalkのウインドウは、見た目がとてもシンプルであったり、スクロールバーがポップアップでしかも左側に付いていたり…と、いっけんLisaやMacのGUIとはずいぶんと違った印象ではありますが、しかし、作業場としてのウインドウが持つべき要素(オーバーラップ、タイトル表示、移動、サイズ変更、スクロール機能…)は、実はまぎれもなく、このSmalltalkのGUIが元になってそれが広まって定着したものです。たとえば、第三ボタンメニュー(Apple Smalltalkではコマンドクリック、あるいはタイトルバーをクリックしてポップアップ)の項目やスクロールバー操作は、次のように対応付けできます。
第三ボタンメニューの項目 → Lisa、Macのウインドウ操作
---------------------------------------------------------
move → タイトルバーの移動
frame → サイズボックスのドラッグ
collapse → (後の)ウインドウシェード機能
close → クロースボタンのクリック
スクロールパネルの操作 → Lisa、Macのスクロールバー操作
-------------------------------------------------------------
ボックスのドラッグ → 同じ
ボックス左側のクリック → 上矢印ボタン(上方向スクロール)
ボックス右側のクリック → 下矢印ボタン(下方向スクロール)
また、マルチフォントやカット&ペーストに象徴されるモードレスな文書編集スタイルについても、Smalltalkが手本になっています。前述のウインドウの場合と違って、当時としては珍しい個性的なテキスト操作スタイルのほうは、ほぼそのままLisaやMac(ひいてはWin…)に受け継がれています。したがって、Macに慣れた皆さんは、ほとんど説明無しで、この1970年代に培われたGUI上でのテキスト編集機能をさほど違和感を感じずに使いこなせるはずです。ただしメニューバーはないので、第二ボタンメニュー(Apple Smalltalkではoptionクリックか、スクロールバー右端領域をクリック)を用いる必要があります。
[fig.C]両システムで酷似しているテキストの編集スタイル
他方で、後にAppleによって発明されることになる“新機能”が欠けていることにも気づかれることと思います。横方向のスクロールバー(あるいは、サイズボックスを含むスクロールバーの再配置のアイデア)、前述のメニューバーや(ポップアップではない…)プルダウンメニュー、さらには、Smalltalkでは必要とされなかった「Finder」(Smalltalkではファイルを読み込んで実行したり文書をファイルとして保存するのではなく、すべてをオブジェクトとして仮想デバイスに押し込めるスタイルのため…)や、「計算機」(Smalltalkではたとえワープロの文書中であってもSmalltalk式をprint itできるため…)といった機能やソフトウエアたち。これらは、Apple Smalltalkには見ら
れません。
[fig.D] Smalltalkの“print it” vs. Macの“計算機”
以上のようにApple Smalltalkは、たんに古いSmalltalk処理系のひとつというだけでなく、我らがMacのGUIが「どこから来たのか?」といったことに思いを馳せたり、Appleが何をそこにどのように付け足したのか?を再確認する目的でも、たいへん興味深いソフトだと思います。相応の知識を持っていれば、1979年にPARCを訪れ、ALTO上のSmalltalk GUIを見て驚いたスティーブ・ジョブズよろしく、「こんなものが1970年代半ばにすでに出来上がっていたとは!」と感動すること請け合いです。
▼Squeakの“前身”としてのApple Smalltalkと、Squeakの“今”
Squeakは、このApple Smalltalkから、移植の妨げになるMacintosh ToolboxやMC68000依存部分を排除しするために、Smalltalkで仮想マシンの主要部分を記述して新しい仮想マシンを作り、その仮想マシン上で古い仮想イメージ(Smalltalk自身で書かれたSmalltalkシステム本体)を拡張する…というサイクルを経て作られました。まるで不死鳥が自らの身を焼いて、新しく生まれ変わるかのようなエピソードですね。
もちろんApple Smalltalk内で動作するSmalltalkで記述された仮想マシンは、動作確認やデバッグ程度のことは可能ですが実用(仮想イメージ開発)には向かないので、それをいったんC言語に変換して、必要なリソースを追加してMacintosh用開発ツールでビルドする…という作業も必要でした。この変換作業には、アラン・ケイたちがPARC時代、C言語の前身のBCPLにSmalltalkを変換するソフトを(やはりSmalltalkで)書いたときのノウハウが活かされていたのだそうです。
Squeakは、そうして、高い移植性を自らの特徴とし(実際、Mac以外の数多くのプラットフォームに移植されました)、同時に、ALTOやLisa、初期のMac時代には望めなかったカラー表示や広大なメモリ空間への対応を果たします。さらに、本来の目的であった子供向けのビジュアルプログラミング環境「eToys」をはじめ、仮想三次元空間の共有機能を提供する「Croquet」、Rubyon Railsの対抗馬(?)で継続ベースのWebアプリ「Seaside」、CocoaのKVOライクな機構を有する次世代GUIフレームワーク「Tweak」など、さまざまな新旧の技術を取り込みつつ、今も多様な進化を遂げているところです。
* eToys
http://squeakland.jp/school/drive_a_car/html/Drivecar12.html
* Croquet
http://www.croquetconsortium.org/index.php/Screenshots
* Seaside
http://www.seaside.st/
* Tweak
http://tweakproject.org/TECHNOLOGY/Tutorials/BankAccountTutorial/
さて。突然ですが今回をもって本連載はおしまいとさせていただきます。皆さんが、様々な意味でMacとは切っても切れない関係にあるSmalltalkに興味を持たれた際に、本連載での情報が何かしらの役に立つことがあれば幸いに思います。長い間、ありがごうございました。
バックナンバー:
http://squab.no-ip.com:8080/mosaren/
書籍紹介 Ship It! ソフトウェアプロジェクト成功のための達人式ガイドブック
解説担当:高橋政明
Ship It! ソフトウェアプロジェクト成功のための達人式ガイドブック
Jared Richardson・William Gwaltney Jr. 共著でびあんぐる 監訳
オーム社 ISBN 4-274-06656-8 2,730円(本体2,600円+税)
今回ご紹介するのは昨年発売された長い書名の本です。「レガシーコードをサポートしなければならない」「修正したはずの機能の不具合が何度も再発する」「コードを統合することに苦痛を感じる」「機能の追加を頻繁に要求される」「いつまでたっても作業が終わらない」これらの項目に一つでも当てはまるならば、この本は『読む価値あり』です。ほかにも具体的な項目が並んでいます。(第5章 一般的によく見られる問題とその解決方
法)
具体的な内容と平易な文章でどんどん読み進めることのできる本です。作業の優先度や悪い兆候としての警告サインなど、漠然と認識していた事柄が上司やクライアントを説得できる明確なリストとして載っています。
新しい本なので紹介されているツールなども最新です。入手するためのURLももちろん載っています。
42のヒント、コラムそれにおすすめの本と参考文献も大いに役立つと思います。
残念ながら本書の内容はチームでの開発向けのため個人で開発している場合には採用できないものも少なくありません。しかし個人であっても工夫は可能です。「どこから着手するか」「そのやり方は正しいか?」「警告サイン」など具体的に書かれているので自分の場合どうしたら良いのかが見えてくるのです。もちろん個人でも有用な情報も沢山あります。
「本書の読み進め方」の項にあるように、開発者やテスター、プロジェクトチームのリーダー、管理者(または製品に関与している顧客)それぞれに役立ち完成(つまり出荷)に導いてくれるはずです。
前向きな気分にさせてくれる本です。もしまだ読んでいなければ五月の連休におすすめの一冊です。(ハムを料理するとき、いつもハムを切り、最初に3分の1を捨てていた女性の話をご存知ですか? この話の顛末を知りたければこの本をお読みください〔^_^;〕)
▼出版社のweb (詳しい目次が載っています)
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-274-06656-8
◇MOSAからのお知らせと編集後記は割愛します◇