ほげぐらまの別館

プログラムに限らずてきとーに、ね?

発売日的には後数時間なんですが、体験版より楽しみにしていたラグナロクオデッセイの発売日!です。先日のアーマードコアV体験版ですがヘッドマウントディスプレイHMZ-T1でプレイしたのが悪かったのか、10分後に2ch AAのオエー鳥をやらかしてしまいました。

ということで私はマイナー派のオデッセイ購入ユーザ予定なんですが、その形態がVitaカードなのですね。ということで、数か月前に遡る事に同じですが、使うことのない購入特典がきっとついてくるだろうと。なので、今回もてきとーにチケット番号は投下します、付属特典についてこれば。

ROユーザの傾向からみれば1人1アイテムだよ、って言ってもそれを守る事なんてないとは思うので全部占めてもらっていいですが、3日後には例のごとく使った人がいるいないに関わらず消しますのであしからず。

2月6日 1:15削除しました

  • たれどドモヴォイ
  • ドンドモヴォイのマント
  • ドモヴォイ
  • フルングニルの魔眼

 

ってか、同時装備という条件がありながらも”クローキング Lv1”発動とか私が現役の頃ならそれだけで買いな物体ですね。だって、完全にS-A型の融合前提(悪魔 Lv9)な拳聖キャラでほぼエンペ専用な状態。クローキングは夢スキルだったな・・・・とか。

 

さておき、プレイは周りに買う人がいないらしいのでほぼソロ専ですが、オンライン(アドパ?)対応したら即刻入りたいですね。

先日月間のPV数などを挙げたのですが、StatPressよりもWassUpの方がより分かりやすいデータが出ていたようで。スパムは少ないものの、スパイダー(検索Bot君)のアクセスは30%~40%前後を占めており、それを除いたグラフを貼り付けてみるテスト。

wassup

図の通り、直近1ヵ月間のSpam/Spiderをを含まないほぼ純粋な閲覧してきた人のグラフ推移なんですが、UPV数がやはり前回推測したのと完全にマッチして1.47UPVとなっています。そしてこれもグラフから明らかなんですが、土日にかけてPV数が減るところが技術っぽい記事の傾向なのかな・・・・と。

まぁ、PV数では毎月40%~50%の伸び率らしいので、てきとーにネタを投下するしかないですね。

別段こんなネタを望んでいるわけでもないのですが、体質なのかエラーに出くわすのが常なようです。月曜日からかなりお疲れなタスクを抱えて”みんいつ”をやりつつも物足りないのでPSStoreをてきとーに見ていたら・・・・

“127時間”がレンタルで出ている!!

あらすじなんてbingれ一発なんですが粋のいいにーちゃんが谷間に挟まって生死をさまようノンフィクションな物語を映画化したものです。
※ ちょっとここ最近の諸事情でGoogle様が嫌いになりましたので、検索の動詞がbingる、になります。

モンハン2Gを買った後で丁度ウォレットが余っていたことから意気揚々と購入ボタンを押すも・・・・エラー?? 購入のために押したレンタルボタンは再度押せなくなっているし、ウォレットの利用履歴には400の消費があるだけ・・・・。そして、悩んだ挙句に右下にある「・・・」を押すとダウンロードリストなるボタンから再ダウンロードができるかと思いきや・・・、またエラー。

10分ほど出続けるエラー窓を閉じながらトライアルを続けるとようやくダウンロードが開始されて・・・・。遭遇したエラーは”E-80103841”と、”E-8010382e” が不安定に表示されてより一層混乱を起こす状態に。あ、記念に写真もバッチリとっておきました。

psn_err1psn_err2

 

とりあえず分かったことは、早々使わないPSStoreでウォレットを消費した瞬間にエラーと出れば

ストアに対する信頼性を全て奪い去るのに十分な破壊力だな

と実感するところです。そして、このエラーの悪い意味ですごいところが、検索しても何一つ情報が出てこないところなんです。Windowsであればエラーコードを入力しようものなら読み切れない量の資料が出てくるところなのですけどね。

 

今残っているウォレットを使い切ったら多分オンラインStoreを使うことはないでしょう。何だかんだでiTunesStoreが恵まれたストア環境なんだと身に染みて感じる出来事でした。

Windows Server 2008 R2 with Hyper-V (+ RemoteFX)な環境にしてからほぼほぼ3ヶ月。RDセッションホスト側のライセンシングの猶予期間の満了が迫ってきました。各OSに対する猶予期間の資料はこちらから。

