HILOG: 2020

2020年12月18日金曜日

Androidヘルプ（Pixel ガイド）を再度表示する方法

Pixelをアップデートした直後の最初だけ通知される

「Pixelガイド」を再度表示する方法。

【環境】

　Androidバージョン 11

【手順】

1. 「設定」アプリを起動

2. 「設定を検索」に「Pixelガイド」または単純に「ガイド」を入力

3. 候補にPixel ガイドが出てくるのでタップして起動。

なお、候補に出てくるPixel ガイドの下の注釈にも出てるが、

「ヒントとサポート」→「Pixelのヒントを見る」

でも起動可能。

【経緯】

OS(Android)をアップデートして、Pixelガイドが出てきたので

見ていたのだが、「なるほどこんな機能もあるのか」と思って、

Pixelガイドを抜けて実際操作してみた。

そしてPixelガイドに戻ろうとしたけれど、「アプリの切り替え」操作（下からスワイプしてホールドするやつ）で

出てくるアプリ一覧に「Pixelガイド」がない。

ホーム画面のGoogle検索で検索しても出てこない。

「Pixelガイド」というキーワードさえ忘れていた（というかアップデート時に勝手に出てくるのでなんのアプリであるかさえ不明な状態）ので

「Android 新機能」とかでもアプリ候補は出てこない。

「Android アップデート新機能紹介　アプリ」とかキーワードを

いろいろ試すけど、YouTubeで機能紹介する動画とかばっかり出てきて

肝心の「Pixelガイド」をもう一回起動するやり方は延々と見つからなかった。

（いろいろ検索して、昔はPixelガイドという独立したアプリだった

　らしいということは分かった。）

おそらく初心者であればあるほど、この状況に陥りやすいのではないだろうか。

つまりAndroidの操作とか新機能を知りたいと思う人ほど、Pixelガイドを

抜けて戻ってこれなくなってしまって、操作方法や新機能を知らないまま

使っている人が多く発生している、ということである。

せっかくこんな分かりやすいガイドを作ってくれているのに、一番知りたい

人に届いていないのでは本末転倒である。

そして、おそらくGoogle的には、PCアプリにあるような

・初回起動時はヘルプを表示

・「次回から表示しない」チェックを付けると以降は表示しない。

みたいな動線が気に食わなかったので、シンプルに、直感的にしたかったのだろう。

（もしくはGoogle流儀が未だ完全に浸透しておらず実現に至ってないと見るべきか。

　主観的なシンプルさ・直感さは気を付けないと、分かりづらさ・

　意味不明さになるという、UX法則第なんとか条ですね。＾＾おしい！）

せめて救済策として「Android アップデート新機能紹介　アプリ」などの

キーワードでPixelガイドの再表示方法が検索トップに出てくるとか、

ホーム画面とかアプリ一覧にエイリアスを貼っておくとかくらいは

しておいてよかったのではないだろうか。（初心者用に）

−−−−−−−−−−

実際なぜPixelガイドが出てこなくなってしまうかだが、「Pixelガイド」は

「設定」アプリの一部なので、一度「Pixelガイド」を抜けて、他の設定を

いじったりすると、それは「設定」アプリ内の画面遷移であるので、

いくら「アプリの切り替え」で探そうが見つからない訳である。

私も最初いろいろ探して、「こうゆうものはヘルプにあるはずだし、

あるべきだ」と思って、設定アプリの「ヒントとサポート」を

一回開いたのだが、ここだけWebページを開く感じだったので

ここから先は外部Webページだと思い込んでしまい、

「Pixelのヒントを見る」を試さずに戻ってしまった。

最終的にはそれを起動するのが正解であったのだが、

初心者がそこまでできるかどうかははなはだ疑問である。

当初は「Pixelガイド」も独立アプリで、バージョンアップにより

設定アプリ中のヘルプ部門に統合されたようなので、その辺の経緯が

あるとは思うのだが。

さすがのGoogleさんでも何かを変化させたときの影響を

網羅的に見るのはやはり難しいのだな、ということが今回

分かりました。

（天下のGoogleさんなので、「Pixelガイド」の使用頻度とかも

統計を取って、ユーザの熟練度（使用年数）とかと相関を取って、

ある時点でAndroidバージョンアップしてからなぜかPixelガイドの

使用頻度がガタ落ちしたことに気づいて対応してほしかった＾＾

これは期待しすぎか＾＾）

2020年11月7日土曜日

鬼滅の刃　大正コソコソ面白話　ー禰豆子の竹・那田蜘蛛山の鬼・鬼舞辻無惨とキマイラ吼ー

鬼滅の刃で、軽微ながら気になった点

フィクションである以上、矛盾はつきものであるが、

熱狂的ファンは当然であるのかもしれないが、社会現象とかにまでなってくると

なおさらだが、誰とも言わずに勝手に考察が始まるものである。

またはファン人情として、なんとしても成り立たせたいために

矛盾を矛盾でないようにあれこれ（時として「どんだけ頭がいいんだ？」

といった想像・創造を駆使して）成り立たせようというベクトルが働くのである^^

(よく言われるフィクションの存在意義)

それを言外に共有した上でみんな楽しんでいるのであれば、

それはそれで良いのだろう。

※過去の投稿　富岡義勇が鱗滝左近次に宛てた手紙の疑問　についてはこちら

https://hilog07.blogspot.com/2020/09/blog-post.html

禰豆子の竹

禰豆子が鬼になりかけたので、人を襲わないように咥えさせた竹について。

実際に口と竹はどういった状態なのだろうか？

短絡的に考えれば、鬼の牙が危険なので牙で竹を噛んだ状態であろう。

そうするとどうしても唇は密封状態ではない。

医療関係者や介護関係者であれば分かるが、（実演するとすぐに分かるが）

口を閉じてないとどうしても唾液が外に出てきてしまうのである。

なので、漫画中には出てこないのだが、おそらく優しい

炭治郎が常に禰豆子のよだれを拭いてあげているのだろうな、

といった、何にもならない想像^^

（もしくは禰豆子には人としての恥ずかしさが残っているので、

常に一生懸命によだれが垂れないように吸い上げてる、とかになってくるが、

それもかわいそうなので、原点に戻ってこのことは「気にしない、考察しない」

のが一番いいのかもしれない。）

（または「鬼になり生存活動が止まったので、一般で言うところの

「食事や生存活動」に対する唾液の分泌は停止した、とか割り切るのも一手。

人の血を見た時だけ唾液の分泌が始まるとか。）

想像を逞しくすると、竹はただのカバーであって、あの中は

牙をしっかり抑えつつも口を閉じれるように、石膏などで

型を取って、口が痛くならないように歯医者さんで使うような

何か柔らかいジェル状のもので作られたもの（大正時代にも存在し得たもの）を、

実際は禰豆子が噛んでいるという案。

（案ってなんだ？）

更に言えば、炭治郎も富岡も鱗滝も、禰豆子は人を襲わないということは

分かったので、人前にさえ出なければ竹はいらないのでは？

とも一瞬思ったが、やはり竹は「保険」として必要だな、ということ。

何かの手違いで禰豆子が暴れた時に竹があるとないとでは、

（禰豆子が本気になれば竹は一瞬で粉々になろうとも、）

たとえ刹那の違いであったとしても保険としての竹の意味はあるのである。

それと対外的に人の目に鬼の牙を見せない意味。

基本的に日中は外に出ない、食事もしないという点を差し置いた前提であっても。

これも保険的な考え方。

現実の世界に立ち返ると、「鬼になりかけた人が竹を噛んでいる」という

「絵」は漫画的に捨てがたいし、独自性（ユニーク性）・マスコット性も

抜群なので捨てる意味がないだろう^^

那田蜘蛛山の鬼

那田蜘蛛山編の累の家族役の鬼で、父親役と兄役の鬼に

エピソードがなくてちょっとかわいそう。

また、なぜ父親役の鬼は顔を蜘蛛に、兄役の鬼は体ごと

蜘蛛にした・しようとしたのであろうか？

他の鬼も見てみると、どうやら自分の体は自分の思うように

できるようなので、それぞれの鬼が生存競争で勝ち残りやすい

自分に合った姿になっているのであろう。

（元は人間なので、そのまま人間の姿の鬼が多い。）

兄役の鬼は、武器を持って戦えなくなる代わりに蜘蛛の捕食能力に

特化することで生きて？いこうと思ったのだろうか。

父親役の鬼は人に恐怖を与えてひるませるために、また父親としての

威厳を出すため蜘蛛の顔にしたのだろうか？

大きなあごによる強力な咀嚼攻撃は前面に押し出してない。

また「自分の体のここをこうしたい、手を生やしたい、

触手を伸ばしたい」というのは、鬼本人の「意志」パワー

（ウィルパワー）だけでできるものなのだろうか？

腕一本にしても骨があり筋肉があり筋があり神経があり、

