2009年8月アーカイブ

本日は第45回衆議院議員総選挙と、第21回最高裁判所裁判官国民審査の投票日です。

我が国に於いて、投票はもちろん義務ではありません。しかし、権利があってなおかつ投票に行ける心身の状態であるのにもかかわらずに投票に行かないのは、ちょっと勿体なくないですか。その先の政治への文句を言う資格がないとまでは思いませんが、同じ文句を言うのだったら胸を張って大手を振って言った方が気持ちがいいですよ。きっと。

首相公選制も間接民主制も完全な仕組みではありません。小飼弾さんのブログ記事にあるような個別事案への意見表明も、向こう数十年はまず難しいでしょう。

選挙に期待を抱くのも、政治家に期待を抱くのも、まあ現状の仕組みではやめておいた方が得策でしょう。それでも世界の仕様に応じて実装を試みるのはプログラミングでも投票でも同じわけで、どこかの党みたいに理想論だけ打っても仕方がありません。

だからといって何もしないのでは、強固な国家構造は何も変わりません。理想を頭から信じるつもりはなくても、どこまで出来るか託してみるのも一興です。または、何もしないのでは、軽薄な流れに乗って悪い方に変わってしまうことを防げません。この国が食い散らかされるのを防ぐ砦を支えてみるのも一興です。あなたが立候補者でないなら、ちっぽけな一票を行使する以外に政治に対するAPIが事実上公開されていないんですもの、これは仕方がありませんね。正直このカプセル化はどうよ、と思いつつも、仕方がないので投票メソッドを叩きましょう。

他にも、取り敢えず一票の格差を是正する視点で国民審査というセレモニーだけ参加するのもありです。ちなみに0.6票の豹の絵が描かれているサイトだと思って自分の選挙区を確かめたら衆院だと0.5票を割っていて笑いました。参院だともっとすごい。鳥取と島根をくっつえけてしまえという暴論を出す人の気持ちも少し解ります。個人的には道州制導入時にいい感じにご破算になるような気もしますが、ゲリマンダーだったらどうしようとも思ったり。

なんだか例によってグダグダな記事ですが、ともあれ投票は一部を除いて夜20時までです。散歩の行き先を投票所にしてみませんか。

今年もJUSのLightweight Languageカンファレンスが開催されましたので、参加して参りました。LLTV (Lightweight Language Television)という題名です。出演者の方々・協賛各社および各団体・そしてスタッフの方々に、今年も深い感謝を捧げます。

折角なので、少し長文となりますが、雑多な感想を記してみようと思います。

さて、今年は「テレビ」にちなんだ演目でセッションが構成されたのですが、元ネタと内容の親和性が高かったのは(「それっぽかった」のは)「ビフォーアフター」くらいで、他は親和性という意味では微妙なところもありました。もちろん、私自身がテレビというメディアを普段ほとんど観ないので、その辺の受け取り手側の問題を考慮する必要があります。そして、これが大事なところですが、元ネタなどというものは飾りです。LLらしい自由な発想で、テーマを着想の一つとして大らかで実りの多い番組を期待していましたし、それは叶ったと思います。

いずれの番組もとても興味深いものですが、詳細な内容は他の多くの方のブログや月曜辺りに上がりそうな各メディアの記事などをご覧いただこうと思います。それらは記事の末尾にあるリストに追記していきます。

この記事では、個人的に特に興味があったり、私が記事にし易かったりする番組をいくつか振り返ってみることにします。

なお、今回のアンケートを実施中だそうです。

FF14のプレイヤー向けウェブシステム"Amikeco"について、前回機能概観を記したついでに、ER図もどきを晒しておきます。

ER図を作成する前に、軽くExcelでお絵描きしてみました......という位置付けですが、そもそもこのファイルが出来た原因は、画面遷移図もどき(1)および画面遷移図もどき(2)におまけとして載せていたスキーマもどきが肥大化してカオスな状態になったことを憂えたためです。しかしリレーションの線を引っ張ってみたらゴルディオスの結び目になってしまったという笑えない結末が待っていたというのは、前回記したとおりです。

以下にそのファイルを添付してますが、正直なところ、Excel方眼ドキュメントの粋ともいえるオートシェイプ地獄の後進性を、改めて強く認識させられる代物となっています。

ER図「もどき」を書くことで次第に像を結び始めたFF14のプレイヤー向けウェブシステム"Amikeco"の説明文を増補しました。「何ができます」というハイライトの紹介だけではなく、実際のサブシステムの一覧と、その簡単な説明を加えています。