以前にもRemoteAppを評価すべく”リモートデスクトップ”の役割の一つである”リモートホスト仮想化サービス”を有効にしたことがあってその際も120日の評価と共に再インストールを行ったことがあります。ただ今回は些か面倒なデータ量なのでリモートデスクトップのライセンスサーバを立てようと。

 

私のネットワーク環境は例のごとく多くのサーバが立っていて、当初はActiveDirectoryのサーバとRDライセンシングサーバを同居させる予定でした。ところが、ActiveDirectoryサーバに”リモートデスクトップライセンス”を追加しようとするとActiveDirctoryサーバとライセンスサーバの同居はセキュリティ上望ましくないとの警告が・・・・。個人サーバでセキュリティもあったもんぢゃないから無視しようかと思いましたが、やはり(一応)IT技術者としてはやってはいけないだろうという事で。普段ついているサーバがVPNサーバでしたが流石にそこも無いだろう・・・・、ということでSMSサーバにインストールすることにしました。

サーバを構成する際に幾つかスクリーンショットを撮ったのですが、ホストサーバ(Hyper-Vが入っているサーバ)に”リモートデスクトップセッションホスト”を追加した際にそのまま再起動してしまって画像がロスト。なので行ったこととを文字で列挙しつつ、結果画面のみの案内となります(ここの説明を行っているblogが壊滅的で・・・、余計なサービスを追加したくないのでスナップショットの巻き戻しをフル活用したり、結構疲れました)。

 

説明する前に結論的なことを言えば、多分以下のMicrosoft(MSDN)から提供されている資料を見ればシステム系の人ならば恐らくわかるのではないかと思います(注: 私はシステム系ぢゃないよ、多分)。

ただ、上記のは文字しかなくて全然イメージがつかめなかったので・・・・。スクリーンショットとかで案内してほしいです。なんとか頑張ってくれませんか、マイクロソフト様。

 

と言う事で大まかな構成のイメージ図。

rd

 なので、Hyper-Vホスト側に”リモートデスクトップセッションホスト”を、リモートデスクトップライセンスサーバには”リモートデスクトップライセンス”の役割サービスを追加します。

 

【リモートデスクトップライセンスサーバ側でする事】

  1. “リモートデスクトップライセンス”の役割サービスを追加します。(1)既にリモートデスクトップサービスが役割として存在しているならば、サーバマネージャから[役割]-[リモートデスクトップサービス]-[コンテキストメニュー内の役割の追加]からウィザードに沿って役割サービスが追加できます。(2)まだリモートデスクトップサービスが役割として存在していないならば、ウィザードに沿ってサービスを追加すれば同様の流れになります。
  2. ウィザードの途中でライセンスのタイプ(デバイスCAL, ユーザCAL)が聞かれますが、後構成でもいいのでパスします。
  3. 役割・役割サービスの追加を完了させます
  4. [スタートメニュー]-[すべてのプログラム]-[管理ツール]-[リモートデスクトップ]-[リモートデスクトップ サービス]-[リモートデスクトップ ライセンス マネージャ]を起動します。
  5. サーバを選択して[アクティブ化]をします。恐らくウィザードが起動するので、認証方法を”自動構成(推奨)”にします。
  6. 名前・国・会社を入力します。(会社、って個人の場合どぉするんでしょうね。とりあえず”Individual”と打ってますが。)
  7. そのまま進むとMicorsoftのライセンスを管理するサーバ(表記忘れた)と通信が始まります。ここで25桁の英数字で構成されたライセンスコードを入力します。
  8. ライセンスコードが確認されると以下の画面のようになるはずです(私の場合はユーザCAL)。

rd_license

 

【リモートデスクトップセッションホスト側でする事】

  1. RemoteFX, RemoteAppが使える段階で既に”リモートデスクトップサービス”役割自体は追加されているので”リモートデスクトップセッションホスト”を役割サービスとして追加します。
  2. ウィザードの途中でライセンスサーバの検索や認証を聞かれますが、適宜判断します。私の場合は検索しない、とドメインメンバ?を選択しました。
  3. ウィザードが完了するとインストールが始まります。この役割サービスは再起動が必須なので、再起動ができるようにしましょう。
  4. 再起動後にインストール構成が始まって、それからインストールが全て完了します。
  5. サーバマネージャを起動して[役割]-[リモートデスクトップサービス]-[RDセッションホストの構成]を開きます。
  6. ライセンスの辺りをダブルクリックして、先ほど構成したライセンスサーバを追加します。

rd_host

 

と、こんな感じで全ての作業が完了します。初のサーバライセンス系のアクティベーションだったので正直上記の方法で正しいのかは怪しいところです。なので、自分で責任を持って作業してね!、ということに尽きます。ライセンスが正しく認証されているのか、ホスト側でライセンスの確認を見る限りは特に問題は無さそうですね。

