Movable Type

mt.psgiを使うと展開が早い! その2

2013年 02月 20日 00:52 | カテゴリー: Movable Type
2013年 02月 20日 00:52
Movable Type

最後にサーバーへの設定

本家Six Apartさんの公開しているマニュアル「PSGI Plack環境でMovable Typeを動かすで、わかったことが、最後にサーバーへの設定が必要だそうです。このページの一番下に、「PIDFilePath 環境変数」というのがあって、これを設定しなくてはなりません。

PIDFileって何?というのが僕、です。ちょいと調べて、OSが動作を管理するために、その動作にID番号を振って、その番号を記録するファイルだそうです。上記記事にあるように、3つの動作時に再起動をするそうで、そのときに作られるファイルのようです。ふむふむ。

試しにFFFTPでサーバー内のありかを覗いてみると...pidファイル、ありません(汗)。ローカルにも本サーバーにもありません。次のタイミングにできるんでしょう、きっと。ということでそのファイルのありかをMTに知らせなくてはならないらしいので、mt-config.cgiの中にパスを記入します。それと(わからないなりに)StarmanというPerlモジュールを使用前提らしいので、こいつにもパスを通すようにします。Starmanは前述の「Task::Plack」をインストールしたら一括して入るようです。

1、2行目は良いですね。1行目は「mt-config.cgiに書くんだよ」という指示です。だから1行目は書く必要はありません。2行目は、そのまま記述します。

そして3行目もコメントアウトされた指示ですから無視、または明示的にコメントアウトのまま書いておいてもよいでしょう。で、4行目。ここでまた疑問。初心者なりに、

$ starman --pid /var/run/mt.pid ./mt.psgi

この記述の最後は、mt.psgiへの相対パスになっているので、これ、ちゃんと置いてあるディレクトリを指示しなくてはならないのでは?と思うわけです。SEの方なら理解できて普通のことも、わからないときはこんなところで躓きます。どこにも書いてないので困り果て、ここは前述で指定したディレクトリ(実際にmt.psgiがあるところ)で絶対パスにしておきました。

$ starman --pid /var/run/mt.pid /var/www/cgi_bin/mt/mt.psgi

まあ、今はPIDFileがないので(汗)、何とかなるだろうと、理解がないままやってしまいます。

 

曖昧な日本語とシンプルな英語

わからないときにやるのが本家の英語との見比べです。内容を理解するために原文を読むことはテクニカルライティングの世界では当たり前なのです。同じ記事の英語版(原文)が「En dev bootstrap mt psgiで公開されているのですが、まったくの翻訳ではなく、日本語ではわかりやすく書き直しているようです。ですが、曖昧で複数の意味を持つ日本語は余計な混乱を招きます。

“この動作を実現するため、PSGIサーバーでpidの指定を行って保存先を指定し、かつ、mt-config.cgiにも同ファイルへのパスを追記してください。”

この日本語は英語のどこにも書かれていません(原文は下にあります)。一番困ったのは「かつ、」の使い方です。ここでいう「かつ、」は「2つの事柄を平行して行う」という意味ですから、「保存先の指定」と「パスの追記」が必要と解釈できます。なので、必要な作業として、

  • (僕のところではpidファイルがないので)mt.pidを作成して“/var/run/”に置いて(保存先の指定?)、なおかつ、mt-config.cgiにパスの追記をする
  • pidファイルのパス(PIDFilePath)と、PSGIサーバーからのmt.pidのパス(Starmanの方)の2行(保存先の指定とパスの追記)をmt-config.cgiに書き込む

と2つの意味に取れるわけです。ですから、前者の「保存先の指定」はどうやるの?mt-config.cgiへの追記は1行だけで良いの?違うの?と、混乱するのです。この時点でおおむね、後者かな?とは思いますが、イレギュラーなことが一つあると僕には判断できないわけで、テクニカルライティングの難しいところです。特に英文が先にある場合、意訳はかまいませんが、こうした別の意味や2つ以上の解釈を持つような意訳はライティングとして「だめ出し」なのです。ですから今回は英文を主として、「後者が正しい」と判断しました。

ちなみに英語の直訳は、

