近況について

■ミカド通い

週2回(火、金、土、日から)程度ミカド(馬場)に通っています。

基本的にはVF3tb、ガロスぺ、各種STGデイトナ等で遊んでいますが

主軸はVF3tbです。

 

ミカドでは月1で初中級者大会(優勝経験者出場不可)、月例大会があり

初中級の方は卒業しましたが月例大会には大きな壁があり全く歯が立っていません。

 

2014、2017、2018に「世界大会」と銘打って48人の限定大会が行われましたが

今年からはほぼ選抜に等しい状況で来年は完全に何らかの実績(月例優勝者など)が

ないと出場ができない大会になるそうです。

正直厳しい状況なのですが、今はそこを目標に練習してます。

 

まさか20年前のタイトルでここまで真面目にやり込むゲームが出てくるとは

思いもしませんでしたが仲の良い常連の人たちが出来たりして最近ゴルフが

あまり出来てない分の発散場所になってます。

 

むかし3tbやってたって人は初中級者大会を基準に触り始めてもらえると

今でもトップクラスに楽しいゲームだと再認識できるんじゃないかなと思います

(そっから先は魔境なので楽しいかどうかは人次第でしょうね

忘れないうちに

ダイヤリーから移行しました。別に昔みたいな頻度で更新することも無いのですが、

備忘録的に書いてあることもあるので・・・。

で、とりあえず1つ書いとこうかなと

 

電子書籍ストアと自分の利用状況について

昔に何度か書きましたが、とりあえず一番量書いたのはコレかな。

2015-04-12 - さとみ飯店の日記

現時点の状況を一度整理してみます

 

保有

bookwalker:2708

ebookjapan:1992

booklive:395

Kindle:ダルイ

 

傾向はあまり変わっておらず、bookwalkerメイン、ebookajapnサブ、bookliveは惰性、

Kindleも惰性。

 

■現在の利用端末について

現状はZenFone3 Ultraがメインになります。

3年前はまだZultra使ってましたかね?

ストラップホールは無いし、厚みは少し増したし、取り回しは悪くなりましたが、

現状選べる本読み端末としては良い方だと認識しています。

 

以後の記載は基本的に本端末での利用を前提としたものになります。

 

■使い勝手について(bookwalker)

 まずストアUIについてですが、元々一番使い易かったストアだけに特にこれと言って

語るべきことはありません。未だにベストなのは変わりません。

※ココ、前Twitterで書いてたことを補完します

 

次にクライアントUIですが、こちらは変わらないことが割と不満です。

Zultraを諦めたのは2000冊クラスを扱い切れなくなった重さもそうですが、

相変わらず本棚操作が手動のみなのが気に入りません。

Webからの操作だけでも良いので、もう少し手動操作を減らすように出来ないか、

という点とシリーズの自動束ね機能が無いのも相変わらず。

ebjの項で書きますが、2段構成にしたいのです。

 

最後にストア販売について。こちらは大いに不満があります。ランク制の扱いが

変わったこと(セール時に関係無くランクにより付与されるポイントがさらに追加、

という形ではなくセール時に付与されるポイントがランクによって格付け)されたこと

はまぁ許容範囲ですが明らかにセールの頻度が落ちました。最悪月1のこともあり、

囲い込みが済んでしまったかのような印象を受けます。

ポイントの期限も短いことが増えたのはライトユーザーには大きくマイナスでしょう。

 

■使い勝手について(ebookjapan)

ストアUIについては改善と改悪両面があります。

昔から言及していた一覧(平積み)上からのカート挿入、及び購入済みの表示、これが

実装されたのはだいぶ〇なのですが、最近ページ自体をリニューアルした際に

とてつもなく重くなりました。何なのアレ。Yahooがクラウド料金ケチってるの?

これが改悪。一般的なサイトと比べても明らかに遅いのでとても×。

 

クライアントUIについては・・・基本的には変わりません。一番軽く、使い易く、

機能的にも満たしています。本棚分け可、本棚分けされた中でシリーズ表示は

自動的に束ねられます。

一点だけ良く分からないのは、共有ボタンがいつのまにかどっかに消えたこと。

お勧めする際にとても不便。まったくもって意味不明。

 

最後にストア販売について。元々独自セールをあまりしない方向性のため、

Kindleと同様に出版社主導のものや、ピックアップのみのセールが大半となります。

月末にたまにセールのメールが飛んでくることがあるのですがトリガーが不明。

 

■使い勝手について(booklive)

※正直惰性でしかないので雑です。WSD+αしか使ってません

 

ストアUIについてはほとんど変わってないですね。特になし。

 

クライアントUIについても特に変わりなく。ebj同様本棚+シリーズ束ねあり。

当然SNS共有もあり。注記としてはZultraの頃はこの程度の冊数でもそれなりに

重かったこと。

 

ストア販売について。前のエントリを書いた時点でそうだったか記憶にありませんが、

Tポイントベースの付与に変わってからはebj同様の扱いに見受けられます。

1日1回引けるクーポン(ジャンルごとに10~25%程度の値引き)がありますので、

とりあえずウィッシュリストに入れといて良いのが引けたときに買う、という

スタンスが基本になると思いますが最近外れ(低還元)が増えたように思います。

 

■使い勝手について(Kindle)

※ほとんど使ってません+Kindle for PCのみの利用です

 

ストアUIは3年前からほぼ改善無く、Amazonから分離されることも無く、

購入済み表示も変わらず分かり辛いまま。要するに一番ダメなまま。

 

クライアントUIはAndroidで触れてないためノーコメント

 

ストア販売について。こちらも変わらず。セールの頻度も内容も変わらず。

いつの間にか消費税も加味されてる?ようですので他社比メリットはゼロです。

 

■現状の総括

先述の3年半前のエントリから比べて、大きく変わったことが無いように思いますが

Bookwalkerを選ぶ最大の理由であった圧倒的なお得感が薄れつつあり、クライアント

の操作感を優先しても良いのかな、と思います。

個人的にはストアUIが相変わらず圧倒的に使い易いため当面はこのままBookwalkerを

優先することにはなると思いますが、まだ揺れる余地はあります。

 

※本エントリは少しずつ改変します。

※何かツッコミあったらください

SharePoint Onlineについて調査、検討



 ・目的
  Cordova等のモバイルクライアントから非対話ベースでSharePointへログインし、
  SharePointリストへのRead/Writeを行う


 ・着手、調査
  https://blogs.msdn.microsoft.com/tsmatsuz/2013/07/11/native-application-mobile-app-azure-active-directory-login-authentication/
  oauth2手順でaccess_tokenを取得し、それを元にREST APIを実行する。
  grant_type = passwordで認証を行うことで可能だということは分かった。
  ただしこの手順は非推奨であり、二段階認証が不可となるなど考慮すべき点がある。


  この手順を行う前に、予め認証を行うための口としてのアプリを登録する必要がある。
  https://blogs.msdn.microsoft.com/tsmatsuz/2014/06/02/office-365-api/


  以下の手順でアプリに権限とスコープを定義する
  https://buchizo.wordpress.com/2017/01/25/sharepoint-online-%E3%81%AB%E3%82%A2%E3%83%97%E3%83%AA%E3%81%8B%E3%82%89%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%81%99%E3%82%8B/


 ・実行(Postman)


  ・認証を実行する
   URL:https://login.microsoftonline.com/common/oauth2/token


   POST:
   { grant_type:'password'
    , client_id:{上記アプリの登録で得たclient_id}
    , client_secret:{上記同client_secret}
    , username:{Office365のユーザ名}
    , password:{パスワード}
    , redirect_uri: {認証後リダイレクトするURL}
    , resource:{上記アプリの登録で得たclient_id}


   resourceは何を指定する必要があるのか意味不明だったが、上記で調べた通りに入れると
   「client_idと同じものを入れてください」的な英語エラーが出るのでこうしている。
   色々調べたが設定すべきパラメータがバラバラで参考にならない。


  ・実行結果
   →OK。access_token取得できる。


  ・REST API(例)
   https://{テナント名}.sharepoint.com/sites/Monaca/_api/web/lists/getbytitle('List')/items
   
   GET:
   Authorization:Bearer + " " + 認証で得たaccess_token
   Accept:application/json;odata=verbose


  ・実行結果
   →エラー。401。主旨不明。詳細不明。


   {"error_description":"Exception of type 'Microsoft.IdentityModel.Tokens.AudienceUriValidationFailedException' was thrown."}
   
   www-authenticate →Bearer realm="d6ab9302-8c72-4f6b-b728-96ba9a7642e8",client_id="00000003-0000-0ff1-ce00-000000000000",
   trusted_issuers="00000001-0000-0000-c000-000000000000@*,https://sts.windows.net/*/,00000003-0000-0ff1-ce00-000000000000@90140122-8516-11e1-8eff-49304924019b",
   authorization_uri="https://login.windows.net/common/oauth2/authorize"
   x-content-type-options →nosniff
   x-frame-options →SAMEORIGIN
   x-ms-diagnostics →3000003;reason="Invalid audience Uri 'e5cfc728-cb6b-4736-ba65-dd563042d5de'.";category="invalid_client"


 ・原因切り分け
  Postmanを使用しているからではないか、という切り分けのためにブラウザで検証


 ・実行(ブラウザ、通常のajax)
  基本的にやることは同じ。


  ・認証を実行する


   $.ajax({
    url: 'https://login.microsoftonline.com/common/oauth2/token',
    type: 'POST',
    dataType: 'json',
    data: data,
    headers: {
      'Accept': 'application/json;odata=verbose',
      'Content-Type': 'application/x-www-form-urlencoded',
    },
   }).done(function(data){
     alert("ok");
   }).fail(function(XMLHttpRequest, textStatus, errorThrown) {
     alert("error");
   })


  ・実行結果
   → エラー。
   No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null'
   内容としては表示された通りなのですが、サーバサイド(SharePoint Online)でカスタムヘッダを
   追加する手段は無いので、クロスドメイン問題をクリアしなければならない様子。
   (同一要求元ではないため、モダンブラウザはすべてこうなる)


  ・結論
   この時点で、一般的なモダンブラウザから非対話での認証+REST API実行は不可との認識。
   ブラウザでなくネイティブコードで記述する分には回避可能と思われる。


 ・他の手順で実行(SP.js) ※MS謹製のJavascriptライブラリ群


  ・認証を実行する
   MSのサイト記述、各サンプルに「認証」用の関数は明示されておらず認証自体は通常の
   Office認証画面をiframe等で表示し、セッションを確立する必要があると思われる
   ※未確認。それらしい記述ははっきりと明示されていない。


  ・REST API
   基本的には下記の手順
   https://msdn.microsoft.com/ja-jp/library/office/fp179927.aspx?f=255&MSPPError=-2147217396


   コア部
   executor.executeAsync(
   {
     url:
       appweburl +
         "/_api/web/lists/getbytitle('List')/items",
     method: "GET",
     headers: { "Accept": "application/json; odata=verbose" },
     success: onQuerySucceeded,
     error: onQueryFailed
   });


  ・実行結果
   → エラー。
   SP.RequestExecutor.js?_=1508838788373:2 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://{テナントID}.sharepoint.com') does not match the recipient window's origin ('null').
   クロスドメイン回避手順になっているはずなのに、エラーとしてはクロスドメインである旨の表示になっている。


 ・総括
  ・非対話で認証+REST API実行が可能なのか確証が取れない。
   PowerShellで同様のことを行っている例はあり、不可能ではないハズなのだが、原因を特定できない。


  ・access_token + REST API実行でのエラー('Invalid_Client')について
   額面通りに受け取ると色々な原因が考えられるが、文献が少ない・曖昧・オンプレ用語が混在しており調査が難航。


   ・考えうる理由
    ・client_idが不正
     → アプリの登録手順は他になく、これを疑っても他に試すことが無い
    ・アプリの登録が不正
     → そもそも「アプリ」という名前で「登録」しているコレが何なのか意味不明である。
       昔は「アドイン」に相当したらしいがそれそのものが処理を行うわけでもないのに「アプリ」?
       「アドイン」?
       一応疑うべき項目としてredirect_urlが意味をなさないことぐらいだが、非対話ベースなので
       これに意味があるなら成立しない
    ・アプリの権限付与が不正
     → SharePoint Onlineリソースにフルコントロールを与えてもダメなので手詰まり
    ・やはりresource_idに意味がある
     → そもそも文献がバラバラで試す余地も少ないが現状で回避できた例が上記の=client_idのみなので、
       これもここで手詰まり。


   ・この手順については凍結


  ・sp.jsでの実行エラーについて


   ・考えうる理由
    → 「認証手順を踏んでいないため」というパターンは当然考えられるが「非対話で」を
      満たさなくなるため調査する意味なし


      サンプルの通り実装しているので正直どうしろと。


  ・テクニカルサポートを利用し、そもそもの目的は「可能なのか」「非推奨のリスクは」
   は確認しようと思ったのだが、SharePoint 「Online」のテクニカルサポートを受けるには
   MSDNプレミアサポートが必要ですぐにそれをクリアできない状況。


 ・私的な感想
  ・オンプレ版SharePointでは行えていた.asmx実装も不可であったり、SharePoint Online上の
   パブリックサイトの作成も不可になったり、MSとしては「枠にはまった使い方」以外は
   あまりしてほしく無いのだろうと思う。
   実際、Flowを駆使すると割と色々出来ることは調査のついでで分かった。が今回は技術検証の
   側面が強いので手段と目的が異なってしまうためFlowを採用することは無い。
  ・各所に英語直訳と思われる表現が見られたり、オンプレ版の表現が混ざったり著しく過渡期感がある。
   サポートもSharePoint Onlineは一段上の扱いとなるため、オンプレ版でないならこのような実装は
   それらのリスクを加味して開始すべきである。

スマホコンテンツしかないやつ

 GearVR処分しちゃって用になんか適当なスマホVRヘッドセットないかなと
 思っていたのですがちょうどimpressにこんなんあったんで注文してみたんですわ
 http://k-tai.watch.impress.co.jp/docs/news/1040992.html


 GearVRとHTC Viveっつーいわゆる業界標準VRヘッドセットを使ってた/る身としては
 ちょっとどうにもならないなという評価になります。
 何がダメって頭固定出来ないんですよ。これ、直販オンリー(マケプレ等はありますが)で
 実際に試せないので一発勝負だったのですが失敗でした。


 Viveがそうなんですけどいわゆる3点式ベルト+αじゃないと固定出来ないんですよこの重さ。
 GearVRはまだマシだったんですけど現状500gレベルのヘッドセットになる以上、最低3点式じゃないと
 固定出来ないんですよ。


 ヘッドホンが一体型になってる奴が欲しかったのですがあきばおーとかで売ってる奴で
 誤魔化しといた方がまだマシだったかもしんない。


 頭が固定出来ない以外は普通に使えるのですが、逆にいうと頭が固定できないので普通に使えない、という
 評価になります。
 んー。失敗した。もう今後は何でもかんでもViveで動かせる努力をした方がまだマシだな。

サンコーの左右独立イヤホン買いました

 これ。
 http://av.watch.impress.co.jp/docs/news/1041170.html


 意外と聞ける音質でBT固有ノイズもそんなに気になりませんし、これが5000円なら
 15〜20kする他社品買うほどじゃないだろーなーとは思う。
 私の耳としてのフィット感は普通のカナル型とそれほど変わらないので
 外で使おうという気にはならないなぁ。
 (何かの弾みで落とすことはある)


 スポーツ用に買ったbackbeat Go 2と同じくらい・・・かな。
 http://www.plantronics.com/jp/product/backbeat-go-2
 これは練習場で老人のおしゃべりが煩い時に使ってますが
 ちょくちょく落とします。
 ゴルフのスイング中と通常用途(通勤時とか)では違うとは思いますが
 人とぶつかったらまぁ落とすこともあるだろうなと。


 BTイヤホンも色々使ってはきましたが結局のところイヤホンをつなぎ変えられる
 小型軽量レシーバが一番無難なのかなと今回の結論。
 MW600相当の大きさ、軽さでaptX HDなりLDAC対応の新製品出してくれれば
 ポンと買うのにな。あ、あのクソ音量キー直したうえでね。

プライム登録したしKindle Fire買いました。

 3480円とか流石にオーナーライブラリで元取れるじゃんということで
 買ってみたんだけどNexus7 2012を思わせる(今としては)野暮ったいデザイン、
 今更600ラインの解像度、2012年ぐらいのデバイスを思わせる超太幅ベゼル、
 Androidアプリ同様クッソ分かり辛い操作感、やっぱりダメなもんはダメだなぁ、
 これ8980円だったら絶対買わんわという感想。


 オーナーライブラリも「端末からじゃないと登録不可」という恐ろしい仕様で、
 且つ端末から「オーナーライブラリ対象」で絞るとそこからジャンル絞り込みも
 不可という相変わらずKindleらしい一切ユーザーのことを考えていない仕様。
 Webで調べてみましたが、いったんWebから検索して対象を絞り込んだ後、
 端末から「オーナーライブラリ」の絞り込み後、キーワード検索でひっかけろとのこと。
 前々からKindle/Amazon電子書籍の非特化はクソだクソだと言い続けてきましたが、
 やっぱりクソでした。


 ME176も長く使ってるし、部屋用の「SIM刺さらない雑に使っていい7インチ端末」の代替にならないかな
 と思いましたが無いかな。