rd_verified

 

今回は当然私1人の環境という事でAmazon経由で1ユーザCALを購入しました。お値段は14,175円。

 

決して安くはないし、ましては失敗したらどぉしようかと不安でしたが・・・・、きっと大丈夫だと願っています。あ、因みに商品に付属されたものは紙2枚(ライセンスコード, EULA)です。

iOS環境ではプッシュ通知が重要だよ、的な周り口で1セッションの通信において複数デバイスにプッシュ通知を行うという記事を投稿しました(因みに自分ではまだやってないのですけどね、同僚が私の作ったモジュールを使って動いているよ~って言ってるから動いているのでしょう)。

プッシュ通知は重要ながらもチュートリアル的な実装をそのままコピペで実装してしまうと優れた機能も非常に残念なことになります。というのも、例えばよくあるパターンではゲームに対してプッシュ通知が実装されている場合、タイトル画面といった起動した瞬間に「○○はプッシュ通知を送信します。よろしいですか?」と出現するパターン(画像はあくまでサンプル画面ですが、実際に私が指摘する最悪なパターンを再現してくれたものです)。

apns_dialog

少しはユーザのことを考えればわかることですが、これって開発側からのエゴの何物でもないですよね。だって、リアルな環境に置き換えるならば、試供品を受け取った段階で

とりあえずDM(ダイレクトメール)送りたいんだけど受け取りますか?

と言われているに近しいものだと思うのです。

因みに私はこのパターンは絶対にプッシュ通知を許可しません。だってウザったいかもしれない通知が来るかもしれないのにそれを許可する理由なんてないですから。

 

ってことで、長々とウンチクを垂れましたが、端的に言えばプッシュ通知をすべき場所を今一度見直して、細かく制御しましょうよ、と。プッシュ通知はUIAPplicationのインスタンスメソッドとして定義されていて以下の3つがあります。

  • registerForRemoteNotificationTypes…プッシュ通知を有効にしようとします。ユーザにダイアログでプッシュ通知の確認が求められます
  • unregisterForRemoteNotifications…登録されたプッシュ通知を破棄します
  • enabledRemoteNotificationTypes…(どのような種類の)プッシュ通知が有効かどうかを取得します

なので、チュートリアル通りにapplication:didFinishLaunchingWithOptions:でregisterForRemoteNotificationTypesをコールするのではなくて、どのような目的でプッシュ通知を行いたいかを述べたうえで初めてregisterForRemoteNotificationTypesをコールしましょう、と。これをやっているのがGameloftの”レッツ!ゴルフ3”ですね。

 

・・・・、とここまでが前置き。そしてようやくタイトルの話になります。上述の通りにプッシュ通知のダイアログが出るタイミングというのは非常に貴重なもので、本当にこのタイミングでよいのかどうかを試験したい場合がありますが、一度この確認でどちらかを選択してしまうと開発中でも中々出てくれません。で、かるーくググってみると大好きなStackoverflowでこんな投稿がありました。

相変わらずの精度が低いほげ脳内翻訳によれば

アプリケーションが初回にプッシュ通知を有効にしようとするならば、iOSはユーザにアプリケーションから通知を受け取るか否かを確認します。一度でもその警告(プッシュ通知の同意ダイアログ)に応答した場合は、デバイスをリストアするか、若しくはアンインストールを行ったうえで少なくとも1日以上経過する必要があるでしょう。

もしあなたが初回のプッシュ通知をシミュレートしたいとするならばアンインストールを行ったうえで1日経過させる必要があります。但し、システムクロックを1日以上経過させたうえで一度デバイスをシャットダウンし、再度デバイスを起動することで後者(=アンインストール後に1日以上経過するという条件)を満たすことができるでしょう

と書いた本人ですが、実際に試していないのであしからず。

 

今回の記事をまとめるとこんな感じ

  • プッシュ通知はアプリケーションが非アクティブ状態でもアプリ提供者側からユーザに情報通知が可能な数少ない手段です。
  • ダイアログを表示することでプッシュ通知の同意を求める貴重なアプローチは1回のみです。もし本当にプッシュ通知を利用して欲しいのであればこのアプローチを行う前にユーザにプッシュ通知を行う利便性を説くべきでしょう。
  • プッシュ通知は登録(登録要求)・解除・状態取得の3つのメソッドがあります。
  • プッシュ通知の初回のアプローチはstackoverflowに書かれているような方法で再度確認を行うことができる(はず)です。アプリの提出前に本当にユーザが望ましい形でそのアプローチが行われているか確認しましょう。