This is done by using PID files, usually stored (on *nix systems) in /var/run. So here is how we tell Starman where to his pid file, and MT where to find it:

これは、通常(*nix systemsにおいて)/var/run内に保存されたPIDファイルが使用されます。ここから、Starmanはpidファイルがどこかを伝えて、MTはそれを見つけます。

こんな感じです(上の英文は引用、下が私の翻訳です。適当で済みません)。文章の最後にコロンでファイルへの記述につながっているので、後者と判断できます。ならばやることはシンプルで、2行をmt-config.cgiに書くだけです。無理に説明しようとするから重複解釈で物事を難しくして、ユーザーを混乱させるわけです。テクニカルライティングでは、説明と手順は区別して書かなくてはならないのです。

 

初心者からのお願い

前述の記事のように、MTに関して名の通った(もちろんこれだけではありませんが)、先人の方達の記事は、とてもタメになります。しかし、僕のようなノンプログラマーな1ユーザーは、その様々なやり方に、どれが一番適しているのか、どうやれば確実なのか、エラーが出ずに仕上がるのかなど、全く区別がつかないわけです。もちろん、勉強のために本は何冊も買っています。でもエラー時の対処は全くと言っていいほどわかりません。

でも、便利にしたいのは同じなわけで、勉強といえばそれまでですが、Try & Errorしかないのです。それでも、何度もぶっ壊してはインストールし直しという事態は避けたいので、欲を言うならば、せっかく記事にしていただけるなら、もう少しわかりやすく、丁寧に書いていただけると敷居も下がってユーザーが増えるというモノです。これはマニュアル作りに従事した経験則で、テクニカルライティングというところを、もう少し意識して欲しいと思うわけです。

できれば、内容の解説はある程度で良いのですが、少なくとも手順は正確に書いて欲しいと願ってやみません。「これでわからないならやめろ」といわれてもしょうがないことかも知れませんが、名の通った先人の方々なら、影響力も多大ですので、ここら辺にもう少し気を配って欲しいモノです(決して文句言っているわけではありません。お忙しい中での記事のライティングが大変なのは、僕もわかりますので...)。

テクニカルライティングで難しいのは「技術者の陥りやすい罠」です。自分が知っていることを通常(または普通)と思って専門用語や省略された手順などを書いてしまい、自分は満足しても初心者には伝わらないということが、ままあります。書いている方はいつものことですので、気がつきにくいのです。大手メーカーではその差を埋めるために、専属のマニュアルチーム(部署)を作っています。今や海外では「マニュアルに書かれていない」というだけで、問題が起きれば訴訟問題までに発展します。特にマニュアルとなれば、全く知らない人でも動かせるようにまで持って行かないとマニュアルの役目が成り立たないのです。

ブログ記事などは、マニュアルではありませんが、この情報化時代には初心者にとってマニュアル以上に重要化しているということに気がついて欲しいのです。特に本家のSix Apartさんにはマニュアルを何とかして欲しいです。タグリファレンスなど、説明になっていないタグが結構あります。本当に広げていきたいのなら、この辺を丁寧にしておくことがユーザーの敷居を下げ、シェアを広げられる一つの要因でもあります。現に僕がある企業の市販アプリケーションのマニュアルを作り直して、それまで年間5000本も売れていなかったアプリを半年で4万本以上売り上げたということをメーカーからフィードバックされました実績があります。その原因は当時のフォーラム(今で言うSNS)でそのマニュアルの改訂が話題になり口コミで広がったそうです。底辺の方を広げることで、たとえピラミッドでも、上も広がるのは目に見えていることです。

僕を含めた初心者は、テクニカルなことを知っている方にとってみれば、思わぬところで躓くモノです。そこら辺がカバーできると、よりすばらしい記事になると思います。

 

最後に

サーバーの再起動後は、いつもと変わらずに使っていますが、やっぱり早いです。でもこれもマシンパワーと一緒ですぐに慣れちゃうのと同時に、戻れなくなるんでしょう、きっと。動作可能なサーバーであればお勧めしたい新機能です。

Six Apartさんには、前述を一例としてマニュアルの言葉足らずの部分や、勘違いしやすいところはちゃんと直しておいて欲しいです。