個人情報管理システム辺りはData::ModelArkなどとの連携のイメージ作りとしてプロトタイピングという位置付けで実装とテストを行っていますが、この辺でシステム全体の概観に言及しておくのも悪くない頃合いだと思いましたので。

以下に説明文の増補部分の抜粋を記しておきます。

勤め先がExcelと心中することを旨としているような素敵な会社なので、私はER図(ERD)を描画する専用ツールを使ったことがありません。汎用ライブラリではなく(今回のFF14向けウェブシステムのような)本格的なアプリケーションを「きっちりドキュメントを用意しつつ」プライベートで作る経験はあまりないので、前時代的なExcelによる設計書作成作業から卒業しようと思いました。

書き方を変えると、「これまで納品物を見てああだこうだ言ったり一部分を書いてみるだけなら何とか我慢できたExcel製ER図を、いざ自分で一通り描いてみたら、短気な自分が我慢ならなくなった」という次第です。いやあ、人間というものは、他人の痛みは解らないものですね(しみじみ)。

といっても(ER図やUML各図が描けるとはいえ)Visioが出て来るわけではもちろんなくて、ちゃんとした専門ツールで、かつ、FLOSSなツールを選ぼうと思います。

さっくり探して見繕った候補と、その選定の委細は以下の通りです。

ArkData::Modelのサンプルアプリケーションとしてぼちぼち作っているSimpleLinksについて、Data::Modelでのリレーション(2) add_methodでリレーションを実装以後、一通りのテストと実装を行いました。まだ重複した処理が残っていたりして汚いのですが、改めて思うのは、手動で泥臭く実装するのは大変だということです。そもそも論を書いてしまえば、RDB的な物の考え方から抜け出せない私が自縄自縛に陥っているような気もしますが。

ともあれ、じゃああとはArkのModelと結婚させておしまいだね、と思って寝床で『モダンPerl入門』を読み返していると、p.102辺りで眠気が覚めました。

(前略)拡張機能を使いすぎるとそのORMの実装に詳しくない他の開発者達が全く手出しできないものになってしまいますし、(中略)業務上の効率を考えると何とか工夫を加えるにしてもその上のレイヤーで行うことをお勧めします。

なんだかData::Model::Mixinの使い方を間違えているような気が常々していたのですが、図星でした。

そもそもいやらしいのが、add_methodで行オブジェクトにメソッドを生やしつつも、その実装は(スキーマクラスの肥大化を防ぐために)個別のSimpleLinks::Schema::Mixin::*に丸投げしているという私の書き方です。

Data::Model::Mixin::FindOrCreateのような汎用的な機能や、Data::Model::Mixin::Queue::Q4Mのような(抽象でなく具象という意味で)低レベルな処理を扱うのには、なるほどmixinは便利でしょう。ですが、今回のようにadd_methodの実装をスキーマクラス(便宜的に表クラスとでも書きましょう)のクラスメソッドとして作成して、それをmixinしなければならないかというと、これは全然違いました。

そもそも現状でも使っているトランザクション(Data::Model::Transaction)を真っ当に使えば、別に外部で実装して問題になるわけではありません。

手動で泥臭くリレーションを実装するためには、行オブジェクト生成・更新・削除などにフックするのが簡単かつAPIも自然なので、行オブジェクトにメソッドを生やすこと自体は現状のままとしようと思います。つまり、スキーマクラスの一つ上のレイヤーであるサービス(API)クラスで実装すると、わざわざ$service->update_website($website)というような冗長な書き方になってしまいます(と思っています)ので、実装の投げ先だけSimpleLinks::Schema::Mixin以外のクラスに変えることによって、自然体で今のままの$website->updateにしたいという意図です。

ということで、少々実装を変えてからサンプルアプリケーションの解説を続けたいと思います。

FINAL FANTASY XIV(FF14, FFXIV)向けのASP(SaaS, クラウド)による非営利サービス"Amikeco"(アミケーツォ)について、そのハイライトを簡単に紹介する文章を書いてみました。微妙に呼びにくい名称ですが、水のカイナッツォのツォです。

上記のページはEorzea System WorksトップFF14.nameFF14.asiaからもたどれます。

"la Aplika programaro por Mastrumi Informon kaj Konon dum Ekosistemo de Ciberspacaj Organizoj"(ラ・アプリーカ・プログラマーロ・ポル・マストゥルーミ・インフォルモン・カイ・コーノン・ドゥム・エコスィステーモ・デ・ツィベルスパーツァイ・オルガニーゾイ)という正式名称は初出ですが、今決めたのですからこれまで出ていなくて当然です。頭字語による愛称というものは、Wikipediaでも喝破されているように後から構成単語をこじつけるという傾向があり、本サービスもその轍を踏んでいます。