それらは意志でできてるわけではなくて、生物の自己完結性で

できているので、鬼としてはできたとしても、あくまで

「ここら辺に腕と同等の組成をしてくれないかな」的な

「きっかけ」を与えるくらいまでだろう。

ましてや完全に異種の蜘蛛の組成を形成するにはウィルパワーでは

できるわけがないので、おそらく蜘蛛の遺伝子なりをものすごい

理論跳躍して取り入れているはずである。

（ザ・フライ！？（ジェフ・ゴールドブラム）世代がばれる）

他種を融合できることをまじめにやって、遭遇したあらゆる

生物を融合して、それぞれの長所をいいとこどりしていけば

かなり強くなれると思う。

（と同時にかなりおぞましくなるだろう。この辺は美意識が

　優先されるのだろうか。）

また、下弦の壱　魘夢のように汽車とも融合できるのであるから、

例えば人の捕食はちょっと我慢して、がんばって山とかと融合して

しまえばかなり最強だろう。

融合後は入山してきた人をいただくと。慎重になるのであれば

事故ってしまった人だけいただいておけば怪しまれまい。

（他の鬼も見てみると捕食数は数十年～百何十年で数十～数百人レベル

であり、数百年前の統計が取れてはいないが過去の事故数は現代よりも

多かったと仮定すれば、まぁ安定的に補給が確保できてなかなか

賢いやり方であろう。）

山と融合しているので首の骨をはるか地中深くにしておけば

まず切られる心配はない。

後の心配というか問題は可動性であろう。

たいていの話だと大型化すると可動性が下がって、それこそ

鬼の腹に入ってとか、血管とか骨とかに入って「内側から倒す」

系の話になることがほとんどである。

山の大きさで可動性もあると本当に最強になってしまうので

むしろ条件設定でこの「枝」は切り落とされるわけである。

山鬼「無惨さま、山と融合しました！」

無惨「うむ、よくやった」

とかなるのだろうが、いったいこの鬼は何をしたいのだろうか、

ということにもなる。

もう一点、傷を瞬時に直したり、腕を再生させたりというのは、

細胞分裂の速度とかに行き着くのだろうか。

腕を生やすにしても、その元となる養分が必要なので、

それは一体どこにどうやって有しているのか、

（すべてはエネルギーに行き着くというのならばゴジラが参考になる）

（そう言えば、映画「シン・ゴジラ」でいつまでも気になって

頭から離れないのは、ゴジラ対策を会議室で考えている場面で、

矢口(長谷川博己さん)が、自分のコーヒーともう一つのコーヒーを

持っていくシーンで、自分のコーヒーにちょっと口をつけた時に

首をちょっと横に振るのだが、あれはどういった意味だったのだろう？

という点。（そこか！）

P.S. Netflix版で言うと 1:28:28 のシーン。

見返すと「熱いな！」のリアクションだった！＾＾

（見返すまでは、矢口のコーヒーに対するリアクションだけが

何故か強烈に印象に残っており、無理に思い出すとそれが

「熱いのか」または「ぬるかったな」なのか「あまり美味しくない

コーヒーだな」なのか自分で記憶を作ってしまっていた！）

人の記憶とはこう言うものだが、この状況で矢口が

首をちょっと横に振ったことを、私は何故かをずっと気にしていた、

と言う点が重要である。（言い訳甚だしいが。。）

人の行動に全て意味を含んでいる訳ではないが、

「微に宿る」（正しくは「神は細部に宿る」）とも言われるように、

その人物をして、その行動をとらしめたことは考察の対象になるのである。

この点で想像が止まらなかったのだろう。皆さんもこれを気にしだすと止まらなくなるので、気にしないようにしましょう。

（更に踏み込むと「歴史とは」とかになるのでやめておくが、良い・悪いでは決してないのだが、ドラマを作ると言うことは特に史実ものにおいてはその時の最新史実情報を元にその時の情景を再現し、各登場人物の心情まで迫れて、考察の新しい切り口になったりして見ていて楽しいのだが、他方でそれがその通りであったかどうか、と言う点はまた別の問題ということであろう。））

とかなり脱線してしまい、これ以上行くと夢がなくなってくる

ので、（またはこれによって驚異的増殖スピードの細胞の

研究が進むことを期待して）、この辺までにしておきます＾＾

鬼舞辻きぶつじ無惨むざんとキマイラ吼こう

鬼舞辻無惨の口（顎あぎと）を持った触手を見てキマイラ吼を思い浮かべた。

そしてまたキマイラ吼を読み返したくなった。

（主観を述べただけで、なんの考察もなくてすいません。

　ただ、同じ事を思ったSFファンはいるはず。。）

※キマイラ吼　…　夢枕ゆめまくら獏ばくさんの小説。詳しくは以下Wiki参照。あの世界観がたまりませんね！

https://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%9E%E3%82%A4%E3%83%A9%E3%83%BB%E5%90%BC

2020年9月11日金曜日

鬼滅の刃　富岡義勇が鱗滝左近次に宛てた手紙の疑問

鬼滅の刃について、ちょっと気になった箇所。

単行本第一巻 P88 で、富岡とみおか義勇ぎゆうが鱗滝うろこだき左近次さこんじに宛てた手紙に

「鬼殺の剣士になりたいという少年をそちらに向かわせました」とあるが、

「ん、炭治朗たんじろうは鬼殺の剣士になりたい？」と引っかかった。

そこまで言い切っていたかな？と。

読み返してみると、炭治朗が意思を表明したのは、

富岡が禰豆子ねずこを後ろ手に抑えながらやりとりする場面で、

「禰豆子を人間に戻す」「絶対に治します」

（鬼が人間に戻る方法を）「必ず方法を見つける」

「家族を殺した奴も見つけ出す」

と言ったところ。

しかし状況が状況なだけに、炭治朗は妹が殺されないように

必死であり、感情的な勢いも含まれている。

富岡もそれを分かった上で、つまり感情という「ゲタ」の分を

差し引いた上でも、炭治朗は鬼殺の剣士になりたいと

いう意思表明と受け止めた、ということだろうか。

（なお、上記のやりとりの後は、戦闘→炭治朗が気を失う→炭治朗が

起き、富岡は炭治朗に鱗滝を訪ねるように言って去る。

なので、「お前は本気で鬼殺の剣士になりたいか」という

意思を最終確認する場面はない。）

いや、この直接的なやりとりではなく、戦闘直前の炭治朗の懇願

→富岡の叱咤→富岡が禰豆子を切ろうとする→戦闘

の場面で、富岡は無言で炭治朗に覚悟を持たせたと取るべきか。

直接的な「鬼殺の剣士」になる覚悟ではないのだが、富岡は炭治朗の

「鬼の妹を守り、家族の仇を取る」という覚悟は強く受け止めており、

そのためには「鬼殺の剣士」になるしかないことを富岡は知っているので、

帰納的に「鬼殺の剣士」になる覚悟となる。

炭治朗もこの時点では、直接的に「鬼殺の剣士」になる覚悟までは

結びつけてないはずで、鱗滝と会い鱗滝から「妹が人を喰った時

お前はどうする」と聞かれて判断できなかったことなどを通して

鬼殺の剣士の覚悟を固めてくのであろう。

よって富岡の「鬼殺の剣士になりたいという少年をそちらに

向かわせました」というのは、炭治朗が遭遇してしまった

抗あらがいようのない宿命への、厳しさと慈いつくしみからの断言なのだろう。

ーーー

この後、炭治朗は亡くなった家族を埋葬し、鱗滝が居る狭霧山さぎりさやまに

向かうわけだが、父親もいなくて実質的に一家の主である炭治朗と

しては、役所への届けとか、長期不在になることを少なくとも

