2009年7月アーカイブ

Data::Modelでのリレーション(1)で、Data::Modelに大きくて重い皮を被せたので自縄自縛に陥ってしまったと書きました。一方でArkサンプルアプリケーション「SimpleLinks」では、規模がFF14総合ウェブアプリケーション「Amikeco」とは段違いに小さいこともあって、比較的見通しがよいスキーマが書けたように思います。Data::Modelサンプルアプリケーションとしてもご覧いただけるかも知れません。

• SimpleLinks::Schema::Table

例えばmany_to_manyを例に取ると、websiteが所属するcategoryの一覧は$website_row->categoriesで得られますし、その反対も$category_row->websitesで得られます。使う場合にのみリレーションを取り扱うので、不必要に遅くなることもありません。

ただ、つまるところは手動でやっている作業をスキーマに押し込めただけなので、きちんとしたリレーションになっているわけではありません。実際には$model->set(website => { ... });などと生で触ることをせず、mix-inしたクラスか、より好ましくは呼び出し元であるAPIクラス（SimpleLinks::Service::Links）でadd_websiteという皮を用意して、リンクエンティティ（website_categoryなど）を同時にupdateするということになりそうです。

やろうと思えば何とかhas_a, has_one, might_have, has_many, many_to_manyなどのリレーションを使えるので、リレーションが現段階でサポートされていないからといってData::Modelを使わないという食わず嫌いは勿体ないと思います。

なお、add_method関数がcallerを使ってメソッドを生やす先の行オブジェクトを探しているので、モデルがadd_methodの一大巨編になりがちなのが少し気に掛かります。最近とみにそのカオス具合が増している画面遷移図もどき（カオスっぷりを笑うために、第3弾を近々上げておきます）ほどの規模になると、流石に1スキーマクラスで何でもやろうとすると見通しが悪くなりかねないと思うのです。

......というようなことをサンプルアプリシリーズとは別個にエントリを立てて述べるのは、ひとえにシリーズの中に占めるModelネタが大きくなり過ぎて右往左往していることに他なりません。以上、見通しの甘さに定評のあるgardejoの提供でお送りしました。

色々ありましたが、取り敢えずXREA（共有サーバー）に於ける非root（ユーザー権限）でのArkのインストールと、簡単な稼働実験が出来ました。Coreserverも互換があるので、そちらも行けるはずです。

• http://eorzea.asia/links/script/simplelinks.cgi

これは、下記の状態のArkサンプルアプリケーションをCGIで稼働したものです（SimpleLinks::Web::Controller::Rootにあるindexアクションの結果です）。そういえばIEはtext/plainが鬼門でしたが、実験アクションなのでtext/htmlにしてpre要素で括る手間は省かせていただきました（上記URLの実験結果の確認にはFirefoxやChromeなどをお使いください）。

SimpleLinks

サンプルアプリケーション一式です（今回コミット分）。{MyApp}/libに配備します。今回は~/app/p5-ark-sample-simplelinks/libとしました。このアプリについては別シリーズとしてエントリを設けています。

Faktro

ラッパークラス群です（今回コミット分）。local::libと一緒に{MyApp}/extlibに配備します。今回は~/app/p5-ark-sample-simplelinks/extlibとしました。

ArkやData::Model、それに依存モジュールの山は、~/local以下のローカルライブラリに配備します（~/local/lib/perl5）。

ディスパッチテーブルも作っています（ただしCGIなのでキャッシュを使っています）し、ミルフィーユのような多階層オブジェクト抽象化の洗礼も受けていますし、SQLiteでDBを読んでもいますが、0.5～1.5秒程度でレスポンスを得られます（ADSL 8Mbps, Firefox 3.5.1でのend-to-endタイム）。

このように、ArkとData::Modelのタッグは、CatalystとDBIx::Classのタッグよりも極めて軽快に動作することが解ります。現段階のサンプルアプリは（開発の端緒であることもあって）テンプレートエンジンは未使用ですが、Text::MidroTemplate, Text::MicroTemplate::Extendedを使う場合には、レスポンスへの影響はほとんど無視出来る見込みです。

ただ、今回は思い切り手動作業で乗り切ってしまったので、スマートな作業記録にはなっていないのが惜しまれるところです。インストールの詳細については後で記事にまとめますが、要点は以下の通りです。

