朝の時点のグリーティングスケジュールが stale になることがあるという自戒です。

グリーティングスケジュールの公開

ピューロランドでは何年か前 (2008年か2009年ごろだったか?) から当日のグリーティングのスケジュールが Web で公開されるようになり、モバイル端末から http://puroland.co.jp/chara_gre/ で閲覧できるようになっています。念のためもう一度、モバイル端末以外からだと蹴られます。

見てもらうと分かるとおり、キャラクターの一覧からキャラクターを選ぶと、そのキャラクターがどの時間にどこでグリーティングを行うかの一覧が出るようになっています。時間や場所ではなくキャラクターを中心としたナビゲーションとなっており、どのキャラクターに会いたいという明確な意図があるユースケースに適したものになっています。

満たせないユースケース

2012年6月2日に起きた実例です。4階でシナモンと戯れた後、1階に下りてみるとハナちゃんメルが一緒にグリーティングをしていました。そのグリーティング中に撮られた写真の例は以下のものです。リンクではなく引用にしたかったのですが、素の Markdown だけでは Twitter の Display Guidelines を守れそうになかったためリンクのみにしてあります。以下同様。

残念なことに私がこの組み合わせに気付いた時点で新規に並ぶのが終了となっていたため、貴重な組み合わせを逃してしまったわけです。キャラクターを起点としたナビゲーション構造では、キャラクターの組み合わせというものを逃してしまいがちです。

ゲストのグリーティングスケジュール利用例

館内で見かけた他のゲストの利用例では以下のようなものがありました。

携帯電話でキャラクターの時間と場所の組の列をテキストエディタっぽいものにコピペし、その組に対してキャラクター名をコピペする。複数のキャラクターでその処理が終わったら時間順に並び替える。携帯電話なのでコピペもソートも手作業になります。

やはり時間順に並んでいるというのは需要があるようです。

作成したスクリプト

自分の需要を満たすために作成した PowerShell スクリプトが https://github.com/ohtake/spl-greeting になります。PowerShell の Execution Policy が RemoteSigned などに設定されていれば dot sourcing operator で、設定されていなければソース本文コピペでどうぞ。

実行すると以下のような出力を得ることができるため、時間と場所の観点からキャラクターの組み合わせを見ることができるようになっています。このデータは2012年7月6日の午前9時半ごろに取得したものです。

PS> $items  | group Start,End,Location | sort Name | select Name,{@($_.Group|%{$_.Name}) -join ", "} | ft -Wrap

Name                                                        @($_.Group|%{$_.Name}) -join ", "
----                                                        ---------------------------------
2012/07/06 10:00:00, 2012/07/06 10:15:00, ピューロビレッジ(1F)   ジャスパー, ウィッシュミーメル
2012/07/06 10:30:00, 2012/07/06 10:50:00, ピューロビレッジ(1F)   ダニエル・スター, マロンクリーム
2012/07/06 10:40:00, 2012/07/06 11:00:00, ピューロビレッジ(1F)   リトルツインスターズ
2012/07/06 11:00:00, 2012/07/06 11:20:00, キティズハウス前(1F)    ジョージ・ホワイト, メアリー・ホワイト
2012/07/06 11:00:00, 2012/07/06 11:20:00, レインボーホール(3F)     ジャスパー
2012/07/06 11:15:00, 2012/07/06 11:30:00, グルメバザール(1F)    トニートニー.チョッパー
2012/07/06 11:25:00, 2012/07/06 11:55:00, レインボーホール(3F)     ダニエル・スター, マロンクリーム
2012/07/06 11:45:00, 2012/07/06 12:00:00, 館のレストラン(4F)     キティ・ホワイト
2012/07/06 11:55:00, 2012/07/06 12:15:00, ピューロビレッジ(1F)   リトルツインスターズ
2012/07/06 12:00:00, 2012/07/06 12:20:00, レインボーホール(3F)     ラブラ, ジャスパー
2012/07/06 12:55:00, 2012/07/06 13:25:00, レインボーホール(3F)     ミミィ・ホワイト, 本舗固歩香本, 分部久花
2012/07/06 13:00:00, 2012/07/06 13:15:00, 館のレストラン(4F)     キティ・ホワイト
2012/07/06 13:30:00, 2012/07/06 13:50:00, レインボーホール(3F)     ラブラ, ジャスパー
2012/07/06 13:55:00, 2012/07/06 14:25:00, レインボーホール(3F)     ミミィ・ホワイト, 本舗固歩香本, 分部久花
2012/07/06 14:35:00, 2012/07/06 14:55:00, ピューロビレッジ(1F)   ガーネット, ジャスパー
2012/07/06 15:00:00, 2012/07/06 15:30:00, レインボーホール(3F)     ダニエル・スター, マロンクリーム
2012/07/06 15:30:00, 2012/07/06 15:45:00, 夢のタイムマシン(1F)    トニートニー.チョッパー
2012/07/06 15:45:00, 2012/07/06 16:05:00, レインボーホール(3F)     ガーネット, エンジェラ
2012/07/06 16:10:00, 2012/07/06 16:40:00, レインボーホール(3F)     ダニエル・スター, マロンクリーム
2012/07/06 16:30:00, 2012/07/06 16:55:00, ピューロビレッジ(1F)   ももうさ&はなうさ, マイメロディ, ウィッシュミーメル
2012/07/06 16:40:00, 2012/07/06 17:10:00, レインボーホール(3F)     キティ・ホワイト
2012/07/06 16:45:00, 2012/07/06 17:05:00, レインボーホール(3F)     ガーネット

この出力されたテキストから冗長となっている年月日と秒を削除したものをモバイル端末に転送しておいて現地に赴くわけであります。

Stale となった例

しかしながらこの方法には欠点があったことが判明しました。2012年7月6日のことです。

  1. https://twitter.com/kurunajalove/status/221059945750204417
  2. https://twitter.com/ohtaket/status/221072824142532610
  3. https://twitter.com/kurunajalove/status/221074857872470016

このようにスケジュールが途中で更新されることがまれにあるようです。

2012年7月6日の9時半ごろと18時ごろに取得したデータの比較をすると以下のようになっており、3回あったガーネットのうち2回がサフィーに置き換えられ、1回あったエンジェラもサフィーに置き換えられています。

PS> diff (cat .\20120706.csv) (cat .\20120706b.csv)

InputObject                                                 SideIndicator
-----------                                                 -------------
"サフィー","2012/07/06 14:35:00","2012/07/06 14:55:00","... =>
"サフィー","2012/07/06 15:45:00","2012/07/06 16:05:00","... =>
"サフィー","2012/07/06 16:45:00","2012/07/06 17:05:00","... =>
"ガーネット","2012/07/06 14:35:00","2012/07/06 14:55:00"... <=
"ガーネット","2012/07/06 16:45:00","2012/07/06 17:05:00"... <=
"エンジェラ","2012/07/06 15:45:00","2012/07/06 16:05:00"... <=

今後

Stale になることを防ぐには一定時間おきに取得するのが簡単ですが、リクエスト数が多くなるので踏みとどまらざる得ないです。とりあえずは朝と晩に取得して stale になるのがどのくらいなのかを観察してみようかと思います。