三郎爺さんとか隣近所には伝えておかないと、とか(もしくは

狭霧山に行けば万事解決し、数日で帰ってこれると考えていた？）、

戸締りは万全だろうかとか、鬼に襲われたことが広まって報道各社が

取材にくるんじゃないだろうかとか、「いや待てよ。なんで自分だけ

無事だったんだと容疑をかけられるのでは？いや炭を売りに行った

町の人や、三郎爺さんがアリバイを証言してくれるから大丈夫だ。」

とか気になったであろう。

（役所とか言い出すと話が進みませんね^^）

最後は逸脱しすぎたが、普通(？)だったら鬼に詳しい人とか

医者に頼ってみようとなるのだが、それでは一般人の話であって、

物語にならない^^

また、そんな覚悟では守ることも仇を討つことも、

なんだかんだと理由をつけて何もしないまま

終わるだけなんだろうな、という戒め。

2020年8月31日月曜日

在宅筋

在宅筋（在宅筋肉, 在筋）とは

在宅勤務で、一人黙々と仕事をしていると、

睡魔に襲われたり、体がなまったりしてしまうため、

自己管理のために筋力トレーニングなどをして付いた

筋肉のこと。

用例

「いい筋肉してますね。あなたも在宅筋ですか？」

2020年8月27日木曜日

MacBook Proを買い換えたい話

Flutterの記事を書いてたりするくらいなので、Flutterでスマホアプリを作っているのだが、

開発マシンは、何と十年来の MacBook Pro (13-inch, Mid 2009)である！

（この、Apple製品を末永く大切に使っているということだけで表彰してくれないかな。）

OSも当初はネコ科のなんかだったが、OSバージョンアップするごとに

重くなっていったのでメモリ8GBへ増設＋ハードディスクをSSDに入れ替えて、

今でも現役で使えている。

ただし、OSのサポートも対象外になってしまったので、OS X 10.11(El Capitan)が

現在の、そして最後のOSバージョンとなっている。

ネットを見たり、YouTubeで動画を見る分には問題ないのだが、

どうしてもバージョンの問題は越えられなくなってきた。

Mac+Flutterでアプリ開発しているので、iOS用にも公開したいのだが、

iOS用アプリを作るにはXCodeが必要。

そしてFlutterは XCode のバージョン11.0.0.が最低要件となっており、

それを入れるにはOS X 10.14.4 ( Mojave ) 以上が必要であった。。。ToT

※あと、確定申告もしているのだが、eTaxの動作環境はOS X 10.11(El Capitan)が対象外で、eTaxページもきっちりバージョンチェックしてるので動かしたくても動かせないToT

なので、VirtualBoxにWindows環境を動作させて行なっている＾＾（USBカードリーダがVM側で認識してカード読み取りも行えたことが何よりの救いだった。ただし動作はものすごく遅いけど。。OS起動するのに数分〜十数分、何か起動するのに数分、と言った感じ。。なんというか苦行である（さっさと買い換えなさい、という話なのだが＾＾）

余談ついでに書いておくと、eTaxのMacOS動作環境としてChromeも対応してほしい。プラスシステム言語を英語にしているとeTaxの初期画面で処理が止まって進めなくなる点も直して欲しい。（開発者ツールで処理を辿ってみると言語環境の問題だと分かった。）まぁこれは日本国内用ページなので聞き入れてくれる可能性は極めて低いが＾＾；）

よほどの細工でもしない限り、この環境は作れないので、

いよいよMacBookの買い換えを検討し始めたわけである。

（OS X 10.11(El Capitan)で入れられるのは、XCode 8.2まで。

　XCode 8.2 を入れて、XCodeからFlutterが生成したios用コード（プロジェクト）

　を開いてビルドできないかも試したがダメだった。

　　 'LaunchOptionsKey' is not a member type of 'UIApplication'

　　 Type 'GeneratedPluginRegistrant' has no member 'register'

　とかエラー出て、完全に基本的なクラスのバージョンが追いついてない。）

（ちなみにAndroidの開発では、デバッグ用のAVD（Androidエミュレーター）は起動できないので、

　実機をUSBでつないでデバッグしてる。AVDも昔は起動できてたが、

　Android Studioのバージョンが上がって、AVDの起動要件としてCPUの

　仮想化の機能が必要要件になってしまったらしい。）

私用で「次世代住宅ポイント」をもらうことができ、交換商品にも

MacBook Proがあったのだが、2019年モデルしかなかった。

しかもこういうポイント制度の製品は原価相当であるということと、

せっかく新しいものが欲しいのにすでに１年分の型落ち製品という

ことで、これに飛びつくには至らなかった。

いろいろ検討しているうちにApple Siliconの話も出てきて、早ければ2020年の

年内にも発売されるとか聞いたので、それまで待つこととした。

（P.S. 本当に2020年末に出ましたね！情報筋の情報は確かにすごいんだな

　と思いました。）

いやぁ、それにしても長い間お世話になったものだなぁ。

※余談だが、どこの記事でも見ないのだが、（敢えて触れないようにしてるのかも

しれないが）、今年(2020年)のMacBook Pro新製品発表　→　Apple Siliconの発表　だが、

MacBook Pro新製品は最後のIntel CPU版Macとなり、買ってしまった人は

「Apple Siliconがでるならもう少し待てばよかった」となるわけで、

結構「酷」な発表順序だったと思うのだが。。。

（むろん商売なので、逆の順番で発表したら誰も買わなくなってしまう、

という判断は当然あるんだろうけど。

買ってしまった人は「最後のIntel版Macという貴重なものを買ったんだ」と自分に

言い聞かせて納得するしかない。無論納得の上で買っているのだろうけれども。

「買い換えタイミングは古今東西いつも難しい」とよく言われるとおりである。

ベストなどなくて、自分がいかに納得するか、なのであろう。）

P.S. (2021年10月)

ついに、M1 Pro & M1 Max搭載MacBook Pro 14-inch/16-inch が発売されました！

Touch Barが廃止されたり、各種ポートが昔のように増えたりしてます。

これは色々試すことで、なぜ物理キーが良かったり、ポートはあまり集約しすぎないほうが良いという具体的な問題点が分かり、原点に戻るというか先祖返りしたようなものでしょうか？（具体的に試して具体的な「理由」を得るという意味でAppleのしたことは無駄では無かった。）

ちょうど現在私が使っているMacBook Pro (13-inch, Mid 2009)と似た構成になっており

（さすがにCD/DVDドライブはなくなったけど…^^（いつの時代の話だと驚嘆することでしょう。））、私的には「Touch Bar?なにそれ」といった感じで、

正に私が買い換えるために作ってくれたのだと思います。（絶対違うけど。）

P.S. (2022年3月)

そしてついにMacBook Proを買い換えました！2009年モデルと比較したのでよかったらどうぞ。

MacBook Proを買い換えた話

2020年8月18日火曜日

人気ゲームFortniteがAppleとGoogleのアプリストアから外されたり、
開発者アカウントを剥奪されそうだったり、何かと話題になっているが
問題の本質は「比重」なのだろう。
　つまり「アプリ市場」という大きな枠で見たときの、市場への貢献度の「比重」。
　AppleやGoogleのアプリストはものすごくよいアプリ配信プラットフォームを
提供してくれており、個人や中小企業など販路を持っていなくても、
アプリを開発するだけで、あとは勝手に全世界のユーザに提供できる
恩恵にあやかれるのである。
　片やFortniteとしては、十分大きなユーザを獲得し、開発にも膨大な
リソースを費やしているにも関わらず、無条件で3割もの利益を吸い上げ
られる仕組みに納得がいかなくなってきたのだろう。
　おそらく結果としては、最初のAppleなりGoogleなりのアプリストアに
配信する時点で、契約として上記内容も「飲んだ」上でアプリ開発しているので
Fortnite側の勝算は低く、そんなことは当のEpicも熟知した上で、
敢えて勝負を挑んで、世界にその理不尽を問いかけたという点で
意味のあるものにしようとしているのだろう。
　
　Apple、Googleとしても、Epicが本気でFortniteユーザをつれて離脱されたのでは
困るだろうから、これを機に「比重」を考慮するポリシーに変更を検討するか
どうか、が今後の注目ポイントである。
　ある意味、それだけの強力なアプリ提供者が育ったため、いよいよ
表層に出てきた問題といったところだろう。
　「アプリ市場」で見たときの貢献者は、アプリストア提供者と
実際のアプリを作ってる者であり、前者はある意味、仕組みさえできれば
あとはほっといても勝手に金が入る仕組みである。
　逆にアプリ開発者はより多くのユーザを獲得するため、恒常的にリソースを
費やしていかなければならない。
　ある規模になると、
　　アプリストアで得られる恩恵　＜　アプリ開発者のコスト
の関係になり、こうなってくるとアプリ開発者たちは「こんなに必死こいて
アプリを作ってるのになんでこんなに利益を巻き上げられなければ
ならないのか？あちらは何もしてないのに。」ということになってくるわけである。
たしかに、自社のために働いているはずが、なぜかストア提供者を
慈善事業的に養ってあげてる感覚になるのだろう。
　または、恩恵を与えてくれた親なので、成人して養うのは良かったが、
親を遥かに凌ぐようになったのにも関わらず、最初に約束した3割負担と
いうのがどこまでも付きまとうので、「親だからって、いい加減に
してくれ！」といったほうが的を得るだろうか？
　たしかに、利益の規模を度外視して3割の巻き上げでは大きくなればなるほど
アプリ開発者側は割に合うまい。
　上記分岐点を境にして、巻き上げ比率引き下げをストア提供側が
検討してくれるかどうか、今後の展開が面白い。
　いずれにしても、これまでもそうであったように、「アプリ市場」などの
全体規模で考えた場合は、それぞれWin-Winの関係に落ち着いていくのであろう。
ーーー
　Win-Winになるかどうかは、問題解決の当事者が問題の本質を
高所から見ることができるかどうかが前提であったりするのだが。
　なにやら開発者アカウントがUnreal Engineまで影響して、サードパーティが
離れていくとか、問題を複雑化しているが大丈夫だろうか？
　過去にも問題の本質よりも、目先の自分の正当性だけ主張して
泥沼化して、結局市場も発展しなくてlose-loseになってしまった失敗事例は
むしろ彼らのほうがよりよく知っているであろうから、ちゃんと
問題の本質を理解して対応してくれるであろう。
　（lose-loseにしてしまった当事者は、社内では「よくぞ我が社の利益を
守った」と言ってもらえるであろうが、業界全体や世間としては、
「あー、はい、そうですか。それはよかったですね」と見られること。）

ーーー
追記
裁判所も想定通りの方向となった。現状では双方譲らない姿勢。
ふと思ったのだが、この「お祭り騒ぎ」も「市場全体」からみれば
多くの人の関心を引くという意味では効果抜群なわけであって、
一旦お祭りが始まったのであれば、なるべく熱を保って長引いた
ほうがよいわけである。
思ったのは、双方ともそれくらいまではわかってるはずで、
つまりそこまで「想定」されてお祭りをしているのではないだろうか？
ということ。（そうなると裁判所の見方も変わってきてしまうだろう。
どうかうまいことやってもらいたいものだ。）

ーーー

さて、AppleもGoogleも年間収益100万ドル以下のデベロッパーに対しては、

30％の手数料を15％に引き下げた。先手を打った形だろう。

「デベロッパーのことを思っていろいろやってるのですよ、文句ないでしょう」と。

しかし上記の「市場への貢献割合」の考え方からするとむしろ逆に

貢献度の低いデベロッパーへの救済策である。

これは富裕層ほど高い税率の考えなのだろうか。

しかしそんなことは行政がやることであってEpicが提唱している問題は

そうではなくて、やはり「市場への貢献割合」の問題であろう。

小規模デベロッパーの30％の手数料を15％に引き下げはむしろ火に油を注ぐ

格好になってるが、大丈夫だろうか？

最初に戻って、これこそが「先手を打った」意味なのだろう。

富裕層からはとことん取るということで、とことんやりあうというわけですね。

おそろしい。

2020年6月5日金曜日

Raspberry Pi で ROBLOX という世界的に有名なゲームを実行

環境

本体: Raspberry Pi 4B
OS: Raspberry Pi OS → LineageOS 16.0

ROBLOXとは

私はハードウェアよりもソフトウェア寄りな人なので、

Raspberry Piを入手して真っ先に試したのがROBLOXを動かす事だった^^

ROBLOX とは世界的に有名なオンラインゲームプラットフォーム。
どちらかというと子供向けであるが、ゲームの内容によって
ものすごく作り込まれたゲームもあったりするので、
大人がやっても面白い。
逆にヘビーなゲーマーでなくてもお手軽にできる点が
いいのかもしれない。

最近はメニューとかも日本語化されたようなので
日本人ユーザも見かけるようになってきた。

（脱線）
アジアで言うとフィリピンと韓国のユーザが多いように感じる。
※フィリピンはタガログ語で会話している人、韓国人はハングル文字を
使ってるユーザで観察した、あくまで私の感覚値。
フィリピン人は英語ができてしまうので、ゲーム中でも普通に英語を
使ってる人も多数いるはずで、そうするとフィリピン人の潜在ユーザは
もっと多いはず。（ご存知の通り文化的にもアメリカナイズされているので
このゲームもみんな普通にやってる。）
それ以外にはベトナム語やタイ語をたまに見かける。ごく稀に中国語を
見たが繁体字だったので台湾人だろう。
（我是變態とか言ってて笑ってしまった。誰も分かるまいとでも思っていたのだろう。）
（簡体字の国は情報統制でできない？あ、ハングルの北の方は言うまでもないですね。。）
（脱線終わり）

結論

最終的にRaspberry Pi上でもROBLOXを動かす事がきた。

ただし、OSはLineageOSというものに入れ替えた。

LineageOSとはAndroidをベースとした、スマートフォンや

タブレット用のフリーでオープンソースなオペレーティングシステムである。

（LineageOS：フリー百科事典『ウィキペディア（Wikipedia）』（2020年4月25日 (土) 09:21 （日時は個人設定で未設定ならばUTC）版より）

LineageOSの公式版ではRaspberry Piは動作対象となってないが、有志が提供して
くれたりするのでRaspberry Pi + LineageOS で検索すればすぐに見つかる。

詳しい手順はみなさんが書いてくれているので、ここでは実際にやってみた
ときの補足説明を書いておく。

まずはLineageOSの作業としては、Raspberry Piとは別のマシン上での操作。
・LineageOSイメージをダウンロード
・新しいSDカードを用意して専用ソフトでLineageOSイメージを書き込み
・SDカードをRaspberry Pi に入れて起動
となる。

次にPlay Storeの追加。LineageOSにはデフォルトではPlay Storeが
入ってないので追加する必要がある。
これも手順（英語）があったので、それに従って実行。
流れ的には
・Play Store追加用イメージをダウンロード
・TWRP recoveryモードで再起動
・Play Store追加用イメージのインストール
・TWRP recoveryモード解除して再起動

まずPlay Store追加用イメージをダウンロードであるが、LineageOS上の
ブラウザでダウンロードできると思うが、私は別マシンでダウンロードして
Android Studio付属の「adb」コマンドでRaspberry Piに転送した。
( adb push コマンド)

次にTWRP recoveryモードで再起動であるが、LineageOS上で以下を実施。
・開発者モードをONにする。(Androidと同じ操作)
・ローカルターミナルをONにする。
・ローカルターミナルappを起動して以下を実行。

su
rpi4-recovery.sh

・再起動

次にPlay Store追加用イメージのインストールであるが、上記で再起動すると
TWRPが起動する。
そのメニューの中に「install」があるので、最初の手順でダウンロードした
ファイルを選択してインストールする。

正常に完了したら本来はTWRPメニューの Wipe → Factory Reset をするべきだが、
私はこの手順を飛ばしてしまった。しかし特に問題はなかった。

最後にTWRP recoveryモード解除して再起動は、TWRPメニューの
「Advanced」にterminal があるので起動して、以下のコマンドを実行。
rpi4-recovery.sh boot
bootが見つかりません見たいなエラーが出たら、TWRPメニューの
Mount → Boot にチェックをつけてから再実行。

これでRaspberry Piを再起動すれば Googleアカウントとか聞かれて
ログインすればPlay Storeが使えるようになる。

あとは普通にPlay StoreからROBLOXをインストールするだけ。

めでたくRaspberry Pi上でROBLOXが実行できた！
が、残念ながら実行速度はかなり遅い。

アーキテクチャ的にはRaspberry PiのARM CPU上で、ARM用の
LineageOSが動作し、その上で(当然ARM構造の)Robloxが動作
しているので、アーキテクチャ的には問題はない。

（他の試行と違ってエミュレータなどを挟んでない、という意味。）

Raspberry Piのマシン的な限界なのだろう。

どれくらい遅いかというと、ROBLOXの人気ゲーム「Tower of Hell」で
最初の階段を登って、最初のブロックに飛び乗ろうとするが
ラグがひどすぎて飛び乗れずに諦めたくらいの遅さであった^^

調査の経緯

最終的にはLineageOSで実現できたのだが、そこに行き着くまでの
経緯も簡単に書いておく。

Raspberry Pi + ROBLOXで調べ始めて最初に出てきたのは「wine」
つまりWindows用 roblox.exe を linux上で動作させましょうという発想。

しかしこれだけだとアーキテクチャの問題が出てくる。
roblox.exe は x86 だけど、Raspberry PiはARMということ。

そこで出てくるのが「ExaGear」。これはeltechsという会社が作ってた
もので、x86をARM上で動かす仕組み。
有償で、動作にはライセンスが必要。
ただしネット上の情報によれば現在はMicrosoft社に買収されたようで
現在ではExaGearは取得できなくなっていた。

他には「qemu」「box86」など。
調査の結果、どこかの記事で「エミュレータでx86をarmには変換できるが
WindowsというOSひっくるめた環境上で動くアプリケーションを
動かすのはまた別の話」みないたところに行き当たって、あぁ
確かにと思った。

そこまでクリアするとなると、かなり壮大な話になってくる。

そこから発想を切り替えて、幸いROBLOXはWindows用、Mac用、
ios用、android用といろいろなプラットフォーム用に作られているので
Raspberry PiのARMアーキテクチャに一番近いAndroidでいけるんじゃ
ないかと行き着いたわけである。

私はゲーマーではないが、たまたま手持ちのAndroidスマホで
唯一遊んでるゲームがROBLOXだったので、Raspberry Piでもできないかな？
せっかく大画面のPCモニターもあるんだし、くらいの発想で
トライしてみた。

「WindowsのゲームもRaspberry Piで遊べないかな？」という発想では
ないので、ご注意いただければと思う。

2020.12.11 追記

「Arm用Windowsでx64エミュレータ実装版が公開」のニュースを目にした。

これって正しく ExaGearを作っててMicrosoft社に買収されたeltechs社に

よる実績だったんじゃないかと思った^^

たしかにこんなことがサードパーティでやられたら、Mirosoft社としては

何かと大切なところを削がれてしまうので買収したのだろうかな。。

2020年6月2日火曜日

Raspberry Pi 4Kモニター文字小さい

【環境】

本体: Raspberry Pi 4B

OS: Raspberry Pi OS

モニター: 某4K PCモニター

【症状及び解消方法】

4Kモニターに接続した場合、Raspberry Pi OSの

初期状態だと、メニューとか全体の文字が小さすぎる

ので、以下で変更可能。

※Raspberry Piに限らず、UNIX系OS全般的に同じような設定で解消可能と思います。

スタートメニュー

→設定(Settings)

→ Appearance Settings

→ Defaults

"For large screens:" を選択

ただし、システム周りのフォントは大きくなるが、アプリケーション

内部のフォントは個別に設定する必要がある。

（中には変更できないものもある。）

その煩わしさを考えると、4Kの恩恵はなくなってしまうが、解像度を

あえて下げるのも一案である。

解像度の設定変更は、

スタートメニュー　→　設定(Settings)　→　Screen Configuration

スクリーンを右クリックして　→　解像度(Resolution)　→　目的の解像度を選択

2020年4月18日土曜日

Flutterのダークモード対応Webview

Flutterでアプリ開発してて、プライバシーポリシーとか
HTMLファイルを表示したい時がある。
（ネットまで接続させたくなく、リソース上の固定HTMLファイルでよい場合。）

また、同時にダークモードにも対応したい場合は以下のパッケージが便利。

simple_dark_mode_webview

使い方は以下の通り。

import 'dart:convert';

import 'package:flutter/foundation.dart';
import 'package:flutter/gestures.dart';
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
import 'package:simple_dark_mode_webview/simpledarkmodewebview.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Simple Dark Mode Webview Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      // ダークテーマを設定する
      darkTheme: ThemeData(
        brightness: Brightness.dark,
        primarySwatch: Colors.green,
      ),
      home: MyHomePage(title: 'Simple Dark Mode Webview Demo'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Container(
              color: Colors.grey,
              child: Text(
                'This widget is useful specially when you want to show a static HTML file!!!',
              ),
            ),
            Expanded(
              child: FutureBuilder(
                // 固定ファイルを読み込む。
                future: rootBundle.loadString('lib/assets/sample_policy.html'),
                builder: (context, snapshot) {
                  if(!snapshot.hasData){
                    return Text('loading...');
                  } else {
                    // ダークモード対応WebViewを使用
                    return SimpleDarkModeAdaptableWebView(
                      snapshot.data,

                      // (例) HTMLファイルのテキストエンコーディングを指定
                      encoding: Encoding.getByName('utf-8'),

                      // (例) WebViewへの操作(ジェスチャー)も登録可能
                      gestureRecognizers: Set()
                        ..add(Factory(() =>
                        TapGestureRecognizer()
                          ..onTapDown = (tap) {
                            final snackBar = SnackBar(content: Text('Webivew was tapped down.'));
                            Scaffold.of(context).showSnackBar(snackBar);
                          }
                        )
                      ),
                    );
                  }
                },
              )
            )
          ],
        ),
      ),
    );
  }
}