英語版正式名称である"the Application software for Managing Information and Knowledge during Ecosystem of Cyberspace Organizations"にしてもAmikecoという綴りが崩れないよう、英語とエスペラントで似た字面の単語を選んだ辺り、私の器の小ささが知れようというものです。

ともあれ、どうにも怪しい販社の営業トークのようですが、非営利サービスとはいえ、ちまたのSaaSの謳い文句の要素をそれなりにつぎはぎした結果、なんともキマイラじみた文章となりました。

ただ、このサービスに掛ける熱意は相当な物と自負していますので、サービスの開始を是非楽しみにお待ちいただきたいと思います。

なお、Amikecoへご意見・ご要望・ご感想・ご提案などを歓迎しています。この開発日誌の個々の記事のいずれでもお受け付けしているほか、目安箱という汎用的なページにお寄せいただいても差し支えありません。

Ark::View周りの実装の勉強を兼ねて、YAMLとJSONでシリアライズするビュークラスのプロトタイプを書いてみました。

YAML::AnyはOO APIがなく、各YAMLパーサー/リーダー毎のOO APIを個別に呼ぶ吸収はあまりしたくないので、関数APIでいいやという諦めの境地です。

JSON::AnyはOO APIがありますが、useしたスコープで色々まさぐっているので、Ark::View::MTArk::View::TTのようにMouse属性として持つことを断念しています。またまた諦めの早い私です。

Ark::View::YAML
YAML::Anyを使ってダンプしています。
Ark::View::JSON
JSON::Anyを使ってダンプしています。Data::Structure::Util::unbless周りの泥臭さがやや気持ち悪いです。
SimpleLinks::Web::View::YAML
Ark::View::YAMLの定義です。ここでは何もしていません。
SimpleLinks::Web::View::JSON
Ark::View::JSONの定義です。ここでは何もしていません。
SimpleLinks::Web::Controller::Root
使用イメージです。テスト表示処理部分を、Viewモジュールに差し替えています。具体的には、$c->view('MT')->template('template_name');などとしていたところで$c->forward( $c->view('YAML')->dump($data) );と書いています。

......え、テストはどこかって? ごめんなさい、まだ書いていません(核爆)。テストも書いたらArkの辺境ブランチに混ぜ込んでおきます。

APIは未確定ですし、ほとんど決め打ちの処理でしかないのであくまで私家版モジュールという形ですが、将来的にはArk::View::SerializerなどとしてYAMLとJSONの両方の面倒を見るのも良いかも知れませんね。

なお、blessされたリファレンスがJSONのお口に合わないことを、恥ずかしながら始めて知りました。だからといって上記のようにunblessしてしまうのもどうかと思います。本当に単なるダンプという位置付けでしかないので、例えばWeb APIとして外部に値を渡す際には、ベタなダンプではなくて、きっちり個別のシリアライズ処理を書いた方が良いでしょう。

また、現在はテスト表示のため(ウェブブラウザで表示することを想定して)MIMEタイプをtext/plainとしていますが、Web APIとして使う場合には、text/yamlやらapplication/yamlなどとするのが良さそうです。

YAML::Anyの使い方の訂正

| コメント(0)

病み上がりで本調子でなかったのかも知れません。などとさり気なく逃げ道を作りつつ、YAML::Anyで実際に使われるYAMLパーサー/リーダーの判別法について、前の記事をしれっと訂正しておきます。

素直にYAML::Any->implementationすべきでした。確かに、YAML系モジュールが複数読まれている場合には、%INCのハッシュキーを見たり、或いはClass::Inspector->loadedで見たりしても無意味です。

また、前の記事で「たまたま何もしなくても良かった」という事案は、YAML::XSの恩恵であることを補足しておきます。

結局CLI系のライブラリにリファクタリングしたので、そのポインターを貼っておきます。

SimpleLinks::CLI::Batch::Initialization
YAML::Anyでパースした時のUTF8フラグ付与処理の差異を_read_queryメソッドで吸収しています。
examples/app/p5-ark-sample-simplelinks/tool/initialization.pl
DBに食わせるコマンド用スクリプト(改訂版)です。
t/80_batch/00_initialize.t
処理のテストです。YAML::Oldのロード後にYAMLをロードするとredefineワーニングが出るので、全5種類のパーサー/リーダーを使ってのテストは断念しています。追記:テスト時の例外送出を回避するよう、初出時から若干コード(リンク先)を変えました。