一連のArkサンプルアプリケーションネタは、作りながら記事を書くということをしています。その一環として、勇んでArkのサンプルアプリをデプロイしようと思いましたが、CPANのmetadataだけで12MB程度を食ってディスク容量不足に悩まされたので、広告付き無料アカウントでのArkのインストールは断念しました。

いやはや、流石に生のXREAでは厳しすぎました。ローカルで同じ構成のLinuxマシンを立ててライブラリだけ同期を取ればどうにかなるのかも知れませんが、あまりやせ我慢をしても仕方がないので、さっくりとXREA plusにしました。3GBもあれば、画像・音楽・映像を扱うようなサイトでもなければ、使い尽くすことはまずないでしょう。しかも広告も取り外せますし、MySQL DBが5個まで持てるようになりましたし、cronも使えるようになりましたし......と自らを納得させていますが、そこはかとなく漂う敗北感は如何ともし難いものがあります。

閑話休題、そんなこんなでXREA/Coreserverでlocal::libを使う方法などをご紹介します。perl自体をオレオレディレクトリに入れる方法（ただしActivePerl）は既にご紹介していますが、今回はあくまでperl（処理系）はいつもと一緒（s345.xrea.comの場合には/usr/local/bin/perlにある5.8.8）として、local::libによるオレオレライブラリを設ける方法です。オレオレライブラリにFTPでアップロードしつつスクリプトでuse libする手もありますが、依存が多いモジュールを入れる際には、CPANシェルで入れてしまった方がよいので、大変お勧めです。

追記：Arkのインストールの際に気が付いたのですが、直近で記事を設けるのは厳しそうなので、取り急ぎここに追記します。上記のみだと、Module::Buildを使用する場合に問題が起きます。泥臭い対処法はlook MODULEしてしまうことですが、ちゃんとModule::Buildのマニュアルを読んでから、採るべき対処法を添えて別記事にてフォローする予定です。

Arkのサンプルアプリケーション開発の第4回は、いわゆるscaffold、雛形作成です。

MyApp名をSimpleLinks::Webとして、デフォルトページの表示が行えるところまで行ってみましょう。

この辺りは、私のようなぺーぺーのブログ記事なんかよりも、開発者のtypesterさん（村瀬さん）ご本人による記事、"ついに出た！最新Perlフレームワーク「Ark」徹底解剖　第2回　Ark チュートリアル：基礎編"をご覧いただいた方が遙かに良いと思いますが、MyApp::WebのようなMyApp名を指定した際の留意点や、Windows環境（Strawberry Perl）での留意点なども簡単に補記しています。

Arkのサンプルアプリケーション開発の第3回は、詳細設計です。

Webアプリケーションはその構成要素が決まっているようなもので、今回のような簡単なアプリケーションの場合、使用言語や使用モジュールを決めたら、後はデータ項目を決めるくらいで十分です。

以下に、それらを簡単に紹介します。

Arkのサンプルアプリケーション開発の第2回は、外部設計です。

これもまた要件定義と同様、自家発電アプリであれば大枠だけ頭の中に描いて、いきなりプロトタイプを作る方が早いのですが、思考を可視化するということでラフスケッチのようなものを掲げてみます。

FFXIVの一次情報が目下のところ少ないながらも、それらを独自の視点を交えて紹介したり、各種の機能別サイトの萌芽（このサイトもその一つであるつもりです）が見えたりしています。ということでそうした関連サイトへのリンク集のページを作っています。

そして、じきにそうしたサイトが増えるであろう事は自明なので、Arkのサンプルアプリケーションとしてリンク集を作りつつ、GitHubで公開しようと思います。

1. Arkによるリンク集サンプルアプリケーション(1) 企画～要件定義編
2. Arkによるリンク集サンプルアプリケーション(2) 外部設計編
3. Arkによるリンク集サンプルアプリケーション(3) 詳細設計編
4. Arkによるリンク集サンプルアプリケーション(4) Scaffold（雛形作成）編
5. Arkによるリンク集サンプルアプリケーション(5) Model（モデル）編
6. Arkによるリンク集サンプルアプリケーション(6) View（ビュー）編
7. Arkによるリンク集サンプルアプリケーション(7) Controller（コントローラー）編

