  |
はてなキーワード: Google playとは
当エントリはある程度の情報技術リテラシーが必須であり、一部の情報はPC初心者および初級者に推奨できるものではない。
しかしPC初心者および初級者はシステムを壊す、大事なデータを失うなどの手痛い失敗をして成長するのもまた事実であり、もしもプログラミングなどに興味のあるPC初心者および初級者がこの情報を活用する場合はシステムを壊す、大事なデータを失うことを覚悟して実行するように。
チュートリアルに指示通りに進めれば大きな問題はほぼ発生しません。
Chrome OSは初期状態のデフォルトで「ノーマルモード」と呼ばれる一般ユーザーモードですが開発者向けに「デベロッパーモード」が用意されています。
ノーマルモードはChrome OSの様々な制限があり、デベロッパーモードによって制限の解除が可能です。
しかしノーマルモードからデベロッパーモードへ移行するとPowerwash(初期化)されてしまい、システムやユーザー領域へ追加された情報はすべて削除されます。
もしデベロッパーモードが必要な場合はデベロッパーモードの詳細を調べ、現在の情報は削除されてしまうことを念頭に実行しましょう。
ちなみにProject CrostiniのLinuxレイヤーへDebianリポジトリからパッケージを導入するなどにはデベロッパーモードは必要ありませんので多くの場合はノーマルモードのままの運用で十分でしょう。
Android OSアプリやChrome OSアプリを開発したい場合は最初からデベロッパーモードにしたほうが後悔が少ないです。
Chrome OSでは一部のキーがほかのOSでは見慣れないものが並んでいます。
迷いがちなので一番最初に覚えるべきキーボードショートカットは「Ctrl+Alt+?」です。
「Ctrl+Alt+?」でいつでもキーボードショートカットを確認できることだけは覚えておきましょう。
多くのChrome OSデバイスはGoogle Play Storeへ対応しており、Google Play Store経由でAndroid OSアプリ導入が可能です。
しかしながらGoogle Play Storeへ公開されているAndroid OSアプリが必ずしもChrome OSへ最適化しているのか？と言えばそうではなく、Android OSアプリの開発環境であるAndroid StudioがデフォルトでChrome OSでの実行を許可していることもあり開発者が意図せずChrome OSへインストールできてしまうことが大半です。
したがってChrome OSへ導入するAndoirdアプリの動作へ何らかの不具合があったとしても脊髄反射で酷評せず、やんわりと丁寧に博愛精神をもってChrome OSではこうだとアプリ開発者へ情報共有することをオススメします。
多くのAndroidスマートフォンやタブレットはARMアーキテクチャーと呼ばれるものを採用していますが、現在のChrome OSデバイスは高性能な製品になるほどx86(x86_64)アーキテクチャーを採用している傾向があります。
本来コンピューターアプリケーションというものはアーキテクチャーが異なると実行起動動作が不可能ですが、Android OSアプリは異なるアーキテクチャー間でもアプリの実行起動動作が極力可能となるように互換性をだいたい確保しています。
しかしながら例えばARMアーキテクチャー向けのAndoird OSアプリをx86アーキテクチャーなデバイスで実行するとアプリ動作のパフォーマンスが著しく落ることが多いです。
これは高度なグラフィックス機能を必要とするゲームなどで顕著に現れる傾向にあり、Chrome OSでは期待したほどAndroid OSアプリが軽快に動かない可能性を理解しておく必要があるのです。
コロナ禍によって多くのChrome OSデバイスを販売することが出来ましたが、それによってChrome OSデバイス間の性能差が問題視される機会も増えました。
具体的には「インターネット上でChrome OSでの動作報告がなされているAndroidアプリが自身のChrome OSデバイスではインストールできない」といった報告です。
これは一部のAndroidアプリ開発者がデバイス性能によってインストールの許可不許可を決めているために起こることで解決方法は基本的にありませんので諦めましょう。
これから導入するAndroidアプリのためにChrome OSを購入する際は価格につられて低性能すぎるデバイスを購入してしまうと失敗する確率が高まりますので注意が必要です。
ただし、Googleが提供するアプリなどは基本的にそのようなことは無いようです。
設定から「Linux（ベータ版）」で「オンにする」とLinuxのインストールが開始されます。
現在のChrome OS v90ではLinuxレイヤーを実現するProject CrostiniではデフォルトでGPUによる支援機能を実行できません。
Chrome Webブラウザを起動し、URL欄へ「chrome:flags」と入力しアクセスして「Crostini GPU Support」を「Enabled」とし再起動してください。
この変更で動作に不具合を確認した際は設定を元に戻してください。
LinuxにもGoogle Play Storeのような簡単にLinuxアプリを導入できる環境が存在します。
GUIパッケージマネージャーを導入する場合は「ターミナル」を起動し下記を実行してください。
sudo apt install synaptic gnome-software
Chrome OSとLinuxレイヤーではパッケージの導入先がデフォルトで海外のサーバーになっており少々遅いです。
日本国内のサーバーへ変更することで速度を改善できる可能性があります。その際は「ターミナル」を起動し下記を実行してください。
現在のChrome OS v90ではChrome OSとLinuxレイヤーを実現するProject Crostiniで日本語入力を共有できず、キーボード入力しても英字しか印字されません。
日本語入力をするには別途に日本語インプットメソッドと日本語フォントが必要です。
日本語インプットメソッドと日本語フォントを導入する場合は「ターミナル」を起動し下記を実行してください。
Linuxへ詳しい方はfcitx5のほうが何かと問題が少ないでしょう。
しかし一部のfcitx5向けパッケージがDebian公式リポジトリに存在しない可能性があるのでご注意ください。
KVMやLXC、Dockerなどの仮想環境を幾度か試しましたが、仮想環境を構築したProject CrostiniのLinuxレイヤーを再起動するなどによってProject CrostiniのLinuxレイヤーシステムへ致命的な破壊が起きることがあるのを何度か確認しています。
Project CrostiniのLinuxレイヤー自体が仮想環境のため、Chrome OSのシステムが破壊されるわけではないですが業務利用時にLinuxレイヤーシステムの破壊が起きてしまうと困ってしまうので仮想環境構築は推奨できません。
仮想環境によって開発環境の統一を計っている現場では開発デバイスとしてChrome OSデバイスは利用しないほうが良いでしょう。
ただし、Chrome OSデバイスは実質的にAndroid OSデバイス、タッチスクリーンデバイス、キーボード付きデバイス、タブレットデバイス、ノートPCデバイス、コンバーチブルデバイス(いわゆる2in1)、マルチタスクデバイス、ウィンドウ可変デバイス、タッチスタイラスペン付きデバイスとして機能する可能性を秘めていますので実機デバッグ用デバイスとしては非常に価値があります。
昨今はアスペクト比が16:9でないどころかリアルタイムに可変してしまうデバイスが物凄く増えていますのでスマートデバイス向けアプリを開発する現場ではデバッグ用として1台持っていても全く損しないデバイスかと思われます。
さらに言えばティーン層はGIGAスクール構想によりChrome OSでプログラミング学習をしているわけですからティーン層取り込みのためのUI開発にも使えるのではないかと考えます。
いや暇だからね、何かやろうかなってパッと思い付いたのがコレだっただけ
ちなみに定番ばかりだぞ？んじゃ行ってみよう
Chromeがあればコッチも
Webブラウザは色々使ったけど結局この2つに落ち着いた
これもプリインストール
次世代SMSであるRCSに対応している
個人的にRCS登場以後のメッセージングはこれの比率が増えている
Web版も存在していて便利
ちなみにRakuten LinkもRCSへ準拠しているので相互にRCSを送受信できる
どうやら国内ではGoogle Messages間同士のみという情報を頂いたので修正
もともとGoogle Talkユーザーだったので流れで
前身のHangoutsは今年の終了が決まっているので早めに移行したほうが良いよ
仕事で使うので
ゲーム系はやっぱりこれだよね
仕方なく
電話番号不要で利用可能、強固な暗号化が施されているP2Pによるチャットが行える
このあたりのツールに親和性が高いギークたちとコミュニケーション取るのに使ってる
分散型チャットプロトコルMatrixへ対応したチャットツール
これも同上の理由でギークたちとのコミュニケーション用
利用頻度は非常に落ちているもののはてブでTwitterリンクが流れてくるため
同上
分散型SNSのMastodonのクライアント
Twitterから完全に移行しちまった
わかる人にはわかるだろうけど非常に居心地が良い
OpenStreetMapを活用した地図アプリ
OSM系地図アプリの中では機能が多すぎるくらい非常に多機能
OsmAnd+は有料版、無料版はプラスなしのOsmAndで有料版との違いが先行アップデートくらいなもので機能的な差はほぼ無いので大半の人はプラスなしOsnAndで十分
モダンなOpenStreetMapエディタ
非常に使い勝手がよくゲーミフィケーション的に進捗を管理してOpenStreetMapへ貢献できる
オープンなGoogleストリートビューを作ろうという試みのサービスアプリ
OsmAnd上でもプレビューできる
Google謹製のファイラー
使用頻度の低いファイルを抽出し削除する機能などがある
写真動画趣味なので保存しまくってたら無料期間終了で抜け出せなくなった
個人的にはこの機能で無料はありえんわなと納得しているので課金して容量増やしてる
撮影に必要な機能をこれでもかと載せたカメラアプリ
ただし多眼カメラが切り替えられないのが最大の欠点
設定項目が多すぎるので写真撮影法のハウツー本とか一度でも読んだことがないと使いこなすのは厳しいだろう
便利すぎ
古典的な2画面ファイラ
整理整頓時に前述のFilesで一括削除したくない時に使える
FTPやWebDAVへアクセスできたりもする
BitTorrentの技術を応用したP2P方式のクラウドストレージ
巨大ファイルのやり取りはGoogle Driveよりも速いし転送上限も無い(大手クラウドストレージはダウンロードを繰り返すと転送上限に達してダウンロード停止されたりすることがある)
いい加減辞めたくて乗り換え先を色々試すが戻ってきてしまうノートアプリ
Androidでは定番のターミナルアプリ
デスクトップLinuxユーザーでもあるのでTermuxには助けられてばかり居る
X Window Systemのクライアント
リモートデスクトップに使える
CUIな同名タスクマネージャーのAndroid GUI版
GUIで操作しきれないとき直接コマンドを送信できる機能もある
ちなみにTermuxにもパッケージが提供されてる
AndroidでもSKKが使えてしまうIMEアプリ
ただし野良アプリ
だらだら思い出しながら書いてるけど眠たくなったのでこの辺で
(ここより追記)
2人対戦のミニゲームが多数収録されているアプリ
1人プレイでも対CPU戦が可能
スマホよりはタブレット向きでAndroid Appが動作するChrome OSにも対応
安いので課金して広告非表示にして損はない
絵本はらぺこあおむしのアプリ
絵本のような世界観の中であおむしを育成できる
算数未満の「数かぞえ」アプリのなかでは完成度が高い
文字が読めない幼児に向き、日本語で課題を読み上げてくれるし、しっかりと数字も読み上げてくれる
前述の2つと合わせて5才児と遊んでいる
ミニゲームが多数収録されていて暇つぶしとして馬鹿に出来ない
インスタントアプリ対応ゲームで様々なタイトルをお試しするのもアリ
もともとはLinux界隈で定番の横スクロールアクションゲーム
膨大に存在する追加ステージをダウンロード可能
むしろ「本家」が出してる例の横スクロールアクションジャンプよりも遊べてしまう
ただし一部のフォントが中華フォント
こちらもLinux界隈で定番の横スクロールアクションゲーム
メトロイドのような世界観グラフィックスと独特の操作性が特徴
認めざる得ない、これは面白い
対戦型タワーディフェンスゲーム
バランス調整が頻繁にあり極力運要素を排除しプレイングで勝敗を喫したいという運営の方針が読み取れる
マッチングはレーティング方式で、更に様々なルールでの対戦があるため強いデッキが固定しないのも美点
検索エンジンとしてGoogleでは、いかに「Google以外のネットに移動してもらうか」が重要だった。
いかに早く検索結果を出し、有益なサイトに飛んでもらうのが良い検索サイトだったわけだ。
だがいつの間にか、いかに「Googleの中にとどまらせるか」に変わった。
検索エンジン以外に幅広く手掛けるようになって、どれかのサービスを切り替えながら居続けてもらう方がGoogleにとって良くなった。
アドレスバーをなくしてURL確認できないようになれば、人々は知らないサイトは危険だから「Googleなら安心か」ということでGoogleの中にとどまる。
自社で持っているサービスを上位に表示させ、類似サービスを下位に表示するのも出来る。
ネット情報で解決しないようになり、どこかで書籍に戻るとなったらGoogle Playブックスで購入してもらったらいい。
そして並大抵の事では次の検索エンジンは現れない。
膨大なサーバーを持たないといけないので天才が数人現れた所で太刀打ち出来ない。
Googleを打倒するような天才が現れようとするのも、教育現場から拾ってきたデータでつかめ、Google社員がハイアリングのために声をかけると
多くは了承してGoogleに入るだろう。
GoogleからしてもGoogle社内内部の方が確かな情報があるのであり、Googleの外のネットがどうなっていようと構わないという状況になりつつある。
この点数シールの集計に、毎年苦労させられるのだ。
台紙は5x6マスである。
しかし毎日まるごとソーセージでは飽きるので、0.5点のコッペパンも食べたい。
となると、どうしたって台紙1枚でお皿1枚スッキリポンとはいかない。
休みの朝には2.5点のダブルソフトだってトーストしたいのだ。
0.5に1に2.5が混在し、場合によっては1.5や2も乱入してくるのだ。
これをどうやって台紙に貼ればよいというのだ。
そろそろヤマザキさんには、デジタル化なりなんなりどうにかしてもらいたい。
といって今年はもうどうにもならないだろう。
ところであなたは、さしあたって台紙に混在した点数シールを画像認識で集計するスマホアプリを作りたくなっただろう。
私はAndroidユーザーなのでGoogle Play Storeで公開してもらいたい。
善は急げだ。
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クソ。
