  |
はてなキーワード: Google Playとは
7と8。
技術的なところが気になる人はこれだけ読んでくれたらいい
最後に技術的な観点からエアレペルソナが純国産ではないということを指摘する。
RocketChatという海外で開発されたOSSチャットアプリをフォーク、改変したもののよう。
ttps://github.com/RocketChat/Rocket.Chat.ReactNative
ttps://rocket.chat
フォーク元はバリバリ多国籍、外資である。(RocketChat自体は問題のないアプリであり、このエアレペルソナとはフォーク関係を超える関係はないと思われる)
冒頭のこの部分に関してである。
ttps://play.google.com/store/apps/details?id=chat.airlex.reactnative
Google Playで公開されているエアレペルソナのAndroidアプリをリバースエンジニアリングして調べてみた。
ちなみに、エアレペルソナには利用規約のようなものは見当たらず、リバースエンジニアリング禁止条項も無いようだった。
ttps://apps.evozi.com/apk-downloader/
ttps://github.com/pxb1988/dex2jar
この辺を使ってapkをダウンロードし、apkを解凍し、chat.airlex.reactnative/classes.dexをjar fileに変換した。
classes.dexから変換されたjarファイルを展開するとchat/airlex/reactnativeというフォルダ、パッケージが見つかる。
このパッケージ内のファイル(.class、クラス)がエアレペルソナの処理を行うもののようである。
このクラスをJadを使い、デコンパイルしてみた。その結果が以下である。
ちなみにここからapkをアップロードするとdex2jarをしなくてもJavaのソースコードにまでデコンパイルしてくれた。便利。
package chat.airlex.reactnative; import android.content.Context; import com.ammarahmed.mmkv.SecureKeystore; import com.facebook.react.bridge.ReactApplicationContext; import com.tencent.mmkv.MMKV; public class Ejson { private String TOKEN_KEY = "reactnativemeteor_usertoken-"; String cardId; String host; String messageId; String messageType; /* access modifiers changed from: private */ public MMKV mmkv; String msg; String notificationType; String rid; Sender sender; String senderName; String type; public Ejson() { ReactApplicationContext reactApplicationContext = CustomPushNotification.reactApplicationContext; if (reactApplicationContext != null) { MMKV.initialize((Context) reactApplicationContext); new SecureKeystore(reactApplicationContext).getSecureKey(C0617Utils.toHex("com.MMKV.default"), new RNCallback() { public void invoke(Object... objArr) { if (objArr[0] == null) { MMKV unused = Ejson.this.mmkv = MMKV.mmkvWithID("default", 1, objArr[1]); } } }); } } public String getAvatarUri() { if (this.type == null) { return null; } return serverURL() + "/avatar/" + this.sender._id + "?rc_token=" + token() + "&rc_uid=" + userId(); } public String token() { String userId = userId(); MMKV mmkv2 = this.mmkv; return (mmkv2 == null || userId == null) ? "" : mmkv2.decodeString(this.TOKEN_KEY.concat(userId)); } public String userId() { String serverURL = serverURL(); MMKV mmkv2 = this.mmkv; return (mmkv2 == null || serverURL == null) ? "" : mmkv2.decodeString(this.TOKEN_KEY.concat(serverURL)); } public String privateKey() { String serverURL = serverURL(); MMKV mmkv2 = this.mmkv; if (mmkv2 == null || serverURL == null) { return null; } return mmkv2.decodeString(serverURL.concat("-RC_E2E_PRIVATE_KEY")); } public String serverURL() { String str = this.host; return (str == null || !str.endsWith("/")) ? str : str.substring(0, str.length() - 1); } public class Sender { String _id; String username; public Sender() { } } }
フィールド名を見てみると、cardId, host, messageId, messageType, mmkv, msg, notificationType, rid, sender, senderName, typeが存在する。
メソッドには、getAvaterUri、token、userId、privateKey、severURLが存在する。
ところで、RocketChatというOSSのチャットアプリが存在する。
ttps://rocket.chat
そのRoketChatのAndroid実装の中に同名のEjsonというクラスが存在する。
ttps://github.com/RocketChat/Rocket.Chat.ReactNative
ttps://github.com/RocketChat/Rocket.Chat.ReactNative/blob/develop/android/app/src/play/java/chat/rocket/reactnative/Ejson.java
見比べてみると、フィールドにcardIdが追加されている以外はフィールドやメソッド名、そしてその処理の内容まで一致している。
他にもReplyBroadcastなど、同様のクラスがエアレペルソナに見つかる。
以上のことからエアレペルソナはRocketChatをフォークして、パッケージ名を変えて作られたチャットアプリであり、開発の大部分はRocketChat社の努力と多数のOSSコントリビュータによってなされたものであると思われる。
そもそもこのOSS時代に純だの何だの言っている時点で怪しい。
さて、エアレペルソナがRocketChatをフォークして作られたものであるとすると、気になるのはライセンスである。
RocketChatのOSSライセンスはMITライセンスである。
ttps://github.com/RocketChat/Rocket.Chat.ReactNative/blob/develop/LICENSE
MITライセンスは非常に緩いライセンスであるため、エアレペルソナの様にフォークして別のアプリケーションとして公開することにはおそらく問題がないということは強調しておく。
現状エアレペルソナにログインできておらず(2要素認証のコードが送信されないといった問題が起きている模様)、使用している各OSSのライセンス表示が適切に行われているかまでは調べられていない。
最初に結論から書くと、「毎日新聞さん正論すぎる」「だけどまだちょっと時間あるで」。
『「COCOA」がグーグルとアップル基本ソフト最新仕様に未対応』
→ https://mainichi.jp/articles/20210315/k00/00m/020/165000c
うん。コード見てる人はだいたい知ってる。
まあ、そうですね…。
COCOAの動作の基盤となっているのは、Exposure Notification API（曝露通知API）というやつで、GoogleとAppleが共同で開発した、AndroidとiOSの両方で使えるAPI。OSと近いところで動くライブラリみたいなもので、おかげでBluetoothを使っても電力消費は最小限で済むし、アプリがプライバシー関係でよからぬ手出しができないようにもなってる。iPhoneではiOSの一部として組み込まれているし、AndroidはGoogle Play経由の「Google Play 開発者サービス」の新しい版に含まれてる、みたい。
このAPIにはバージョンがあって、V1ってのが最初のやつで、もう少し検出方法が洗練されたV2ってのがある。Exposure Notification APIのセットの中にV1とV2が重複しつつ混在してて、今から作るアプリなら使えるAPIバージョンをアプリ側で確認して、使える方を使う、という感じになるかと思う。
現在、COCOAがまがりなりにも動いていることからも分かるように、API V2が使えるようになっても、後方互換性のためにV1も使えるようになっている。Apple/GoogleはV1のメソッドとかには「deprecated」（使用不可）っていう印をつけて、今後は使わないように、と言ってる。
「deprecated」になったやつは、Apple/Googleは「もう使わんでね。いつ使えなくなっても文句言わんでね」という扱いをする。だから、「ソフトの更新次第で作動停止」という指摘は間違いではない。間違いではないが…。
Apple/Googleのデベロッパならよく知っていると思うけれど、「deprecated」になったからといって、そのAPIを予告なく使えなくすることは、まず、ないのです。
増田はIOSのデベロッパなのでiOSの例をあげると、画面を表示する基本的な部品であるところの UIWebView っていのうがあったんだけど、これはiPhone OSの頃からあった古い古い部品で、これまでずっと使われてきた。これはwebの画面を表示するのと同じやりかたができるので、iOSのアプリはほぼみんな使ってたんだけど、いろいろ問題もあるので、iOS 8の頃に WKWebView っていう新しい部品を出したのです。で、UIWebView をdeprecatedにしたのがiOS 12のとき。
ここからAppleは、「UIWebViewを使ったアプリをApp Storeに提出したら警告するからね」→「今後新規アプリやバージョンアップのときUIWebView使ってたらリジェクトするからね」→「UIWebView使ってるアプリはAppStoreから削除するからね」という感じにデベロッパの様子を見て期限を延長したりしながら段階を踏んで、ほんとに削除（一時的な非表示）始めたのは去年の12月ですよ。しかもiOS 14でもまだ既存アプリのUIWebViewは動く。
もちろん、滅茶苦茶使われていたUIWebViewと比べたら、Exposure Notification APIみたいなマイナーなAPIでこんな丁寧なことはやらないかもしれないけれど、でも重要度で言ったらExposeure Notification APIなんて「超重要」でしょ。V1が全然使えないならまだしも、一応動いてるし。
Exposure Notification API V1は、使えなくなる前には必ずデベロッパに期限を知らせるはずで、いきなり切るはずはない（ないよね（ないんじゃないかな（まちょっと覚悟はしておけ）））。
だから、COCOAが急に使えなくなっちゃう！ と不安になる必要は、当面はないと思っていい。かな。
これはスレたデベロッパであるがゆえの油断であると言われてしまえば、そのとおりです。「deprecated」は「deprecated」。普通のプロジェクトなら、すぐさま対応を検討して、バージョンアップ計画を立てるのが正しい。普通のプロジェクト、なら。
記事中では「21年2月になって、ようやく最新使用に対応するための具体的な検討に着手した」って言ってて、まあこれはダメなんだけど、そもそもプロジェクト運営がグダグダだったんでしょうがねーんじゃね？ というのがいちヲチャーとしての感想ではある。だって、Android版動いてなかったんじゃよ？ プロジェクト立て直す時間はあるはずなので、体勢立て直してから検討してもいいかな、という気はしている。それくらいの時間はある。はず。
そういう意味で、毎日新聞の記事はちょっと叩きすぎな感はある。正論ではありますよ。正論では。
で、ここでぶっちゃけてしまうと、実はもうCOCOAは要らないっちゃ要らないのです。
保健当局がアプリを作れない／作らない国／地域のために、iOSでもAndroidでも、AppleとGoogleが用意したCOCOA相当機能「Exposure Notification Express」というやつが、OSに組み込まれている。これを使うことにすれば、当局はサーバ側のバックエンドだけ用意すればいい。
『グーグルとアップルの新型コロナ接触確認機能に新たな仕組み「Exposure Notification Express」――日本には影響なし』
→ https://k-tai.watch.impress.co.jp/docs/news/1274374.html
『Supporting Exposure Notifications Express』
「だけ」って簡単な言うな。そりゃ大変だけろうれど、わざわざ使いづらい／どマイナーなミドルウェアXamarin（Microsoft謹製）使って、頑張ってクロスプラットフォームなアプリを開発／運用するよりはずっと負担は少ないよね（必要な予算も）。
もう、バンザイして、Expressにしたらいいんじゃね？ と、増田は考えるんじゃよ。知らんけど。
COCOAは嫌いになっても、Exposure Notificationの仕組みは嫌いにならないでください…(´・ω・`)
COCOAは出自がアレで、採用の意思決定が不透明で、契約もテキトウで、アプリ運用も誰が何をどうしたらいいのかわかってない／身動きができない、という悲惨なアプリです。
でも、2月以降変わってきたんですよ。COCOAの立て直しチームにCode for Japanの人やオープンソースの知見を持った方が参加して、githubでのissue解決の動きも再開している。ちょっと見てみてくださいよ、いろんな人が寄ってたかってコードを検証して、それが反映されつつあります。
『Issues・cocoa-mhlw/cocoa・GitHub』
→ https://github.com/cocoa-mhlw/cocoa/issues
いままでよりはまともに動くようになるはず。
前述のように、Exposure Notification APIで消費されるCPU資源も、通信も、ストレージも、バッテリも微々たるものです。
Exposure Notification API自体は非常によくできており、プライバシーに関しても、よくまあここまで、というくらい考慮されています。アプリ側でいろんな悪さを仕込むことは技術的には可能ですが、小細工を仕込んでもAppleやGoogleのアプリ審査で弾かれます（通常の小細工入りアプリが弾かれる程度には）。運営への不信からプライバシーについても疑ってしまう人もいるけど、COCOAはその点まず心配ありません。
だから、渋々でいいので、もうしばらくスマホの奥においといてもらえませんか。そんなにお邪魔にはならないですよ？
そして万が一曝露通知が届いたりしたら宝くじ大当たり級の驚きが（うれしくない）
さて諸君、胡桃ちゃんと護摩の杖、最低1つずつは確保できたかね？
男女だセックスだ差別だ、カネだコインだ格差だなどと世迷い言に明け暮れて、人生における最大の幸福である原神プレイ、すなわち伝説任務の読破と祈願と樹脂消費と日々の鉱石・聖遺物拾いと公式動画チェックとファンアートチェックを疎かにしていてはいかんぞ。この作品に限っては情報ソースは世界中にある。人生1つでは足りない深みを前にして、目を滑らせてなぜか掃除を始めるようなムーブをいつまでもしていてはならんぞ。さあ、今こそがっぷり4つに取り組むべきだ。まずはランチャーのアップデートから始めようではないか。次にVer.1.4の事前ダウンロードだ。こうして予めDLしておくことで、負荷分散に協力することになり、諸君の行動が世界に平和をもたらすのだ。ちなみに我は先程駆け込みで護摩を引いてきたところだ。Google Play Pointsちゃんが最近なかなか原神を対象にしないから課金タイミングを逸していたのでな。それでも我は勝ったぞ。確定ピック75%の半分であるからして…37.5%の勝負に勝ち、一発で護摩を迎えたのじゃ。しかし突破素材はすでに辛炎ちゃんに持たせた紀行大剣を90にするのに使い果たしてしまった。我のVer.1.3は隕鉄が掘れる水曜日にやっと始まる。ってその日は奇しくも1.4アップデート日ではないか。まあそんなことはどうでもいいのだが、胡桃ちゃんのぶっとんだ個性に馴染んでしまうと辛炎ちゃんのような褐色トゲトゲロッキンガールも全然可愛く見えてしまうの。いや実際かわいい。前から見たときの目つきは多少強面だろうとも、後ろから眺める肢体の動きは間違いなく女の子のそれだ。それはそれとして胡桃ちゃんである。今まで香菱――同時ピックであり同じ火属性の槍使いということでにわかに偽胡桃扱いされだした不憫な子、しかも設定上でも胡桃の悪戯対象という――の装備を使いまわしていた為、チャージ槍と魔女2剣闘士2で適当にぶん回していたのを、まだLv20の護摩と魔女4に変更したのだ。典型的な胡桃のビルドではあるが、この魔女4を活かそうと思うならやはり元素反応を意識して立ち回りたくなるところ。となると水や氷キャラなのだが、一応モナや甘雨は持っているものの、やはりどう考えても行秋や重雲が相方にピッタリなのだ。だが我は野郎ガチャは全力スルーしてきた漢。それでもなぜか行秋が完凸しているが、いくら強くて便利と分かっていても育成を始める気になれない。うっかり引いてしまったタルタルでさえろくな装備を与えられないままLv50で埃をかぶっている有様なのだ。男キャラに慈悲を与えるほどには樹脂の余裕がなさすぎる。そういう意味でも、諸君らにはここでうつつを抜かして樹脂をオーバーフローさせている場合ではないことを伝えておきたく筆を執った次第なのである。
一般的なスマホアプリの場合はGoogle PlayやApp Storeといったストアを通してアプリの更新を比較的手軽にできるので、比較的簡易な手動テストや自動化テストなんかでも充分なケースも多いです。
市場で不具合が出ても修正したアプリを配布すればいいため、不具合が発生した場合の損失（例：Eコマース系アプリならショッピングができなかったことによる金額的損失など）とテストのコストを比較して、簡易なテストでも間に合うと判断するケースが少なくありません。
実際には機種数×OSのバージョンが多すぎてまともにやると大変なので、現行の人気のありそうな機種だけで検証して、市場で何かあったらその時に対応することも多いです。
このあたりは組み込みやハードウェアのソフトとはコスト感覚がことなるのは事実です。
とはいえCOCOAアプリは「一般的なスマホアプリ」ではありませんし、命を扱うソフトウェアということもあり、明らかに上記と同じような対応をすべきではありません。
実機テストはもちろんのこと、Bluetoothの通信を扱うということもあり、複数の機種でのテストを慎重にすべき対象です。
ウェブ系やスマホアプリ界隈ではこのような命を扱うレベルのソフトウェアを開発したことのある人や組織は少ないですし、界隈がそういった開発に慣れていないということはありそうです。
別にTVが無い事自体はおかしくないけど、大画面で見たいときにわざわざモニターを選んでも、あんまりコストメリットがないというか。
40インチとか50インチなら、配信用モニターとしてもTV機器のほうがコストメリットが大きい。
チューナーは必須でないがあえて外すことにこだわるより、ついてて安くてキレイで入力端子も多く、ゲーム機用モニターとしても切替機とかいらないし、最近のAndroid TVなら FireTV とかさえ要らない。さらにFireTVでは使えないGoogle Playのアプリが使えたりもする。リモコンで操作できるのも便利だ。Android TV は FireTVより便利なのでFireTVは初期化して人にあげた。
TVがないPRする人でも何らかの映像配信サービスは使ってる場合がほとんどだろうし、映像配信サービスオンリーだとしてもTV機器のほうが安くて多機能。スピーカーしょぼいと言われてもそれでもモニター内臓のスピーカーとかよりは十分な音出るし。
高くて低機能な機器をあえて選ぶというのはよっぽど強情な変人か情弱なんで、それで情強気取りするのが失笑なんだよ。
うちはTVはあるけどTV放送のチューナー機能は殆ど使ってない。でも繋いではいる。役に立つこともあるので。
いやはやまったく、はてブにあがってたので読んでしまったが、久々にあまりにも酷いレビューを読んでしまった。あぁそうそう引用している記事にはアクセスしなくても良い。時間とトラフィックリソースの無駄だ。
記名は編集部となっているが、Business Journal編集部員の質はこの程度なのか？まるで「私たち編集部はWeb検索すらしないで又聞きした情報を記事にしています」と宣言したいがために記事を公開したのかと邪推したくなる。
1つの記事へ膨大な時間を掛けて執筆することは生産性を考慮すると悪手であるのは間違いない。しかし、いくらなんでも"ほど"があるだろうと言わざる得ないのだ。
下記の理由からBusiness Journal編集部は当該記事の編集部員へ二度とゲーム記事は書かせないほうが良いと"ご意見"をよせさせて頂く。
当該記事では太正100年が既存のサクラ大戦シリーズとの歴史的連続性の無さを指摘しつつ、蒸気エネルギーが排除され主要エネルギーが採用されたことへ対して非難の声がよせられていると書いている。
しかし、太正100年は西暦で言えば2011年である。半世紀以上の時間が経過していながらサクラ大戦シリーズはいまだ蒸気エネルギーへ依存し続けなければならないと本気で思っているのだろうか？
そして、歴史的連続性の無さを指摘しているが現在公開されているサクラ革命のシナリオは、チュートリアルと九州編と中国編(そして九州を舞台としたサイドシナリオ特別イベント)のみだ。
サクラ革命は47都道府県を舞台としようとしているのは現状で明確にわかる。つまり素直に受け止めれば45シナリオが残されている。全体のシナリオ進捗は約4.25％であり、この状況ではサクラ革命がサクラ大戦シリーズでどういう立ち位置なのかほぼわかっていないとWeb検索するまでもなく察することが出来るので、なぜこれを"爆死＆大炎上"の理由としたのか本気で謎である。
サクラ革命を現状で物凄くやり込んでいるプレイヤーすら何もわかっていないのに、何をわかったつもりで居るのか。
サクラ大戦シリーズにおいて蒸気エネルギーは主要エネルギーとして確かに重要であり、サクラ大戦シリーズを彩るスパイスとして無くてはならない存在であるのは間違いない。
しかし、サクラ大戦シリーズにおいてスチームパンクはスパイスであってメインの素材ではなく、あたかもサクラ大戦シリーズはスチームパンクだからこそ支持されていたかのように描くのは誤解である。
サクラ大戦シリーズファンへはわざわざ説明するまでも無い話だが、申し訳ないけれども知らない読者のためにも付き合って頂きたい。
端的にかつ簡潔に述べるならば、サクラ大戦シリーズは「アイドルマスター」シリーズのご先祖様である。
サクラ大戦シリーズは宝塚歌劇団をパロディした作品であり、その痕跡はキャラクター名や帝国華撃団など各名称に現れており、歌って踊り、企画段階で強くメディアミックスを意識され、当時の声優業界すら巻き込んで現在にもその影響を残しているターニングポイントだった作品だ。
霊子甲冑のデザインを著名なメカデザイナーが手がけているなど日本のSFとして決して軽視できるものではないが、宝塚歌劇団のパロディとしてゲームに落とし込んだという要素に比べればスチームパンク要素は些細と言って過言ではない。
だから「戦うアイマス、アイドルマスター XENOGLOSSIAかよ」と一部のユーザがそう感じてしまうのも仕方ない。ご先祖様なのだから。
ついでに誤解なきよう言及しておくと、蒸気エネルギー要素はディスコンされていない。当該記事の書き方では蒸気エネルギーがディスコンされてしまったものと誤解する読者が出てきそうなので。
これにはサクラ革命プレイヤーとプロジェクトセカイプレイヤーの双方が怒って良い。というか既に怒っているだろう。
どういう神経でプロジェクトセカイを持ってきたのか呆れて果ててしまう。
現代のサブカルシーンでは主題のコンテンツを貶めるため他のコンテンツを持ってくるのは禁じ手とする傾向が強くなってきているのを読み取れていないのか。
作品Aはカワイイ、作品Bもカワイイ。どっちもカワイイ。どちらがカワイイのではないどちらもカワイイ。
これが現代のサブカルシーンであり、当該記事の書き方はまるで10年前のゲームハード戦争真っ直中の素人レビューのようだ。
他のコンテンツを貶める暇が在るなら推しコンテンツを布教しろ。
Business Journalとかいう質が低すぎる文字同人サイトの誤りを指摘したので、次は実際にサクラ革命プレイヤーである筆者がサクラ革命が非難される理由を書こう。
ネタバレになるので詳細は控えるが、サクラ革命で現在配信されている3つのメインシナリオであるチュートリアル、九州編、中国編すべてでお涙頂戴が展開される。
しかもお涙頂戴の起因が3つとも同じだと言って良い。どれだけライターはこのシチュエーションが好きなのか。流石に3連続、というか配信されているすべてのメインシナリオがコレなのはおかしいだろう。
この繰り返される同じお涙頂戴シチュエーションについてはTwitterでちょっと検索するだけで出てくるので当該記事を書いたBusiness Journal編集部員はおそらくWeb検索すらしてないと思われる。
Twitterユーザーの100文字に満たないツイート、例えば「お涙頂戴繰り返すからサクラ革命のシナリオは微妙」みたいなレビューよりも質が低い上に、あれだけの文字量なのだから執筆時間もTwitterユーザーのツイートより掛けているだろうから生産性まで低い。圧倒的な質の低さである。お前Twitterユーザー以下だぞと。
サクラ革命の戦闘シーンで敵ユニットが毎ターンほぼ確定で自ユニットへ弱体化補正(いわゆるデバフ)を決めてくる。
つまり、敵ユニットが自ユニットへ対して攻撃力や防御力、必殺技ゲージの低下を(自ユニットが弱体化耐性を持っていない限り)毎ターンほぼ確定で決めてくるのだ。
ディライトワークスが開発するスマートデバイス向けの別ゲームタイトル「Fate/Grand Order」のプレイヤーならば慣れているゲーム設計と言えるが、ディライトワークス製ゲームを初プレイするプレイヤーに取っては不快なゲーム設計だろう。
サクラ革命はスマートデバイス向けRPGでありがちな、いわゆる「育成周回」が必須のゲーム設計となっている。
そしてサクラ革命には攻略ステージ毎へ親切にも自ユニットの適正レベルが記載されているのだが、どうやらこれは自ユニットの攻略ステージ開始時の初期ステータスを基準にしているらしく、適正レベルへ至っていてもターンが進む毎に敵ユニットから弱体化補正をかけられ続けると攻略が困難になってくるのだ。
当然、非常に高度な立ち回りをすると苦戦しつつも結果的に勝利を収められるが、忘れてはならないのがサクラ革命は「育成周回」が必須のゲーム設計なのである。
「育成周回」しなければならないのにターンを膨大に重ねるのは非効率なので、ここに矛盾が生じて慣れていないプレイヤーはストレスを感じてしまう。
「Fate/Grand Order」プレイヤーはこのゲーム設計に慣れているので即座に「最短ターンで編成を組むのがサクラ革命の最適解」と察して行動を取れたが、ディライトワークス製ゲームを初プレイしたプレイヤーはより一層のストレスを抱えているだろう。
これは完全にディライトワークス製ゲームのプレイヤー間の内輪ネタだが、ディライトワークス製ゲームにとってバグは"お家芸"である。何も笑えないが、ネタにして笑い飛ばすくらいの胆力がないとディライトワークスには付き合っていられない。
「Fate/Grand Order」でもローンチ直後から様々なバグがあり、その伝統は本作にも引き継がれ、大いにプレイヤーを笑わせてくれている。・・・その笑いは失笑かも知れないが。
筆者が笑ってしまったのはローンチ初日、サクラ革命もアプリ初回起動後に追加データダウンロードというゲーム系アプリにはありがちな仕様(初回起動時に追加データダウンロードが発生するのは各アプリストアの仕様上の制限である)で、ダウンロードプログレスバーが表示されている間に、登場キャラクターの簡易プロフィールが読めるという演出になっていた。ダウンロード中にプレイヤーが飽きてしまわないよう配慮された仕様だ。
しかし、この簡易プロフィールのデータがどうやら初回起動後の追加データに含まれていたらしく、1人目以降まったく簡易プロフィールが読めないというバグがあった(現在は修正済み)。ゲームプレイする前からわかりやすいバグが発見できる。これがディライトワークス。
サクラ革命を実際にコーディングしている開発者からすると変な汗が出る初歩的なバグであるのは筆者も情報技術者の末席に連ねる者としてお察し出来るので心身痛み入る、まぁそういうこともあるさという言葉を送りたい。
こうやってディライトワークス製ゲームプレイヤーが開発元ディライトワークスをイジるのが内輪ネタというわけである。
「Fate/Grand Order」のバトルシステムは登場当初スマートデバイスでもバトルっぽいことができると示した素敵なエコシステムだが、サクラ革命のバトルシステムはそのエコシステムのエコさ加減を最大限に活かしつつ、ちょっと戦略性を上げましたというバトルシステムである。
サクラ革命という新しいゲーム開発へ関わったのだから「もうちょっとなんかあったやろ」というツッコミが方々から聞こえてくるが筆者としては1周回って「ディライトワークスだしコレで良いんじゃね？」と思えてきている。
詳細なバトルシステムが気になる人はYoutubeか何かで観たほうが早いだろうし割愛する。所詮はポチポチゲーですよ。
筆者としては歌劇シーンを観ることができると思ってサクラ革命をインストール事前予約してまで期待して待っていた(ディライトワークスなのでバトルシステムは鼻から期待してない)のだが・・・観れないんだなぁ・・・(遠い目)。
いやコチラが勝手に期待したのが悪いっちゃ悪いんだが、3DCGでやるって言うんだもんアイドルマスターみたいな歌劇シーンを期待しちゃうじゃないですか。もしかしたら初代サクラ大戦のメンバーとかもスペシャルゲストとして動いてる様子が観られるとか思っちゃうじゃないですか。
このあたりが怨嗟を生んでる気がするんですけど、ディライトワークスさん1周年イベントで良いんで歌劇シーンやりましょうや。
悪いところばかり挙げるのもアレですし、とりあえずプレイせず様子見している"司令"も居るでしょうから良い点も挙げておく。
初代サクラ大戦のイメージを引っ張っている司令からすると違和感が物凄いけれども、慣れてくるとこれはこれで良いものなのではないかと思えてくる。
ただモーションは固定なので高く期待するほどでも無い。
サクラ革命ではガチャゲーで、アイテムや装備も一緒に排出されるいわゆる"闇鍋ガチャ"であるが、☆5キャラの排出率が恒常ピックアップ☆5キャラが0.375%で「Fate/Grand Order」と比較すると悪くはない(FGOの恒常ピックアップ☆5キャラは0.029%)。
筆者もそうであるが、コレクター的な性質を持つプレイヤーならば出費少なく結構簡単に現行でガチャ実装されているキャラが揃ってしまうので、その辺は気持ちよさがある。
ちなみにガチャで所有キャラが被ると必殺技の性能が向上するという仕様。最大でLV20。
前述したとおり、ガチャで所有キャラが被ると必殺技の性能が向上するという仕様だが、ガチャでなくとも必殺技の性能を挙げるためのアイテムが存在する。
いわゆる"箱推し"でなく"嫁"を愛でる性質を持っているプレイヤーであるのならば自由意志で集中してアイテムリソースを注ぎ込むことが可能だ。
一部の読者からすると途端にマニアックな話になって申し訳ないが、サクラ革命はChrome OSのAndroidエミュレータで動作可能で、Chrome OS上のGoogle Play Storeで普通に配信されている。
これはおそらくAndroidアプリ開発の統合環境Android Studioの仕様で、デフォルト設定だとChrome OSでの動作が許可されているためだ(ちなみに「Fate/Grand Order」も動作する)。
筆者は細かな検証をしていないが、どうやら新しいApple Sillicon M1を採用したMacでは動作しないようなので、この点だけはほんの少し新しいMacbook Airよりも一歩、いや半歩だけ進んでいると言って良い。
ただ、どうやら配信されるバイナリはARMアーキテクチャ向きのものであり、x86(x86_64)アーキテクチャ向きのものではないようで、そのためかレンダリングへ一部不具合を抱えている上に動作が重い。これが半歩の理由。
Chrome OS上でサクラ革命の動作を検証した筆者のChrome OS環境で最大スペックのものはCPUがCore i7-10510U(第10世代)でワーキングメモリ16GB、M.2 SSD 512GB(PCI Express 3.0)であり、それでも「軽快さはないがプレイに全く支障はない」くらいの重さを感じるので、現状でサクラ革命をChrome OSでプレイするならこの程度のスペックは必要になると思われる。
情報技術者としては今後デスクトップおよびラップトップコンピュータでスマートデバイス向きアプリケーションが動作するのが一般的なのは目に見えているので、アプリ開発者はデスクトップおよびラップトップ向きのハードウェアサポートを検討する時代へ突入し始めていると多少の意識を向けたほうが良いのかも知れない。
例えば、各アーキテクチャへ最適化されたバイナリや、スマートデバイスではあまり意識されてこなかったハードウェアキーボードのサポート、シングルタップ時とマルチタップ時のトラックパッドの振る舞いの違い、変動するアスペクト比など挙げればキリはないので頭が痛い話だ。
<
コインドーザーというスマホゲーを久々に始めた。どういうゲームかっていうと、ゲーセンによくあるメダルゲームを模したものだ。コインを入れ、場にあるコインを落として手に入れる、その繰り返し。脳死ゲー。パチカススロカス以下、底辺の娯楽、ポチポチゲー。昔は無課金で延々遊べたが、今はすぐ原資のコインが尽き、課金・動画広告の視聴・別アプリのインストール&何らかのアクションを迫られる。
動画広告では別のゲームアプリが宣伝される。見終わればキャンセルしても報酬を得られるわけだが、わざわざ広告費を出してよそのゲームで宣伝するほどのゲームということなのか。よほど魅力的で、開発費も広告費もかかったリッチなゲームで、始めたらどんどん散財したくなっちゃうようなゲームなのだろうか。
めちゃくちゃ課金を迫ってくるのか？あるいは個人情報の収集を目的としてやたらとアクセス権限を要求してくるタイプか？
前者だとしたらGoogle Play Storeの支払を確定しなければ金銭を失うことはないし、後者だとしたらAndroidの権限付与ダイアログで拒否すれば被害はない。
動画でやたら出てくるアプリ、トゥーンブラストというゲームを入れてみた。アメリカンなアニメ調の劣化パズドラといった雰囲気。パズドラのように余計な演出がなく、シンプルでよい。それは良いがぜんぜん課金を迫ってこない。たまに課金ポイントらしきものはあるが、むしして遊びつづけられる。別に面白くもないのだが。同じ面白くないならコインドーザーのほうが俺は好きだ。このアプリの素性を把握するというミッションを完了したらとっととコインドーザーのケチ臭い動画広告視聴作業に戻りたいのだが、金も個人情報も要求してこない。
トゥーンブラストについてTwitterで検索してみると、プレイヤーはちらほらいるようではあるが熱心に遊ばれている感じではない。ググっても攻略ウィキなどない。広告と内容が異なる、詐欺だ！けどゲームとしては遊べる〜といった評価。誰もまともにプレイしてない。とても儲かっているようには思えない。
ゲームは進む。面白くないが、ちゃんとパズルゲームだ。ステージごとに新しいギミックが出てくる。どこかで見たような仕掛けでなんの感動もないが。
もういい。コインドーザーに戻る。インストールまでしたのだから報酬は少し高いかもしれない。…と思いきや、4コイン。普通に時間経過でもらえるだけのコインでは？？
もう、よくわからない。アドネットワークでゲーム同士・アプリ同士が、ゲーム内の報酬を餌に他アプリのインストールを勧め、しかし勧められたアプリの中でも特に金を取られるでもない。こちらのアプリもプレイヤーの原資が減ってきたらまた広告で別のアプリに誘導するのだろうか。俺がそこまで辿り着いてないだけなのか。
このアドネットワークで開発者たちはどう儲かってるのか、ホイホイ乗っかったらプレイヤーはどんだけ金取られるのか、上流に近いところにいる企業ってのはどんな有名アプリを出してるとこなのか、あたりが気になって調べてみたかったんだが、ムリ。飽きた。2ホップ目で飽きた。詳しい奴いたら教えてくれ。
https://anond.hatelabo.jp/20200831191205 の続き。
今回、Googleから理不尽な要求を受けたアプリのうちの一つであるFedilabが呟いていることがあったのでこれを翻訳・解説していきたいと思う。
Other app developers maintain that this blocking doesn’t fit Mastodon’s mission. The Android-based Fedilab app’s free version initially blocked Gab because of Play Store content policy fears. But the ban has since been lifted. “I will simply not block instances with the app,” wrote Fedilab’s developer. “I clearly think that’s not my role … If you want a strong block, it’s in the hands of social network developers or your admins.”
-----
How the biggest decentralized social network is dealing with its Nazi problem
翻訳：
このブロックはMastodonの使命に反すると主張しているアプリ開発者もいる。 Androidで動くFedilabアプリの無料版は、Google Play Storeのコンテンツポリシーに抵触する懸念から、最初はGabをブロックしていた。 しかし、ブロックはその後解除された。「私はただアプリでインスタンス（サーバー）をブロックしないだけです」とFedilabの開発者は書く。 「それは私の役割ではないことは明らかです…。もしあなたが強力なブロックを必要とする場合は、その選択はソーシャルネットワークの開発者またはあなたのサーバー管理者に委ねられます。」
この記事はGabがMastodonをフォークしてFediveseに参入してきたときの記事である。Fedilabの開発者は当初GabをクライアントであるFedilab自体でブロックするようにしたが、その後改めてブロックを解除した。Mastodonが掲げる自由の理念を尊重したのである。Mastodonの創始者のEugenは当時、自分のFedivese上のアカウントで強い口調でMastodonサーバーの運営者とクライアント開発者に対してGabをブロックするように呼びかけたが、この行為自体がMastodonの理念に反しているように自分は感じた。Eugenはドイツ出身であり、Gabを全く許容しない社会で育ったのだろうど推測されるし、Mastodon創始者としてGabを許容しない姿勢を打ち出すことに意味があったのだろうと思われる。
If Google does not want to listen to my explanations, I will not change the app for them.
The way they are acting is unfair and don't give any trust concerning next publications.
I prefer to spend my time to help people to switch on #FDroid for getting the app.
#Fedilab
-----
Imagine a day, where asking a dev to restrict their app to some people is a normal behavior. Today, maybe 99,9% don't care due to the target. But what's next?
Do you like to choose freely an app with your needs or choose your needs due to apps?
翻訳：
Googleが私の説明を聞き入れない場合は、アプリを彼らのために変更しません。彼らのやっている行動は不公平であり、続くリリースに関していかなる信頼も与えません。私は、人々がGoogle Play StoreからF-Droidに切り替えてアプリを入手するように助力することに時間を費やしたいです。
アプリ開発者にアプリを一部のユーザーに制限するよう要求するのが通常の行動である1日を想像してみてください。 今日において、おそらく99.9％がターゲットのことを気にしないでしょう。 しかし、将来的にはどうでしょうか？あなたのニーズに合わせて自由にアプリを選択しますか、それともアプリによって自分のニーズを変えますか？
日本時間9月2日現在、Googleから要求を受けているアプリは対応せず7日間経過するとGoogle Play Storeから削除されるが、まだ7日間経過していないため現時点ではGoogle Play Storeから削除されていない。MastoPaneの作者は異議申し立てをしたが否認されたため自分からアプリをGoogle Play Storeから削除した、と呟いている。これからの展開はどうなるのかは分からないが、大きな流れとしてはGoogleの要求を受け入れることなく自分たちの理念を貫くだろう。というかそもそも理不尽な要求で、Googleの行動は根本的に間違いであるから対応する必要性がないのだが。Google Play Store上ではGoogleの言うことが絶対だから仕方ないね。
昨今はAppleのApp StoreやGoogleのGoogle Play Store上での問題が注目を集めている。大きな組織によって自分たちの首根っこが抑えつけられ自由を侵害されるというのは今に始まったことではないが、ここに関する反発は日々強まってきていると感じる。大きな組織がさらなる大きな力を持ち、中央集権を強めるなかで我々が模索し目指さなければならないのは脱中央集権、非中央集権である。自分たちの在り方は自分たちで決めるし自分たちの個人情報は自分たちに権利があるのだ。
Mastodonという非中央集権なSNSがある。プロジェクトはオープンソースで誰もがMastodonのサーバーをホストすることができる。このサーバーたちは相互に繋がることができるので違うサーバーであってもメッセージを送り合うことができる。
今回問題になったのは、Google Play上で公開されているいくつかのMastodon向けクライアントだ。これらのアプリはGoogleの主張によれば「ヘイトスピーチ」に関する内容を含んでいるため改善しろ、というものであった。クライアントはただサーバーにアクセスするだけである。ユーザーがアクセスしているサーバーにはGoogleが指摘するようなヘイトスピーチを扇動するようなサーバーがあるかもしれないが、それを理由にGoogleが該当サーバーをホストしている訳ではないアプリ開発者に対して改善をするよう脅迫するのは理不尽である。彼らのGoogle Chromeでもこれらのサーバーにアクセスすることは可能であり、ただクライアントがWebページを表示しているのとなんら変わりない。Googleの主張からすれば、彼らのGoogle Chromeも同様に取り締まられるべきだ、と言えてしまう。
今回の問題は既に一度議論されたことがある。Gabという極右コミュニティがMastodonを使ってMastodonを始めとしたネットワークに参入してきた。これを機にMastodon創始者のオイゲン氏はGabをサーバー管理者やクライアント開発者に排除するよう呼びかけた。サーバー管理者やクライアント開発者はGabをブロックしたりしなかったりした。サーバー同士で繋がることができると言っても例えば日本語と英語とで言語圏の違ったりと接点が無い場合はわざわざブロックする必要はないだろうということだ。またはサーバー管理者がわざわざブロックしなくともユーザーが各自に対応する自由な判断に任せるということもある。クライアントはただサーバーにアクセスするだけであるからハードコーディングによってそれらを排除するのはナンセンスであるし、この行動はユーザーの自由を制限することであるからやるべきではないという意見もあった。一方でGabにアクセスすることができることを理由にApp StoreやGoogle Play Storeからアプリを削除されてしまうのではないかという意見もあった。ただこの懸念はただのクライアントに対して合理性を持たないだろうと思われていたがその懸念が愚かなことに現実となってしまった。
さて幸いなことに今回の問題はGoogle Play上で起こったものである。Google Play Storeを使わなくてもAndroid端末にインストールすることができる。F-DroidやAPKの配布などインストールする手段は残されている。これがApp Storeでの問題ならば開発者とユーザーに残された生き残る手段はないだろう。
2017年頃にMastodonが注目された頃に比べて大きなメディアがMastodonを取り上げることはめっきりなくなった。国内で言えばITmediaがよく特色のある記事を書いていたが今では全く更新されることはなくなってしまった。mstdn.jp の管理者が変わったことの詳細な記事がITmediaから出ると期待しているが既に変更されてから2ヶ月が経とうとしている。仕方がないよね。Fediverseの思想がいくら素晴らしくても金にならないんだもの。金にならない話は注目されない。記事にする価値はない。世の中は金の話が本質的に価値を持つのか？
Mastodonに対するメディアの関心というは昔に比べて低くなったものの今回の問題はHacker Newsにて大きな注目を集めているのでメディアに取り上げてもらって大きな世論を形成していって欲しい。ITmediaはGabとMastodonについての記事を書いてくれなかったので期待することさえ無駄だろうが。
Subway Tooter blog - Playストアからの削除警告について - Subway Tooter blog
http://subwaytooter.hatenadiary.jp/entry/2020/08/29/113948
Google is apparently taking down all/most Fediverse apps from the Play Store | Hacker News
https://news.ycombinator.com/item?id=24304275
How the biggest decentralized social network is dealing with its Nazi problem - The Verge
・AppStoreでの課金の全てに30%の手数料（Google Play Storeも同じ割合）
・AppStore以外でのアプリ販売は認めていない（AndroidはPlay Store以外での販売も認める）
・アプリ内で販売する課金アイテム（電子書籍なども含む）はアプリ外で販売すれば手数料がかからない
・アメリカの企業だが中国企業のテンセントが40%の株式を所持
・AppStoreの手数料に不満を持ち大々的にアプリ外課金へ誘導した
・規約違反でアプリが配信停止になる（既にインストールされていればプレイは可能）
・Google Play Storeでも同様のことが起きる
・「独裁に反対したら報復された！助けてくれ！」とプレイヤーを煽ってAppleに圧力をかける←いまここ
・Epic Game Storeの販売手数料は12%（ライバルのSteamの手数料は30％）
・米中対立を背景にトランプ大統領がテンセントとの取引の禁止を通告しているのが関係ある？
・Epic Game Storeは「手数料が安い」というのが売りになっておりSteamの手数料をたびたび批判している
・EpicはゲームエンジンのUnreal Engineも開発しておりそちらでも利益を確保できる
日本の銀行である住信SBIネット銀行は公式Androidアプリを提供している(Google Play)。
アップデートして起動してみると、カメラと通話の発信とファイルへのアクセス権限を要求するポップアップが表示された。
前略
これら(の権限)はアプリが端末を認証するために利用するもので、実際に電話をかけたり写真を撮影したりするものではありません。
後略
と表示され、起動することができない。
説明は不明瞭だし、なぜ端末の認証にカメラが必要なのか理解できない。目的外利用な気がする。
口座の解約も検討している。
どこぞの県警はJavaScryptなんかを取り締まってないで住信SBIネット銀行を取り締まってほしい。
住信SBIネット銀行は盗撮をやめろ
メールで「カメラ権限は必要になったときに要求すべきであり、起動直後に要求すべきではない 改善の予定はあるか」と問い合わせたところ、改善の予定はないと返答が来た。
口座を解約することにした。アディオス！
用途でカード分けるってのは完全に自分の都合であって、カードを複数登録してた時に片方が使えなかったのならもう片方を使うのは極めて自然な挙動。
例えば同一のECサイトを利用する場合で個人用と事業用でカード分けたりしたいケースってまああると思うし
そこで複数登録してるからと言って別のカードで勝手にリトライされたらたまったものではないでしょ…
それが自然と思うかどうかは人によるよね。少なくとも自分はそうは思わない。
定額課金系サービスだったりで課金に失敗した場合はユーザー側に別途メールで再操作を求めるのが普通かな。
もちろん知らないだけで反例はあるかもしれない。あったら教えてね。
書いてない文章を勝手に読み解いて、元増田はこういう感じやろって決めつけて
Kyashみたいなプロキシ型のサービスの問題っていう前提にしたいのだろうけど
直近だと今年2月にも障害で楽天カードが利用できなくなったり、裏側に紐付いてるカード自体が問題の場合もあるわけで。
それほど大規模でないにしても、個別の決済がエラーで失敗するってことはあると思うのよね。
規約を過去日にさかのぼって改変するのはそこそこどころか糞evilでしょう。
みたいなこと書いてるけど公正世界仮説に引っ張られすぎでは。
通常のクレジットカードであれば連続決済で片方拒否されるとなると、限度額に到達したくらいしか考えつかない。
Google Playでの課金というからに、廃課金して上限引っかかったなんて話は2ちゃんやSNSでもたまに見かける。
その上、カードAとして登録されているのはKyashだそうじゃないか。
決済サービスに登録するカードを別の決済サービスによる仮想クレジットカードにする、なんてせせこましいことを何故平然とやってるんだ。
こうなると話は複雑だ。
Kyashに登録されている実物のカードAに限度額などの問題がなかったとしても、Kyash上の利用制限に引っかかる可能性が出てくる。
＜Kyash Card＞
1回あたりの設定可能上限額は 30万円
＜Kyash Card Lite＞
1回あたりの決済限度額は 5万円
1ヶ月あたりでの決済限度額は 12万円
＜Kyash Card Virtual＞
24時間あたりの決済限度額は 3万円（本人認証が済んでいない場合は 5千円）
だそうだ。
おそらくこれに引っかかったんじゃないのか。自分のマネジメント力不足で。
そうでなくても多重に決済システムを動かしている以上予期しない様々なエラーに遭遇する率は跳ね上がっていると言える。
そういう使い方を自ら選んでしているということ。
例えばオートチャージ設定で残高不足の決済時には、決済に10秒前後の時間がかかることがある。
プラットフォームによってはそれに遭遇したらタイムアウトでキックされることも十分考えられるだろう。クレジットカードなら即時なので、Kyashのレスポンスは異常に映る。
PayPal側はKyashのシステムなど関知しないから、決済拒否されたから気を利かせて第二の決済手段を使った。
そんなのはシステムとして当たり前の挙動だ。それをしないなら2つ目以降の予備の決済手段を登録しておく意味がない。
なんというか、この前の置き去りにされたUber Eatsの処分を拒否してわざわざ引き取りにこさせた増田と共通するマインドを感じる。
正義感自体は間違っちゃいないが、それを主張しすぎてドツボに嵌りめんどくさいことになるような食らいつき方をして、
より相手を悪意的に見れる証拠を探しにいくようなムーブを選んでしているところがだ。
置き去り弁当の場合は完全なる被害者だったのでほじくりムーブも「分かるけど面倒くさい奴だな」程度の認識で済むものの
増田の場合は決済に不都合が生じている時点で、決済業者を詰めるばかりでなく自分側の使い方に問題がなかったのか考える謙虚さも必要なのではないか。
ここ数年 Twitter で連休の度にクーポンを配っていたり、 Google Play や PS Store 、 ニンテンドーeショップでの決済手段で見かけたりと、それなりに認知されているだろう。
PayPal のアカウントにクレジットカードを登録しておけば、対応しているサイトやサービスであれば PayPal アカウントでログインすれば決済できるようになる。
決済の際にクレジットカード情報をしなくていいというのも魅力的だが、最大のウリはトラブルが起きた際に買い手保護システムだろう。
https://www.paypal.com/jp/webapps/mpp/support/buyer-protection
商品が届かなかったり、説明と違うものだったりしたときに PayPal が代金を返金してくれるというものだ。
ぼくが初めて利用したのは2013年で、長いこと愛用してきた。
PayPal が利用できるサービスなら迷わず PayPal を利用してきた。
最も愛したサービスの一つだった。
けれど、ぼくはこの PayPal が信用できなくなってしまった。
2020年7月末、 Google Play で課金した際に違和感を感じた。
2回連続して課金したのだが、いつも PayPal アカウントでの決済に利用している利用している Kyash の決済通知が1通しか届かないのだ。
しかし、よく見てみるとそれぞれ決済に利用されているクレジットカードが違っていた。
PayPal はクレジットカードを複数枚登録すると、決済実行時などに請求先のカードを聞いてくる。
また、 Web サイトから優先支払いカードを指定することもできる。
どちらもカードAを指定していたが、2回目の課金の決済に使用されたのはカードBだった。
実はこの現象が発生したのは初めてではなかった。
毎回 Google Play で発生していたため、まずは Google に問い合わせた。
ではと思って PayPal に確認したところ、原因と条件が判明する。
カードが2枚登録されている状態でカードAで決済を行おうとした際に、何らかの問題でカード会社がこれを拒否したとき、 PayPal は決済を停止せず勝手にカードBを使用して決済を行うというのだ。
https://web.archive.org/web/20200616215429/www.paypal.com/jp/webapps/mpp/ua/useragreement-full
これが当時の利用規約だ。
ぼくが該当するパーソナルユーザーの規約にそんなことは一言も書いていない。
その旨をサポートに伝え、どこかに記述があるのかと質問したところ
「システム判断につきましてそこまで繊細な部分が規約に記載がございません。」
「PayPalのシステムでは、お客様の支払がスムーズに行えるように、且つサービスの停止、ご迷惑などをおかけしないように設定されています。つきまして、アカウントに登録されているすべての資金源が利用可能だとシステムより認識されています。」
だそうだ。
聞かれてもいないしどこにも書いてないのだから当然同意などしていない。
支払い手段を指定しているのだから当然それが使われ、その支払い手段が使用できなければ決済が失敗すると想定するだろう。
つまり、同意のない契約が PayPal のシステムの都合で勝手に結ばれたわけだ。
「本来であれば確かにご指定のカードに請求しますが、二回ほども請求かけましたが請求ができませんでした。支払いや取引をスムーズに行えるように別のカードで請求をさせていただきました。」
とのことだ。
そしてこれ以降押し問答が続き、挙句の果てにはビジネスユーザー向け規約の2.3 優先支払方法を持ち出してきた。
確かに今回の件に近い文章が書いてあるのは知っているが、これはビジネスユーザー向け規約だ。
それはさすがにどう考えてもおかしい。
ぼくはパーソナルユーザーだ、ビジネスユーザー向け規約が適用されるというのか。
しかも、先ほどまでどこにも書いていないと回答していたはずだ。
そう問いかけたところ「専門部署に一度報告いたします。」といってやり取りを打ち切られてしまった。
これが8月5日のことだ。
規約が変わっている。
どう考えても今回の件の規約が追加されている。
だが日付がおかしい。
ぼくは7月末から8月4日まで毎日規約を確認していたので PayPal が実際にこの規約を掲載したのは2020年8月4日以降のはずだ。
日付を遡って適用しているのだ。
そしてこれだけ大規模の変更だというのに、この規約変更はユーザーに対する通知はなかった。
信頼関係が壊れた瞬間だった。
ありがとう PayPal 、きみがいなければ海外通販を利用してみようなどとは思わなかっただろうし、 PayPal が使用できなければ利用する機会のなかったであろうサイトやサービスはいくつもある。
だけど規約と一致しないシステムを優先し、カードを勝手に使用し、問い合わせても終始言い訳に徹し、あまつさえ黙って規約を書き換えるようなサービスを信用することはできない。
支払いに PayPal を使用していたサービスを少しずつ切り替えている。
さようなら、愛していたよ。
ちなみに、1週間以上に及ぶ今回のやり取り、途中でオペレーターが何度も変わり、日本語が怪しい担当者や、それどころかBOTが紛れ込んだこともあった。
そのたびに話が中断され、再度説明を求め、やり取りが巻き戻ったりはぐらかされたりするのだ。
これも初めてではない、別件でも同様だったので PayPal の方針なのだろう。
途中でなんども諦めそうになった、いや、最終的には諦めたからこの駄文をしたためたのであるが。
クレーム対策には非常に有効かもしれないが、買い手保護利用の際もこのやり取りをする必要があるということだ。
https://web.archive.org/web/20200616215429/www.paypal.com/jp/webapps/mpp/ua/useragreement-full
国立西洋美術館が日時指定のチケットをオンラインのみで発売してるっていうんで、チケットを取ってみた。
これがほんとに使いにくい。
購入にあたってこんなにイライラするwebサイト、はじめて見た。
致命的に使えないわけじゃなくて、購入までの各ステップでそれぞれちょっとずつイライラさせられる。
厳密には国立西洋美術館だけじゃなくて途中からはe+のサイトだけど、もうなんかセットで苛立つ。
西美サイトで｢オンラインチケットは以下の各方法で販売してるよ｣って書いてある割に、その各サイトへのリンクが見当たらなかったり。
日時指定で空いてる日時をクリックした後、さらにもう一度日時一覧がズラっと出てきたり。
購入に会員登録がいるのかよ、面倒くせー…と思って進もうとしたら、会員登録方法の説明ページに移動するだけで、登録には一度トップページに戻らないといけなかったり。
メールアドレスで仮登録して、メールに書いてあるアドレスに移動したら、そこからさらにSMS認証があったり。
購入できた！チケットをダウンロードしよう！と思ってダウンロードボタンを押したら、Google Playが開いて、まず別アプリをダウンロードするよう求められたり。
もうなんなんだこの、購入者の心を細かくイライラさせる使いにくさは。
クソofクソ。
「電子書籍元年」と喧伝された2010年に、iPadとあわせて入手した電子本の半数以上は、最新のOSで開くことができない。
標準フォーマットのEPUBから外れた独自規格が原因らしいが、10年経たずに朽ちてしまう本って、いったい…。 pic.twitter.com/jJHNB3uhPy— 桂川 潤 Katsuragawa, Jun (@jun_soutei) September 30, 2019
2010年はいくつかある「不発に終わった電子書籍元年」だよ。
7月楽天Kobo、9月Google Nexus 7とGoogle Playブックス、10月Apple iPad miniと日本語組版に正式対応したiBooks 3.0、同じく10月Amazon Kindle 4機種とKindleストア登場。ということで、正真正銘の「電子書籍元年」がやっと訪れた。Kobo、Google、Apple、AmazonそしてSONY、すべてEPUB 3が基本フォーマットになっているのは感無量。
つまりKindleの日本語版が登場した2012年が真の「電子書籍元年」だ。
「EPUBが基本フォーマットになっている」というのも重要で、
「電子書籍元年」になれなかったし「10年経たずに朽ちて」しまったんだよ。
当然のことをいまごろになって騒ぐほうがおかしい。
https://www.gamespark.jp/article/2019/01/10/86544.html
食品擬人化キャラが店舗経営をするだけの全年齢萌えゲーなのに複数回にわたって理由の通知なくリジェクトされ、最終的にキャラの外見年齢をほんの少し上げたら通過
「児童労働」が宗教右派の怒りに触れたのではないかと噂されているが推測にとどまる
このルールはまったく一貫しておらず、審査員ガチャの運が悪ければ健全萌えゲーでもアウト、運が良ければ露骨なエロゲーでもセーフと悪名高い（なおエロ自体はSteamでは認められている）
https://techraptor.net/content/the-expression-amrilato-steam-release
最近の日本産ゲームだと「ことのはアムリラート」（エスペラント語と百合をテーマにした全年齢ノベル）が審査上の謎の理由によりSteam版のみ一時無期延期
「"マイノリティの性的消費"だと通告されたがまったくばかばかしい。そんな内容は含まれていない」「昨今の審査プロセスはますます不可解になってゆく」と海外パブリッシャがコメントして賛同の声が集まった
その後無事無変更でリリース
Google Playの例では、このポップな絵柄のゲームが「一番右のキャラの胸にほんのり谷間が描かれている」を理由に突然販売停止
我々（以下「当社」といいます）が提供する有料プランの利用については、本利用規約に必ず同意のうえご利用ください。 なお、有料プランをご利用される場合には、利用規約への同意が必要となりますので、ご利用前に併せて必ずお読みください。
第 1 条（利用規約について）
Iyashi有料プラン利用規約（以下「有料プラン利用規約」といいます）は、Iyashi利用規約に定める個別規定として、Iyashi利用規約の一部を構成します。
有料プラン利用規約は、当社と有料プラン（第 2 条 1 号で定義します）を利用する有料プラン会員（第 2 条 2 号で定義します）との間の一切の関係に適用するものとします。
有料プラン会員は、有料プランを利用することにより、有料プラン利用規約及びIyashi利用規約の内容について同意したものとみなされます。
有料プラン利用規約については、有料プラン会員に対する事前の通知なく、当社の判断により、いつでも任意に変更ができるものとします。有料プラン利用規約が変更された場合、当社が別途定める場合を除き、当社サイト上又は当社アプリ上に表示した時点により効力を生じるものとします。また、当該変更後の有料プラン会員による有料プランの利用には変更後の有料プラン利用規約が適用されるものとし、当該利用により、有料プラン会員は当該変更に同意したものとみなされます。
有料プラン利用規約において使用する用語の意義は、次の各号の定めるとおりとします。なお、Iyashi利用規約で定義した用語の意義は、有料プラン利用規約で別段定める場合を除いて、全てIyashi利用規約の用語の意義と同一とします。
「有料プラン」とは、有料プラン会員が当社サイト又は当社アプリ上で利用できる当社の有料サービスをいいます。
「有料プラン会員」とは、利用者のうち、有料プラン会員の登録手続を行い、有料プランサービスを利用する方をいいます。
第 3 条（有料プランの利用条件について）
未成年者は、有料プランの利用にあたり親権者の承諾を得なければならないものとします。
当社は、有料プランの利用者が、次の各号のいずれかに該当すると判断した場合または判明した場合、いつの時点においても、有料プランの提供を中止することができるものとします。
（1）過去に本規約の違反等により本サービスの提供を強制的に中止されたことがある場合 （2）その他、当社が利用者とすることを不適当と判断する場合
当社は、有料プランサービスの内容を、当社サイト上又は当社アプリ上に表示します。
第 5 条（有料プランの変更等）
当社は、有料プランの全部又は一部をいつでも任意の理由で変更、追加、中断、終了（以下本条において「変更等」といいます。）することができます。 当社は、有料プランの変更等により有料プラン会員に生じたいかなる損害等についても、一切責任を負うものではありません。
第 6 条（利用料金）
有料プランの契約期間は、１年プラン申込時より１年間（ただし第８条に定める自動更新があります）とします。
一旦支払われた情報料は、通信サービスが利用出来ない状態が生じた場合等を含め、当社の責めに帰すべき事由がある場合を除き、返金いたしません。
有料プラン会員は前条に定める金額を、以下の各号で定める方法により支払うものとします。
本サービスは、請求・収納代行業務を行うApple Inc.、Google Inc.が App Store、Google Playで提供する自動更新の定期購読型課金の機能を利用しております。情報料は、請求・収納代行業者が提供する課金機能での決済手段および支払方法により、請求・代行収納されるものとし、有料会員はこれを承諾するものとします。
有料プラン会員は、有料プラン会員が請求・収納代行業者との間で別途契約する条件に従い、当該請求・収納代行業者に対し情報料の支払いを行うものとします。有料プラン会員が請求・収納代行業者との契約条件を遵守しない場合は、本サービスの利用をお断りさせていただく場合があります。
請求・収納代行業者が情報料の収納代行を行う場合において、有料プラン会員が支払期日を経過しても情報料を支払わなかったときは、当該請求・収納代行業者は弊社に対し、有料プラン会員の氏名、未払い情報などを通知いたします。この場合、当社が通知を受けた情報をもとに、直接有料会員に請求させていただくことがあります。
有料プラン会員は、情報料の支払いに関連して請求・収納代行業者との間で生じた紛争を、自己の責任と費用において解決するものとし、当社に何等の迷惑をかけず、かつ損害を与えないものとします。また、当社は、かかる紛争に起因して有料会員に生じる損害につき、一切の責任を負わないものとします。
有料プラン会員と請求・収納代行業者との間の紛争に起因して当社が損害を被った場合、当該有料会員は、かかる損害を当社の求めに応じて賠償するものとします。
第８条（課金の停止等）
本サービスは請求・収納代行業者が提供する自動更新の定期購読型課金の機能を利用しております。お客さまご自身で課金機能を通じて登録をキャンセルされない限り、自動的に課金は継続します。現在の購読期間が終了する24時間前までに、以下のリンクを参照し解約を行ってください。なお、解約処理をされても支払い済みの購読期間中は引き続き有料プランのサービスをご利用いただけます。また、購読期間中に解約されても当期間分の料金は返金いたしません。
App Storeでお申込みされた方 https://support.apple.com/ja-jp/HT202039
※本アプリをアンインストールしても自動的に定期購読は解約されませんのでご注意ください。
Google Playでお申込みされた方 https://support.google.com/googleplay/answer/7018481?hl=ja
※本アプリをアンインストールしても自動的に定期購読は解約されませんのでご注意ください。
当社は、利用者が次の各号のいずれかに該当する場合には当該利用者への本サービスの提供を終了することができるものとします。
附則
2019 年 3 月 16 日適用