基本的には「自分が作りたいから作った」という、車輪の再発明的なものです。ただ、作るからにはちゃんとした最近の作法で作りたいものですし、作る経緯なども紹介してみたいという気持ちもあります。Catalystの例は色々ありますが、Arkの例はまだ少ないので、その意味でも一つの参考になればいいなと思います。

ということで、第1回目は企画と要件定義です。

MT4の組み込みCAPTCHAが働いていませんでした。完全に確認漏れです。申し訳ありません。

障害報告内容と対応の詳細は、以下の通りです。

HTML::FormFuや、現在開発中のアプリケーションで使わせていただいているHTML:Shakanなどのフォームクリエーター＆バリデーターモジュールはとても有用です。もっと早く使えば良かったです。

有用ついでに感心したのが、アプリケーションをよりセキュアに出来るというおまけです。おまけというよりも仕様なのですが、$c->req->paramsを生で使わずに$form->paramsを使うことによって、フォームで定義していないパラメーターを食べなくて済むことが、細かいことですが嬉しい点です。

何にそんなに感激したかという具体的な話は以下の通りです。まあ上記の話を一歩も出るものではありませんが。

例えばRESTfulなディスパッチテーブルとして、以下のようなものがあるとします。

GET /avatar

全サーバーのプレイヤーキャラクターの一覧表示。avatarsの方がLISTっぽいですが。

POST /avatar

プレイヤーキャラクターの新規作成。$c->req->paramsがなければ新規作成画面で、あれば処理終了後、/avatar/{world}/{forename}に転送。

GET /avatar/{world}

{world}サーバーのプレイヤーキャラクターの一覧表示。これもavatarsの方がLISTっぽいですが。

GET /avatar/{world}/{forename}

プレイヤーキャラクターの単独表示（兼、編集＆新規作成完了画面）。

PUT /avatar/{world}/{forename}

プレイヤーキャラクターの編集。$c->req->paramsがなければ編集画面で、あれば処理実行後、/avatar/{world}/{forename}に転送。

DELETE /avatar/{world}/{forename}

プレイヤーキャラクターの削除。$c->req->paramsがなければ削除確認画面で、あれば処理実行後、/avatarに転送。

なるほど、綺麗ですね。ところが、肝心のPOST, PUT, DELETEメソッドを、どのように発行してもらいましょうか。

一つの考えはこうです（Data::Localizeによるローカライズ後の出力結果の例です）。

<ul>
<li><form method="put" action="http://localhost:4423/avatar/bahamut/foo/">
    <p><input type="submit" value="編集" /></p>
</form></li>
<li><form method="delete" action="http://localhost:4423/avatar/bahamut/foo/">
    <p><input type="submit" value="削除" /></p>
</form></li>
<li><form method="post" action="http://localhost:4423/avatar/">
    <p><input type="submit" value="新規作成" /></p>
</form></li>
</ul>

こんなところでしょうか。しかし、HTML4やXHTML1ではform要素のmethod属性にはgetかpostしか使えないんですねえ。今更ながらですが。

また、formはまどろっこしいという悩みもあります。普通のa要素（アンカー。いわゆるリンク）はインライン要素ですが、formはインライン要素とはいえ子としてブロック要素しか持てないので、記述が増えてしまって面倒です。

例えば目下開発中のこのアプリケーションでは、言語を英語・日本語・独語・仏語・エスペラントから選べるようにしていますが、PUTで出した編集画面のままで言語を切り替える際にも、単純なa要素（アンカー）による切り替えが出来ないんですね。つまり、GETだと編集画面の言語を切り替えるのではなく、言語切り替え後には個別表示画面が出ているという案配です。_methodをfill-inするなど、formが増えれば増えるだけ面倒になります。

ではどうするか。やっぱりRailsのようにするしかないと思いました。

HTML5でform要素のmethod属性に（これまでのgetとpostに加えて）putとdeleteが追加されることを心待ちにしていますが、勧告に先立つ実装が出たからといって、古いUAを切り捨てるわけにはいきません。

ということでHTTPメソッドとしてはpostなんだけれども_methodという名前の値でputだとかdeleteだとかを主張する、Railsでもおなじみの似非REST（なんだかエベレストみたいな語感ですね）として、現在のアプリケーションを開発しています。