Arkによるサンプルアプリケーションですが、病気明けのリハビリを兼ねて、純モデル部分の実装イメージを一通り作りました。といってもトランザクションにすべきところを単純順次処理にしていたりと、まだまだ抜けはいっぱいあります。それが済めばようやくArkとModelの話が出来そうです。

http://eorzea.asia/links/script/simplelinks.cgi
スクリプト(以前のものとほぼ同じで、CGIでArkを稼働したもの)
examples/app/p5-ark-sample-simplelinks/tool/initialization.pl
DBに食わせるコマンド用スクリプト
examples/app/p5-ark-sample-simplelinks/SimpleLinks.data.yml
実際に食わせる元ネタ

上記は、CLIでYAMLからDBに突っ込んだウェブサイトの、最初(ID = 1)のものを表示した結果です。主に負のベクトルを持つ人徳の成せる業(笑)か、会社の後輩に「本当にArkで動かしているのか、単にそれっぽいYAMLファイルをベタに表示しているだけではないのか」というあらぬ疑いを掛けられたので、念のため補足しておきます。

ところで、基本的にYAMLはYAML::Syckでのみ読み書きする人生を送っていたのですが、ちょっと色気を出してYAML::Anyに対応しようとして、UTF8フラグ周りで足下をすくわれました。

つまづいたのは、何も考えずに使っていたら「たまたま」何もせずにエンコードをよしなに取り計らってくれるようなYAML::Anyの採用順が働いていたという点です。食わせるデータが腐っていたので環境を変えたらDBの作成・検索に失敗していたという、何とも情けないことをしてしまいました。委細は以下の通りです。

前の記事で夏風邪と書いていましたが、ようやく治りました。インフルエンザでなかったにせよ、こんなに続けて病気で会社を休んだのは久しぶりの事態でした。注射したり、検査のため血を抜いたり、点滴したりと、腕から液体を出し入れする生活はもうこりごりといったところです。今週いっぱいは薬漬け(「くすり」を音読みする時事ネタはご遠慮いただいております)の生活ですが、この記事を書く前にfavicon.icoをシコシコ作ったりCSS3を試してみたり(ff14.nameおよびff14.nameは8を含むIE以外のウェブブラウザをお使いいただくと、よりお楽しみいただけます)する程度にマンモス平気です。

さて、病気でダウンする前は雑誌記事のリークが出ていた程度ですが、スクウェア・エニックス社から「残暑見舞い」も届き、いよいよおぼろげながらFFXIVの、エオルゼアでの生活が垣間見えるようになりました。公開情報自体は雑誌リークの範疇を出るものではありませんでしたが、それに対するユーザー候補生側のリアクション(つまり世論)の動向を追い切れておらず、プチ浦島太郎状態だったりします。

個人的な換装としては、私のようなFF14向けウェブアプリでのシステム化がしにくそうなゲームシステムなのは、開発者としてはちょっと残念で、かつ発奮するところです。勿論ユーザーとしては楽しみなところなので、総合すれば良かった知らせということにしておきましょう。

夏風邪対策で処方された薬に当たったのか、発疹するわ熱が下がらないわで、眠れないなりにも寝て変な時間に起きたら、自家アンテナが2ch発の情報を受信した旨のメールが電話に届いていました。それによると、どうも本物らしい雑誌写真がいくつも紹介されています。種族改め民族や、ジョブ制とおぼしきアーマリーシステム(職能とクラス)などです。

喉の痛みをうがい薬で紛らわしつつ、そのまますぐに床に入るのも惜しい気がして、早速悪のりしてテストデータに仕込もうとしましたが......あぁっ、システムのテストデータに流すには、英語名(やそれに基づく略号)が足りないッ。

xxx hyuran   ヒューラン (de)xxx (fr)xxx
xxx lalafell ララフェル (de)xxx (fr)xxx
xxx roegadyn ルガディン (de)xxx (fr)xxx
xxx xxxxx    エレゼン   (de)xxx (fr)xxx
xxx xxxx     ミコッテ   (de)xxx (fr)xxx

取り敢えず民族も種族もraceで行けそうなので、テーブル名(別に変えたって構いませんが)はraceのままです。ただ、流石にjobテーブルはclassテーブル辺りにするでしょうし、職能は単純に訳すとabilityにもなりうるのですが色々訳せそうなので委細は不明です。つまり、armory systemなる仕組みがもうちょっと判明しないことには、どっちみち汎用MMORPG的システムの「その先」(各作品に特化した部分)の設計・実装もおぼつきません。ゆえに、どちらにせよまずは基幹システムの本流を粛々と開発していくつもりです。