2020年4月11日土曜日

Flutterパッケージ公開先の pub.dev で実行してくれる「pana」をローカル環境で実行する方法

【環境】
macOS 10.11 El Capitan
Android Studio 3.6.2
Flutter 1.17.0

【内容】

Flutterパッケージを https://pub.dev に公開すると、スコアリングを

自動で実行してくれるが、その仕組みが「pana」。

これをローカル環境で実行する方法。

https://pub.dev/documentation/pana/latest/

に基本的なことは書いてあるので、補足しておく。

ページには、Installationとして「pub global activate pana」とあるが、Flutterからだと、

flutter pub global activate pana

を実行。

実行結果にインストールされたパスが出力されるので、パスを通す。
(そのコマンドまで表示してくれるので、その通りに行う。
　macOS であれば、 ~/.bashrc などに export PATH=....）

panaの解析を行いたいプロジェクトのパスまで移動。
一旦コマンドを試してみる。
(path_of_the_flutterはご自身の環境のFlutterインストールパス。)

pana --flutter-sdk path_of_the_flutter -s path ./

ここで

pana: line 7: dart: command not found

と表示されたら、dartのパスも通す必要がある。
Android Studio の Android Studioメニュー → Preferences → Languages & Frameworks → Dart

に Dart SDK path が載っているので、このパスもシステムのPATHに登録する。

(先ほどの~/.bashrc などに export PATH=....と同様の手順。)

これで再度panaコマンドを実行されれば結果が出力されるはず。

2020年4月9日木曜日

Firestoreで思った通りのデータが取れない

Androidアプリでリリース版を公開したがFirestoreのデータが
思い通りに取れなかった。

慌ててデバッグし直したところ、以下のようなエラー（警告）が
発生していた。

W/Firestore(nnn): (x.x.x) [Firestore]: Listen for Query(texts where col1 == value order by col2, __name__) 
failed: Status{code=FAILED_PRECONDITION, description=The query requires an index. 
You can create it here: xxxxx

そこに表示されたURLをクリックすれば作成するべきインデックス情報を
引き継いで表示しているれるので、インデックス作成をクリックするだけで
解決。

そもそも、デバッグ版とリリース版で条件を変えていて、以前に動作してた
と勘違いしたため、テストせずにリリースしてしまっていた。

2020年3月30日月曜日

Flutter flutter_launcher_iconsでAndroidのアイコンが変わらない

【環境】

Android Studio 3.6.1

Flutter 1.15.17

使用ライブラリ

flutter_launcher_icons: ^0.7.4
media_notification:
  git:
    url: git://github.com/coderkkc/media_notification.git

【症状】

flutter_launcher_icons でいくらアイコン生成しても
実際動かすとアプリのアイコンが緑色のドロイド君の
まま変わらなかった。

【原因】
原因はなんと、media_notification だった。このライブラリの生成物として
ic_launcher_foreground.pngとic_launcher_background.pngが
含まれており、生成物のマージの順序的にmedia_notification側の
ドロイド君で上書きされていたようだ。

【対策】
出力ファイルのファイル名を変更した。

pubspec.yaml
flutter_icons:
  android: 'my_launcher'　←ココ
  ios: true
  image_path: 'lib/assets/icon.png'
  adaptive_icon_background: '#ffffff'
  adaptive_icon_foreground: 'lib/assets/icon.png'

ただしこれだと、Oreo(API Level 26)よりも前のアイコンしか
指定したアイコン名称になってくれない。
Oreo(API Level 26)以降の「アダプティブアイコン(Adaptive Icon)」は
flutter_launcher_iconsでは未対応のようなので、手動で書き換えた。

android/app/src/main/res/mipmap-anydpi-v26/sodoku_launcher.xml
<xml version="1.0" encoding="utf-8"?><adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android">
  <background android:drawable="@color/ic_launcher_background"/>
  <foreground android:drawable="@drawable/my_launcher_foreground"/>　←書き換え箇所
</adaptive-icon>

あとは以下のフォルダ中の

「ic_launcher_foreground」を

「my_launcher_foreground」に書き換えて完了。

drawable-hdpi
drawable-mdpi
drawable-xhdpi
drawable-xxhdpi
drawable-xxxhdpi

※ ic_launcher_background も使用している場合は同様に修正。

【（参考）調査方法】
プロジェクト配下をファイル名「ic_launcher_foreground.png」で検索。
media_notificationビルドフォルダ中に問題のドロイド君アイコンが見つかった。

また、「merger.xml」中に以下の記述あり。

config=":media_notification" ignore_pattern="!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~">

成果物をマージする設定か？ignore_patternに .png とか入ってないから
ic_launcher_foreground.pngもマージ対象になったのだろう。

なお、試行としてはmedia_notificationビルドフォルダ中のアイコンを
目的のアイコンで書き換えても、ビルド時に書きかわるのでダメ。
「merger.xml」ファイルに

config=":media_notification" ignore_pattern="!.png:!.svn:...

のようにpngファイルを除外させようとしても、
こちらもビルド時に「merger.xml」ファイル自体が書きかわるのでダメだった。

この場合はたまたまmedia_notificationだったが、このライブラリに限らず、ライブラリ作成者がアイコンのことまで意識しないでリソースに入れたままライブラリ化してしまうと、同じことになりそうである。

同じ症状の方は参考にしてもらえればと思います。

2020年3月29日日曜日

Flutter StreamBuilderで状態がずっとConnectionState.waitingの時

【環境】

Android Studio 3.6.1

Flutter 1.15.17

【症状と対策】
Flutter StreamBuilderで状態がずっとConnectionState.waitingの場合は、
setState()とbuild() がループしている可能性がある。

まずはbuild() 中にブレークポイントを貼って、絶え間なく
ブレークするようだったら、setState()を読んでいるところを
潰していく。

2020年3月14日土曜日

大きい数字。桁の大きい数字。数の単位。K M B T Qa Qi ...

大きい数をまとめた。

接尾辞 Suffix		記号 Abbreviation	名称 Name	値 Value
0〜9 -illion	0 cero	K	thousand(kilo)	10³
	1 uno	M	million	10⁶
	2 dos	B	billion	10⁹
	3 tres	T	trillion	10¹²
	4 quatro	Qa	quadrillion	10¹⁵
	5 cinco	Qi	quintillion	10¹⁸
	6 seis	Sx	sextillion	10²¹
	7 siete septiembre	Sp	septillion	10²⁴
	8 ocho octubre	Oc	octillion	10²⁷
	9 nueve noviembre	No	nonillion	10³⁰
10〜19 -decillion -d	10 diez diciembre	Dc	decillion	10³³
	11 once	Ud	undecillion	10³⁶
	12 doce	Dd	duodecillion	10³⁹
	13 trece	Td	tredecillion	10⁴²
	14 catorce	Qad	quattuordecillion	10⁴⁵
	15 quince	Qid	quindecillion	10⁴⁸
	16 dieciséis	Sxd	sexdecillion	10⁵¹
	17 diecisiete	Spd	septendecillion	10⁵⁴
	18 dieciocho	Ocd	octodecillion	10⁵⁷
	19 diecinueve	Nod	novemdecillion	10⁶⁰
20〜29 -vigintillion -vg	20 veinte	Vg	vigintillion	10⁶³
	21 veintiuno	Uvg	unvigintillion	10⁶⁶
	22 veintidós	Dvg	duovigintillion	10⁶⁹
	23 veintitrés	Tvg	trevigintillion	10⁷²
	24 veinticuatro	Qavg	quattuorvigintillion	10⁷⁵
	25 veinticinco	Qivg	quinvigintillion	10⁷⁸
	26 veintiséis	Sxvg	sesvigintillion	10⁸¹
	27 veintisiete	Spvg	septenvigintillion	10⁸⁴
	28 veintiocho	Ocvg	octovigintillion	10⁸⁷
	29 veintinueve	Novg	novemvigintillion	10⁹⁰

※定義自体はこの先もまだまだ続く。
　接尾辞(Suffix)の数字の横に書いたのはスペイン語での数字の読み方。
　(一部カレンダーの読み方も併記)

国際単位系版 (SI : Système International d'unités)

国際単位系 SI		Short Scale
記号 Abbreviation	名称 Name	記号 Abbreviation	名称 Name	値 Value	接尾辞 Suffix
-	-	-	one	10⁰	-	-
da	deca	-	ten	10¹		-
h	hecto	-	hundred	10²		-
k	kilo	K	thousand	10³	0〜9 -illion	0 cero
M	mega	M	million	10⁶		1 uno
G	giga	B	billion	10⁹		2 dos
T	tera	T	trillion	10¹²		3 tres
P	peta	Qa	quadrillion	10¹⁵		4 quatro
E	exa	Qi	quintillion	10¹⁸		5 cinco
Z	zetta	Sx	sextillion	10²¹		6 seis
Y	yotta	Sp	septillion	10²⁴		7 siete septiembre
R	ronna	Oc	octillion	10²⁷		8 ocho octubre
Q	quetta	No	nonillion	10³⁰		9 nueve noviembre

※Short Scaleについては、中盤くらいの説明参照。

和名対応版

接尾辞 Suffix		記号 Abbreviation	名称 Name	値 Value		和名 Japanese			備考
0〜9 -illion	-	-	-	10⁰	one 1	-	一	ichi 1	-
				10¹	ten 10		十	juu 10
				10²	hundred 100		百	hyaku 100
	0 cero	K	thousand (kilo)	10³	one thousand 1K		千	sen 1,000
				10⁴	ten thousand 10K	万 man	一万	ichi-man 1 man	0
				10⁵	hundred thousand 100K (same as below)		十万	juu-man 10 man
	1 uno	M	million	10⁶	1M		百万	hyaku-man 100 man
				10⁷	10M		千万	sen-man 1,000 man
				10⁸	100M	億 oku	一億	ichi-oku	1
	2 dos	B	billion	10⁹	1B		十億	juu-oku
				10¹⁰	10B		百億	hyaku-oku
				10¹¹	100B		千億	sen-oku
	3 tres	T	trillion	10¹²	1T	兆 chou	一兆	ic-chou	2
				10¹³	10T		十兆	juc-chou
				10¹⁴	100T		百兆	hayku-chou
	4 quatro	Qa	quad rillion	10¹⁵	1Qa		千兆	sen-chou
				10¹⁶	10Qa	京 kei	一京	ik-kei	3
				10¹⁷	100Qa		十京	juk-kei
	5 cinco	Qi	quin tillion	10¹⁸	1Qi		百京	hyak-kei
				10¹⁹	10Qi		千京	sen-kei
				10²⁰	100Qi	垓 gai	一垓	ichi-gai	4
	6 seis	Sx	sextillion	10²¹	1Sx		十垓	juu-gai
				10²²	10Sx		百垓	hyaku-gai
				10²³	100Sx		千垓	sen-gai
	7 siete septiembre	Sp	septillion	10²⁴	1Sp	𥝱 jo	一𥝱	ichi-jo	5
				10²⁵	10Sp		十𥝱	juu-jo
				10²⁶	100Sp		百𥝱	hyaku-jo
	8 ocho octubre	Oc	octillion	10²⁷	1Oc		千𥝱	sen-jo
				10²⁸	10Oc	穣 jou	一穣	ichi-jou	6
				10²⁹	100Oc		十穣	juu-jou
	9 nueve noviembre	No	nonillion	10³⁰	1No		百穣	hyaku-jou
				10³¹	10No		千穣	sen-jou
				10³²	100No	溝 kou	溝	ik-kou	7
10〜19 -decillion -d	10 diez diciembre	Dc	decillion	10³³	1Dc		十溝	juk-kou
				10³⁴	10Dc		百溝	hyak-kou
				10³⁵	100Dc		千溝	sen-kou
	11 once	Ud	un decillion	10³⁶	1Ud	澗 kan	澗	ik-kan	8
				10³⁷	10Ud		十澗	juk-kan
				10³⁸	100Ud		百澗	hyak-kan
	12 doce	Dd	duo decillion	10³⁹	1Dd		千澗	sen-kan
				10⁴⁰	10Dd	正 sei	一正	is-sei	9
				10⁴¹	100Dd		十正	jus-sei
	13 trece	Td	tre decillion	10⁴²	1Td		百正	hyaku-sei
				10⁴³	10Td		千正	sen-sei
				10⁴⁴	100Td	載 sai	一載	is-sai	10
	14 catorce	Qad	quattuor decillion	10⁴⁵	1Qad		十載	jus-sai
				10⁴⁶	10Qad		百載	hyaku-sai
				10⁴⁷	100Qad		千載	sen-sai
	15 quince	Qid	quin decillion	10⁴⁸	1Qid	極 goku	一極	ichi-goku	11
				10⁴⁹	10Qid		十極	juu-goku
				10⁵⁰	100Qid		百極	hyaku-goku
	16 dieciséis	Sxd	sex decillion	10⁵¹	1Sxd		千極	sen-goku
				10⁵²	10Sxd	恒河沙 gou-ka- sha	一恒河沙	(same as below)	12
				10⁵³	100Sxd		十恒河沙
	17 diecisiete	Spd	septen decillion	10⁵⁴	1Spd		百恒河沙
				10⁵⁵	10Spd		千恒河沙
				10⁵⁶	100Spd	阿僧祇 a-sou- gi	一阿僧祇		13
	18 dieciocho	Ocd	octo decillion	10⁵⁷	1Ocd		十阿僧祇
				10⁵⁸	10Ocd		百阿僧祇
				10⁵⁹	100Ocd		千阿僧祇
	19 diecinueve	Nod	novem decillion	10⁶⁰	1Nod	那由他 na-yu- ta	一那由他		14
				10⁶¹	10Nod		十那由他
				10⁶²	100Nod		百那由他
20〜29 -vigintillion -vg	20 veinte	Vg	vigintillion	10⁶³	1Vg		千那由他
				10⁶⁴	10Vg	不可思議 fu-ka- shi-gi	一不可思議		15
				10⁶⁵	100Vg		十不可思議
	21 veintiuno	Uvg	un vigintillion	10⁶⁶	1Uvg		百不可思議
				10⁶⁷	10Uvg		千不可思議
				10⁶⁸	100Uvg	無量大数 mu-ryou- tai-suu	一無量大数		16
	22 veintidós	Dvg	duo vigintillion	10⁶⁹	1Dvg		十無量大数
				10⁷⁰	10Dvg		百無量大数
				10⁷¹	100Dvg		千無量大数
	23 veintitrés	Tvg	tre vigintillion	10⁷²	1Tvg	-(未定義) undefinded
				10⁷³	10Tvg
				10⁷⁴	100Tvg
	24 veinticuatro	Qavg	quattuor vigintillion	10⁷⁵	1Qavg
				10⁷⁶	10Qavg	-(未定義) undefinded
				10⁷⁷	100Qavg
	25 veinticinco	Qivg	quin vigintillion	10⁷⁸	1Qivg
				10⁷⁹	10Qivg
				10⁸⁰	100Qivg	-(未定義) undefinded
	26 veintiséis	Sxvg	ses vigintillion	10⁸¹	1Sxvg
				10⁸²	10Sxvg
				10⁸³	100Sxvg
	27 veintisiete	Spvg	septen vigintillion	10⁸⁴	1Spvg	-(未定義) undefinded
				10⁸⁵	10Spvg
				10⁸⁶	100Spvg
	28 veintiocho	Ocvg	octo vigintillion	10⁸⁷	1Ocvg
				10⁸⁸	10Ocvg	-(未定義) undefinded
				10⁸⁹	100Ocvg
	29 veintinueve	Novg	novem vigintillion	10⁹⁰	1Novg
				10⁹¹	10Novg
				10⁹²	100Novg	...

日常生活ではT: trillionくらいまでしかお目にかからないが、
それ以上の数はむしろゲームでよく目にするようになった。

10²⁴: Sp: septillion, 10²⁷: Oc: octillion, 10³⁰: No: nonillion, 10³³: De: decillion はカレンダーの
9月: septiembre, 10月: octubre, 11月: noviembre, 12月: deciembre (スペイン語)
9月: september, 10月: october, 11月: november, 12月: december (英語)
と2ヶ月ずれていると思うが、そもそもカレンダーの方が、
今の呼称とずれてしまったようだ。
※なお、なぜスペイン語を併記しているかというと、単に私がなんとなくスペイン語を勉強してるからというだけです＾＾
おそらくカレンダー呼称に限らず西洋の命数法全体的にもラテン語で考えた方がよりしっくりくるはずです。
本格的に調べたい方はぜひラテン語にも精通してみてください！
※もしこれを読んで本気で学ぼうと思われた方は、本当にラテン語で方向性があっているかどうかはご自身で確認お願いします🙇‍♂️
　もしも方向性がずれてたら申し訳ありませんので。。。

もともとローマ暦では今でいう「3月」が1番目の月だったので、
「9月」が7番目=septiembre
「10月」が8番目= octubre
「11月」が9番目= noviembre
「12月」が10番目= deciembre
ということだったらしい。

また、接尾辞(Suffix)に書いた 0, 1, 2, 3, ... を「S」とすると、
値は 10^3(1+S)と表せる。
例えばSp: septillion であれば septiembreを連想して
7 なので、3 × (1 + 7) = 24 となる。
（実生活では何の役にも立たないが。
生活していて「あれ？Spは10の何乗だろうか？」と
思ったら、インターネットを調べるだろう。）

(更に余計なことを言うと、
M: million は U: unillion
B: billion は D: Duollion
とかの方が体系的にすっきりするが、
インド・ヨーロッパ語族でもないものが
何を言ってるかとか言われそうなので
何も言わない。)

ーーー
国際単位系：SI (Système International d'unités)も追記した。
こちらは、科学界で使うのでキッチリ定義されている。（この後の説明で呼称の拡張の話が出てくるが、SI上はようやく「〜illion(Suffixの0〜9)」の領域が終わったくらいなのでホッとした）
R: ronna = 10²⁷ と
Q: quetta = 10³⁰ は、2022年に制定された！地球の重さは約6 Rg (ロナグラム）らしい＾＾

ーーー
和名については「塵劫記」(jin-kou-ki)と言われる書物が原典だそうだ。

（『命数法』出典: フリー百科事典『ウィキペディア（Wikipedia）』
　2020年4月16日 (木) 02:52 （日時は個人設定で未設定ならばUTC）版より）

和名の右端の備考に、西洋方式に倣って順番に数字を振ってみた。
この数字を「J」とすると、値は 10^4(1+J)と表せる。

和名では10⁶⁸: 無量大数　までしか定義されていないが、日常生活で
そこまで大きな単位を使う事がないので問題となっていないだけである。
もしも千年後とかに日常的に那由他とか無量大数とかまで使う必要が
出てきたら定義が拡張されるのだろう。
「日常的に」というのがミソで、K, M, B, T とか万, 億, 兆, 京とかは
単なる「呼称」であるという事。
「表記」としては、それこそ10^{1,000,000,000,000,000}とかいくらでも
表記できるので、数学上は困らない。

また、例えば通貨だが、日本だと「銭」から「円」になったように、
インフレによって「量はかり」が実態に即さなくなったら、扱いやすい
尺度に変えてしまえば良いので、那由他とか無量大数などが
日常でそのまま使われる事はあまり考えられないのであるが。
（記憶に新しいのはジンバブエドルのハイパーインフレであるが、
　それと同じような事が起きれば、無くも無いのかも知れないが。

　ただそうだとしても、制度として無量大数の次を決めるよりも

　尺度を変えるほうが先に決まるだろうからその線でも考えられない。

　敢えて例えるならば、１円〜１兆円くらいの圏内で生活している人たちと、

　無量大数円くらいのお金をやりとりする人たちが同居する社会とかだったら

　無量大数の次を考えなければならない、とかだろうか。

　つまり超格差社会。せっかくだから言うと無量大数格差社会。

　ただしこの場合も無量大数円くらいのお金をやりとりする人たちは

　そのままでは扱いにくくて仕方ないだろうから、円に代わるものに

　してしまうだろう。）

ーーー
無量大数より大きい単位の拡張方式は大まかに以下の２案が考えられる。
案１：無量大数の次の新しい定義文言を追加していく方式。
案２：現在の万から無量大数までの単位をベースにして、西洋方式に
　　　倣って、「接尾辞」化して拡張する方式。

案１だと定義文言を次々と考えていかなければならないし、既に
「無量大数」という最上級っぽい文言を使ってしまっているので
なかなか大変そうである。
上記で引用した「名数法」に載ってるが、仏典ではもっとたくさんの
文言があるので、それに倣うなども考えられるが、現状の塵劫記の
定義を廃止して新しい定義に置き換えるのは、塵劫記の定義が既に
広く使われてしまっている事から、なかなか考えにくい。

案２は、西洋方式の接尾辞が
10〜19ではdecillionを付けて、接尾辞が無いものから 10³³倍
20〜29ではvigintillionを付けて、接尾辞が無いものから 10⁶³ 倍
という方式を真似る。西洋方式は10ずつなのでわかりやすいが、
和名方式だと万〜無量大数まで16ずつなのでややこしい。

また、接尾辞も、末尾に文字を追加するか、または漢字自体を
拡張するか。
末尾に文字を追加するというのは、例えば仏典を真似して、
末尾に「転」を付けるとかである。
漢字自体を拡張というのは、例えばしんにょうを付けるとかである。

漢字拡張方式だと「恒河沙」とか複数文字になった時にうまくいかない。
拡張する部首の組み合わせも限界がある。
また、上記の例だと「一周」しか拡張できないので、せっかく拡張するのに
もったい無い。

末尾に追加する方式の方が良いが、できれば無限にループして
拡張できる「何か」が良い。

ここでは一旦「転」を付けるサンプルを書いておく。
億転: 10⁷²

兆転: 10⁷⁶

京転: 10⁸⁰

垓転: 10⁸⁴

…
無量大数転: 10¹³²
といった具合である。

西洋方式だと10³がベースで「一周」ごとに10^3*10ずつ増えていく。
和名方式だと10⁴がベースで「一周」ごとに10^4*16つまり10⁶⁴ずつ増えていく。

「万転」はないのか？と思われるかも知れないが、西洋方式の
接尾辞を観察するとわかるが、接尾辞上では「0」は使われずに
「10」の方を使ってるということである。
あえて言えば「万転」＝「無量大数」である。
西洋方式に逆適用すると
kilodecillion = decillion または、
thousandecillion = decillion ということ。

最後に、第３案としては、こんなややこしいことするなら、
「無量大数」の次は西洋方式を用いましょうという案^^

と思ったが、あちらはあちらで short scale と long scale の問題があることが分かった。

このページで書いた「西洋方式」というのは short scale 側だった。

（『西洋の命数法』出典: フリー百科事典『ウィキペディア（Wikipedia）』

　2020年6月4日 (木) 20:18 （日時は個人設定で未設定ならばUTC）版より）

この多様性は言語学のようだ、というか正に数字と言語を結びつけるための呼称

＝「命数法」の問題ということに行き着く。

（最近話題のABC予想にちなんでに言えば「数言際」だろうか。

　※ABC予想も含めて数々の予想を証明できる理論として、望月教授が開発した「宇宙際タイヒミュラー理論」のこと。）

数学的に見れば、「1つの数字に1つの名前をつける」というごく単純な1:1プロット問題なのだろうが、現実世界では歴史とか文化とかが絡んでここまで深遠な世界が広がっているのである。
（言ってみれば「自由度無限大の目で1:1プロット問題を眺める」と言ったところだろうか＾＾　「自由度無限大」というのが現状では「人」とか「人類」になってくるだろうが、これは別にいくらでも拡張可能な話。自分で言っておきながら訳が分からなくなってきた＾＾）

もしもこの命数法問題を根本的に見直したいという人は大変である。
まずは、なぜ 0, 1, 2, 3, ... を
英語では、 zero, one, two, three, ... ※あ、これもラテン語の派生と捉えるなら、やはりラテン語で考えた方が良いですね＾＾
和名では、レイ(零), イチ(一), ニ(二), サン(三), ...
という「読み方」にしたのか？というところから見直さなければならない✌️　（歴史学とか言語形成学？とかの分野）
そこをすっ飛ばして「完璧な」命数法を編み出したとしても、今度は世間が受け入れてくれるか？世間に浸透するのか？という問題が発生する。（それとも「完璧」であれば意外とすんなり受け入れてくれるものなのだろうか？ちょうどいいので独裁国家とかで試してもらいたいものだ＾＾）

なお「完璧な命数法」とは以下のようなものである。
・単位の名称文字列は有限長であること。（そうしないと読み終わることができない＾＾　もしも無限長だったら、うっかり読み上げ始めてしまった人は最悪で、それを読むために一生を使い果たすことになる。。）
・（できれば）無限に拡張可能であること。
（ちょっと考え直したところ、1つ目の条件はなくても良いかもしれない。実際に読み上げるかどうかは別問題であって、別に呼称も無限長でも構わないだろう。今回はとりあえずこの条件で話を進める。）

結論としては、有限個の文字とか単語の結合及び組み合わせ問題なので、文字列を無限長にしない限りは無限に拡張は不可能ということになるだろう（残念！）
無限とは恐ろしいもので、表に書いた　無量大数 = 10⁶⁸ とか、Novg (novemvigintillion) = 10⁹⁰ とかは無限サイドから見ればゴミみたいなものなのである。
有名どこだと、googol = 10¹⁰⁰ とか googolplex = 10^googol = 10^10¹⁰⁰ とかもあるのだが、googolplexであってもたかだか1の後ろに0が10¹⁰⁰個つくだけである。(←話を誇張するためにこのように書きましたが、0近傍の我々からすると、ものすごくバカでかい数です😅)
※ちなみに話は変わるが、無限サイドから素数を求めていく手法を見つければBitcoinで大金持ちになれる＾＾
思えば、無限サイドと0近傍の関係というのは「お互いに観測できるのか？」という問題とも言える。人とか一般生活上はたまたま0を起点として0近傍から無限近傍を考えているだけであるが、無限近傍から0近傍を見れば「無限だ」と思われることだろう。
まさに裏返しの世界である。望月教授の宇宙際タイヒミュラー理論の言葉をお借りすれば、0近傍という宇宙（舞台）と無限近傍という宇宙（舞台）の問題と言えるかもしれない。ここで観測（通信）する観点は「近似」とかになってくるのかな？（数学的には無茶苦茶なことを言ってるかもしれませんので、ご了承ください🙇‍♂️）　（このアイデアについては既述　近傍を変える　と　数学上に「不明」を導入も参照。これは「あるのでもなく、ないのでもない」という概念に発展していくものですね✌️）

「命数法は数学側に近い話なので、言語文化でも特別に「億² = 10⁷²」という表記を許容してはどうか？」という意見もあるかもしれない。（まずは言語学者が絶対に許さないだろうが＾＾；）
もしも運よく許容されたとしても、乗数が呼称の上限を超えた時にやはり読みようがなくなってしまうのである（残念！）
解決策としては「乗数部分も和とか積にすれば良い」というものがある。

つまり、「無量大数 = 10⁶⁸」を呼称の上限とした場合は、
無量大数 = 10⁶⁸ = 10^{4 * ( 1 + 16)}
億² = 10⁷² = 10^{4 * ( 1 + 16 + 1 )}
兆² = 10⁷⁶ = 10^{4 * ( 1 + 16 + 2 )}
...
無量大数² = 10¹³² = 10^{4 * ( 1 + 16 + 16 )}
億³ = 10¹³⁶ = 10^{4 * ( 1 + 16*2 + 1 )}
兆³ = 10¹⁴⁰ = 10^{4 * ( 1 + 16*2 + 2 )}
...
無量大数³ = 10¹⁹⁶ = 10^{4 * ( 1 + 16*2 + 16 )}
...
億¹⁰ = 億^十 = 10⁵⁸⁴ = 10^{4 * ( 1 + 16*9 + 1 )}
兆¹⁰ = 兆^十 = 10⁵⁸⁸ = 10^{4 * ( 1 + 16*9 + 2 )}
...
無量大数¹⁰ = 無量大数^十 = 10⁶⁴⁴ = 10^{4 * ( 1 + 16*9 + 16 )}
...
...
億^10⁶⁸ = 億^無量大数 = 10^{4 * ( 1 + 16*(10⁶⁸ - 1) + 1 )}
兆^10⁶⁸ = 兆^無量大数 = 10^{4 * ( 1 + 16*(10⁶⁸ - 1) + 2 )}
...
無量大数^10⁶⁸ = 無量大数^無量大数 = 10^{4 * ( 1 + 16*(10⁶⁸ - 1) + 16 )}

といった感じである。※すいませんが、最後の億^無量大数〜無量大数^無量大数は、10の何乗がものすごいことになるので実際に数を表すのは省略しました＾＾　また、上記は何かしらミスってるかも知れません😅
（なんだかこれを書いてて何をしたいのか訳が分からなくなってきた＾＾；）

「転」をつけるサンプルで言えば、億² = 億転である。
また、お気づきの通り億 = 10⁸ なので、数学の計算的には、億² = 億 * 億 = 10⁸ * 10⁸ = 10¹⁶ なので、呼称用表記とは整合性が合わなくなってくる。（先に気づけばよかったが、もうこの時点でこの案は脱落だろう＾＾）

続いて、読み方の問題。例えば「億^10⁶⁸」つまり「億^無量大数」は、「億の無量大数乗」（または「億の10の68乗」）と読むし、
「億^10⁶⁹」つまり「億^10⁶⁸*10」は、「億^{10無量大数}」= 「億^{十無量大数}」は、「億の十無量大数乗」とかになってくる。
もちろん読み方のルールを厳密に決めれば読めるのだが、そこまで規定した時に、人々は結局読んだとしても読んだ内容を計算によって０が何個つくのかを求めなければ、それが一体どれくらいの乗数なのかは「瞬時には」わかり得ないということに気づくのである。

話が呼称に戻って来るが、呼称とは結局は命名した対象を把握するものであって、命数法で言えば例えば「兆」とは一体どれくらいかという「概念」は「兆」を聞くことで、和名に親しんだ人であれば聞いた瞬間にどれくらいの「層」に属しているかを知ることができるのである。
この「人とか生活面から見た観点」を「ボトムアップ的命名観点」とでも呼んでおこう。

他方で、「実在する以上は全てのものに名称をつけれるはずだ」といった、トップダウン的な考え方もある。
これを「トップダウン的命名観点」と呼ぶとしよう。

命数法とはいわば、ボトムアップ的命名観点とトップダウン的命名観点が最も顕著に顕在化しやすい概念であったということがわかったというだけでも、今回の考察は意味があったのではないだろうか？（というか、ここまで書いたのであったと信じたいだけなのだが😅）

数学の組み合わせ問題的にも有限長かつ無限に拡張できる呼称は実現不可であることは分かったし、いくら頑張ったとしても結局は「人」側の「認識」が追いつかなくなることも分かったため、呼称問題は、あくまでも「みんなが」「納得する・できる」または「実際上困らない」範囲で決めれば良いのではないだろうか、と思った次第である。

一応頑張って話を続けるならば、log（ロガリズム。対数）を持ってきて、そちら側で命名していくことも考えられる。この点については紙面が足りないため、また別の機会としよう。。
（logにしても呼称が無限長になるのは変わらないが、少しは領域を「把握」しやすくなるだろう。logを「入れ子」にしていけば、ルール上は無限に拡張可能？）

登録: 投稿 (Atom)