ここで問題になるのはフォームの取り扱いです。編集画面（入力画面）とそのフォームの送信先のURIが同じ場合、_methodという値がいることで$c->req->paramsが存在すると思われてしまいます。HTML::Shakanの場合、$form->submitted_and_validを多用することになりますが、_methodだけが定義されている場合には$form->submittedだと見なさないような手当が必要になります。

ということで、HTML::Shakanを継承したモジュールで、_build_submittedメソッドをオーバーライドしてしまいます。

HTML::Shakanは構成部品を自由に組み替えられるので、先の記事のようにHTML::Shakan::Renderer::HTML::Simpleの代わりにHTML::Shakan::Renderer::HTML::DefinitionListを使うなどといったことが出来ます。従って、汎用性を余程力説出来るようなものでなければ、自アプリケーション専用の拡張として、MyApp以下の名前空間にそっとしておくのが良さそうです（MyApp::Web::HTML::Shakan::*などとして）。

ただ、標準添付クラスの気になったところを触る場合には、クラスの外部からパッチを（実行時に）充てるよりは、本体を触ってしまう方が楽ですし、パッチャーモジュールのローディング漏れも気にしなくて良いので安心です。

ということで、例によって前置きが長くて恐縮ですが、id:tokuhiromさん（松野徳大さん）のHTML::Shakanをforkして遊び始めました。

http://github.com/gardejo/html-shakan/tree/master

取り敢えず、

• HiddenFieldの追加
• ラジオボタンの関連付け（グルーピング）

というところからpushしています。

今後、チェックボックスなどのウィジェットも追加してみたいと思っています。

なお、CPANには0.02が存在しますが、fork元は0.01_06なので、万が一私の怪しげなコードを使われる場合には、そのバージョンの差異にお気をつけください。

『モダンPerl入門』でも言及されているとおり、MVCのM、つまりモデルについては、ウェブアプリケーションフレームワークとは分離するのが定石です。

で、Arkの場合はこれまで以下のようにArkの管轄外のモジュールに代用させる処理を山のように書いていました。

package Amikeco::Web::Model::User

use Ark 'Model::Adaptor';   # automatically turn on strict & warnings

__PACKAGE__->config(
    class => 'Amikeco::Logic::User',
);

1;
__END__

流石にこれを山のように書くのは辛いので、ラッパークラスでも作ろうかと考えていたのですが、Ark::Modelsの登場により、要はFlyweight的な面倒を見てくれるObject::Containerと仲良くすれば良いと分かったので、MyApp::Model以下のモジュールを殆ど全て消すことが出来ました。

今まで通りに$c->model('Foobar')のような感じで使うために、私は後述するように姑息な手だてを講じていますが、ファイルの数が多くなるよりはましだと思って楽をしてしまいました。委細は以下の通りです。

見栄えは二の次、三の次で、まずはロジックをがっつり書いているところですが、そうはいっても完成形のページを生成して独りほくそ笑むという趣味の悪い悦楽に浸るためには、それっぽい画面を生成する必要があります。

ということで、HTML::Shakan::Renderer::HTMLをそっくりそのまま剽窃したHTML::Shakan::Renderer::HTML::DefinitionListを試験的に書いたので、取り敢えずgistに上げておきました。名前の通り、ベタにフォームを並べずに、定義リスト（dl要素）で描画するというものです。

• HTML::Shakan::Renderer::HTML::DefinitionList
• HTML::Shakan::Renderer::HTML::SelectivelyEncodable
• HTML::Shakan::Renderer::HTML::DateTimeSeparatable

上記はちょっと気持ち悪い実装ですが、HTML::Shakan自体はとっても気持ちの良い実装なので、添い遂げたい気持ちになるというものです。

名前空間こそHTML::Shakan::Rendererの下位にありますが、これはあくまで開発中のアプリケーション用のモジュールであり、汎用性はありません。フォーム関連処理の部品をレゴブロックの様にいくらでも好きなように組み込める（何よりMouseなモジュールなので心理的障壁も低い）という、あくまで一例に過ぎません。

Ark::Plugin::Authentication::Store::Data::Modelを0.04_00に更新しました。

これで、最初の記事で言及していた内容としては、大体片が付いたように思います。

• $model->lookupでrowオブジェクトを探す版の...::Fastを統廃合して、新設したMoose/Mouseアトリビュートのbool値で処理を切り替えるようにしました。
• gistに実測値付き簡易ベンチを上げましたが、イテレーターよりもリストで貰ってきた方がごくわずかに成績がよいようなので、処理を変えました。limit => 1も生かしています。
• テスト用DBの作成の際に、Data::Modelによって生成するSQL文を使うようにしました。