この段階でのそれなりの情報暴露は喜ぶべき事なのでしょうが、冗談で書いていたつもりの「当システムのβテスト運用開始が、FF14のβテスト開始よりも遅れる」事態が、真実味を帯びてきました。

時間に余裕があれば画面遷移図を(「もどき」でないものとして)作りつつまったり進めていこうかと思ったのですが、予想外の事態に驚きました。

驚いたところでまどろんできたので、また朝まで長めの二度寝をすることにします......。

追記elezenおよびmiqo'teということで。固有名詞の綴りはen, de, fr共通で、jaのみカタカナ表記も有り得る、ということのようですね。勿論、FFXIの例を挙げるまでもなく、複合名詞(Sword of Foobar)などは言語毎に綴りが違うと思います。

Arkで書いたアプリケーションの開発者テスト(author test)でTest::Perl::Criticを使う際には、use strict;が実効コードより以前に書かれていなければならないというPerl::Critic::Policy::TestingAndDebugging::RequireUseStrictのポリシーに留意します。

具体的には、use Arkによってstrictがインポートされる(のでPBP違反ではない)ことを、Perl::Criticに教えてあげなければなりません。

書き方の一例は以下の通りです。

s/licence/license/xmsgi;

| コメント(0)

ArkとData::Modelのサンプルアプリケーションを作っていますが、この間のコミットはどうしようもない修正点でした。掲題の通りのスペルミスです。

ミスというほどのものではない(イギリス式の綴り)なのですが、通りがよいのはアメリカ式なので直しておきました。scaffolod付きのウェブアプリケーションフレームワークでは、雛形を書き間違えると酷いことになるという一例として、他山の石としてください。

なお、ここまで書いておいて何ですが、題名の正規表現置換は正しくありません。s/(licen)(c)(e)/$1 . ( $2 eq 'c' ? 's' : 'S' ) . $3/xmsgie;とするなど、大文字小文字をしっかり見なければなりません。もうちょっと技巧に走ると、ASCIIコード値のcとsおよびCとSの差分は同じなので、ビット計算しても良いです(良かぁねえよ、という突っ込みはご勘弁ください)。

それにしても、コミット単位が大きすぎるきらいがあるので、なんとかしたいところです。

ところで、ダミアン先生のPBP的にxmsは固定として、残りのgieのオプションをどう並べるか、tarのオプションのように悩んだことはありませんか?

ArkとData::ModelとText::MicroTemplate::ExtendedのトリオだとCGIでも早いよ! という実例を提示するつもりでしたが、肝心のeorzea.asiaをホストするコンピューターであるs345.xrea.comがかなりの外れサーバーだったことに遅まきながら気付きました。FTPが繋がらないだけならまだしも、サンプルアプリが(時間帯により)重いという問題は、黄金トリオの鼎の軽重が問われるようなFUDをまき散らしてしまうおそれがありました。

ということで、「真面目なサイト」のermitejo.comをホストしているs32.coreserver.jpに引っ越しました。DNS伝播の程度にもよりますが、遅くても週明けには切り替わっていることでしょう。この記事をご覧になれる場合は、新サーバーに向いていますので大丈夫です。

正直なところ、そろそろ馬脚を現し始めたDigiRock社と心中するのは微妙なのですが、短期間での切り替えを考えると、既に別サイトを運営しているcoreserverに片寄せする選択肢を採らざるを得ませんでした。

今回の引っ越しの落とし穴などは以下にまとめます。

筆者"Gardejo"について

  • Twitter: @gardejo
  • GitHub: gardejo
  • CodeRepos: gardejo
  • CPAN: MORIYA

このサイトについて

Eorzea System Worksは、架空のシステム開発結社です。

FF14.name (FinalFantasyXIV.name)では、アヴァター(プレイヤーキャラクター)の管理システムやイベント出欠・リマインダシステムや、リンクシェル(LS)運営・管理システムやDKPシステムなどを設計・開発・公開する予定です。

関連サイト

関連サイトでは、他にもFF14に関連するサイトをいくつか紹介しています。

リンク, トラックバック歓迎

このブログへのリンク(どのページでも構いません)やトラックバックを歓迎します。

設計・開発・運用の参考にさせていただきますので、コメントもお気軽にお寄せください!

個別の記事に対するご意見などのほか、目安箱もご用意しています。

このアーカイブについて

このページには、2009年8月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2009年7月です。

次のアーカイブは2009年9月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

最近のコメント

2014年2月

            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28  

やや真面目なサイト