問題は、次の記事でも言及した、PODのまわりくどさですが......ますます拍車が掛かったような気がします。現状はさて措き、Arkのドキュメントが充実すれば屋上屋を架すことになりかねません。これはもう少し検討が必要かも知れません。

それと、MANIFESTの更新をcommitし忘れていたのをこっそり修正したりして、取り敢えずgithubに上げました（commit対象の漏れがないか確認する際には、Tortoise gitのGUI画面が便利かも知れません）。

http://github.com/gardejo/ark-perl/commit/4039f1e7d7722d270bcd7035b7fe2771b119edbd

さらにいくつかのシチュエーションで使ってみて、感触を確かめてみようと思います。

Ark::Plugin::Authentication::Store::Data::ModelとArk::Plugin::Authentication::Store::Data::Model::Fastを0.01_00に更新しました。APIをArk::Plugin::Authentication::Store::DBIx::Classに合わせたのが今回の修正点です。

先の記事で$infoの使いどころに悩んでいましたが、これは私が単純にDBIx::Class然り、Data::Model然り、それらのO/Rマッパーに類するクラスに明るくないからでした。

或るモデルクラスがあったとしたら、そこにfind_userというオレオレメソッドを仕込んでしまい、そのメソッドの引数として使うというのが、$infoの生きる道であるようです。プラグイン純正の処理ではなく、自分で仕込んだメソッドでユーザーを拾ってくれるという案配ですね。今回の場合、例えばMyApp::Schema::Table::Userという架空のユーザーモデルクラスがあったとしたら、そこにfind_userメソッドを仕込むという次第です。勿論、これまで通りプラグイン純正の処理でもユーザーを捜せます。

ということで、テストはそのままで、PODを怪しげな英語で若干追補しつつ、0.01_00としてgithubにpushしました。

http://github.com/gardejo/ark-perl/commit/28f98f308b293befe677e3fa3672038f29c9bead

......PODの誤りを訂正しました。うっかりぽん。

http://github.com/gardejo/ark-perl/commit/f9784728d2e8e6ba5f390b2d626897dd6fc00ce2

PODがちょっと回りくどすぎたかという思いと、Data::Modelの効率的な使い方が出来ているか確認したいという思いがあり、これらの懸念が解消出来たら、畏れ多くもfork元へのpull requestを差し上げようかと思っています。

あと、独立したプラグインであればともかく、pull request歓迎というポリシーに基づいて本家に取り込んでいただける可能性があるプラグインの場合、個別にバージョンなどを設けない方が良いのかどうなのか、Catalyst::Model辺りのCPANモジュールを拝見してみようと思います。

ArkのData::Model対応として、Ark::Plugin::Authentication::Store::Data::ModelとArk::Plugin::Authentication::Store::Data::Model::Fastというプラグインモジュールを作ってみました。

githubでforkしています。

http://github.com/gardejo/ark-perl/tree/master

前者は普通に$model->getするのに対して、後者はインデックスを使って$model->lookupしているのが違いです。別々のモジュールに分ける必要性は、多分ないです（モジュール内で吸収すべきですね）。

目下、開発中の私のアプリケーションで満足に動いているのですが、あくまでまだ実験です。

留保の理由は以下の通りです。

Data::Modelでは、現段階ではリレーションをサポートしていません。作者の大沢さん（id:yappo）ご自身の紹介には「よい実装手法があれば作りたい所」とも書かれているので、将来的な実装を期待するところ極めて大なのですが、現段階でサポートしていないのも納得のいく話です。

なぜなら、Data::Modelはobject/relation mapperではなく、data/object mapperだから......というのも勿論ですが、O/Rマッパーを使う上では、あまりリレーションにこだわらず、リレーションが必要になる処理は予め非同期に済ませておくのが、世の趨勢である（ように見受けられる）からです。『モダンPerl入門』にも、以下のような箴言が書かれています。

そのような複雑な処理が必要なのであれば、それらは非同期に前もって行い、サマリーテーブルを作成するべきでしょう

とはいえ、先の画面遷移図を見ると、Amikeco::Entity::Avatar（プレイヤーキャラクター）とAmikeco::Entity::Race（種族）のようなhas-a関係だけでなく、Amikeco::Entity::Account（アカウント）とAmikeco::Entity::Expansion（拡張パッケージ）やアカウントとプレイヤーキャラクターのようなhas-many関係が頻出しています。

まさにこれを単純化して、リレーションを廃したサマリーテーブルを触らなければならないのでしょうが、取り敢えず最初はリレーションを無理矢理実装しています。もうちょっと一般化が済んだら泥臭いコードを公開しますが、そもそもData::Model::Rowオブジェクトにadd_methodすればいいのに、わざわざ別個のMyApp::Entity::Foobarオブジェクトを作っているので、スタート地点から使い方を間違えているような気がなきにしもあらずです。というような状況で、Data::Modelのトランザクションと、MyApp::Entity::Foobar（Moose/Mouseオブジェクト）のlazy_buildでせこせこと実装しています。

懲りずにFF14のユーザー向けウェブシステム"Amikeco"（仮称）の画面遷移図もどきです。前回の2009/07/02版との間違い探しの様相を呈してきました。

このシステムでなくても、FF14然り、一般的なMMORPG然り、ユーザー向けCGIスクリプトを作る上での基本的な事項が読み取れるかも知れません。単なる大枠の設計で、PerlやらRubyやらといった言語にも左右されない肝の部分ですので、例えばPerl + Catalystだとか、私のようなPerl + Arkで実装するのも一興でしょうし、勉強かたがたRuby on Railsで組んでみるのも面白いと思います。

Arkの依存モジュールの一つでもあるText::SimpleTableですが、2009/07/03のバージョン1.2で、「列幅を1バイトと指定した列で1バイトを超える列名や値が入るときに無限ループする」という不具合が解消しました。

このモジュールは、列幅を超える列名や値について、-（ハイフン）で区切って次の行を描画するという仕組みです。当初のバージョンでは、列幅が1バイトだと（-それ自体で1バイトを専有してしまうので）、無限に次の行を描画するという不具合が生じていました。

この解決策として、私のオレオレパッチでは「列幅が1なのに列名や値が1を超える場合にはcroakする」という場当たり的な方法を採ったのですが、本家1.2では「列幅が1だろうが何だろうが最小の列幅を2にする」という対応になっています。

Arkの依存モジュールということで知ったモジュールですが、CLIでは結構便利なモジュールで、私もMyApp::CLI::Viewで色々と使わせていただいています。今回の改定で、全列幅がいっぱいにならないように気をつけようと思います。

一応、何を言っているかというコードを以下に掲げておきます。

FF14.nameやFF14.asiaで機能の一端を紹介していますが、これだけではイメージが掴みづらいので、ざっくりとしたものですが画面遷移図もどきな得体の知れない画像を貼り付けておきます。詳細な検討はまだ全然行っていません。

補足しておくと、ASPで（も）動かすため、例えばスクリプトをダウンロードしていただいて個々のサーバーでCGIで動かすような場合に不要な階層化も含んでいます。例えばAmikeco::Web::Controller::Community辺りです。

非Moose/Mouseの継承ネタで、MooseX::Types::DateTimeやMouseX::Types::DateTimeを使った方が早いと書きましたが、MouseX::Types::DateTimeの0.02では警告が出ますので、これを回避するパッチを紹介します。

ごくわずかなパッチなのですが、著者の方が日本人とはいえ、CPAN RTに英語でチケットを切る踏ん切りが付かず、結局標準とは違うオレオレライブラリ（例えば/MyApp/lib/）に同名モジュールを突っ込んでしまっています。

先の例のようなDateTimeの例だと、単にMouseX::Types::DateTimeやMooseX::Types::DateTimeを使ってcoerceすれば良いので、アプリケーションそのものではなく、いくつかのアプリケーションに共通して必要になりそうなクラスを集めたオレオレリポジトリから、別のクラスEmail::Addressでの例を紹介してみようと思います。

MouseにはMouse::Meta::Class::new_objectメソッドがない（Class::MOPに頼っていないので当然ですが）ので、非Moose/Mouseクラスの継承の方法が限られます。従って、委譲での継承をすることになります。

追記：委譲でなく真っ当な継承を行う方法を、トラックバックで教えていただきました。委細は以下の通りです。