ししおどし

SKK Android で SKK と言えば、 SKK for Android (3.4) APK をインストール後、 設定 > システム > 言語と入力 > 仮想キーボード > ＋キーボードを管理 で、SKK for Android を仮想キーボードに追加する。追加した SKK for Android をタップすると、SKK for Android 用の設定画面に入ることができる（この中で最初に、辞書ファイル解凍の実行が必要）。ここで句読点のタイプを「。、」にしておく。 Nintendo Wireless Keyboard (Bluetooth) ペアリング時は Fn を押しながら電源を入れればよい。Gboard のキー配列では「日本語 109A 配列」で ok。 これだけでも SKK の動作に支障はないが、Control キーは多用するので、Caps Lock を Control にしておくのが望ましい。 KCM リマップ （106/109ハードウェアキーボード配列変更 (+親指Ctrl) [日本語配列]）をインストールして、日本語 [Caps]→[Ctrl] の設定を使った。

Mac の Safari でパスワードを記憶したサイトにログインしようとしたら、「このパスワードは以前データ漏洩で検出されたことがあり、強力なパスワードに変更する必要があります」というポップアップメッセージが表示された： 最近になってから初めて経験したが、調べてみるとこれは macOS Big Sur からの新機能らしい。 自分はパスワードについては怠惰で、同じパスワードを使い回ししていたので、ちょっと危機を感じている。 Safari の環境設定のパスワード 他のパスワードやサイトはどうなのかというのが気になったが、ポップアップが表示されてから逐一行動するのもどうかと思った。ちょっといじっていて、「Safari の環境設定のパスワード一覧」に、このデータ漏洩についての警告も表示されているのに気付いたので、これで一目瞭然、対策をとるべきパスワードとサイトがわかる。 デフォルトで有効（✅）になっていたが、「既知の漏洩データによって侵害されたパスワードを検出」がポイントのようだ。

シングルトンは自前の Static Singleton を実装すべきか、Application サブクラスを使うべきか？ Application のサブクラスを Singleton 的な目的で使うことはよくある話だが、実際に Static Singleton を使うのか、（Static Singleton の一種である）Application サブクラスを使うのかには、議論の余地があるようだ。 StackOverFlow の議論： Singletons vs. Application Context in Android? によると、Static Singleton 派と Application サブクラス派に分かれていて、両派ともほぼ対等な支持を得ている。 しかし、公式リファレンスには以下のようにある： ★ Note: There is normally no need to subclass Application. In most situations, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), include Context.getApplicationContext() as a Context argument when invoking your singleton's getInstance() method. この記述を見る限り、どちらかというと、Singleton 的なことをしたいのであれば、単に Static Singleton を使う方がお勧めのようだ。global context を使いたいのであれば、Context.getApplicationContext() で得た Context オブジェクトを Singleton の getInstance() で引数として渡せば用が足るとしている。「Singleton 的なもので、さらに処理の中にグローバルコンテキストを扱うものが含まれるから Application を使う必要がある」と考

アプリのインストール後の初期画面で、ライセンス条項（EULA: End User License Agreement）を表示して、承認を求めるダイアログ（DialogFragment）をライブラリーモジュールとして実装してみた。 基本は DialogFragment なので、下端の Yes/No のボタンに関する挙動と、ダイアログに表示するライセンス条項に関するコーディングが主となっている。 Activity への組み込み方 MainActivity の onCreate 内の処理のかなり初期の段階で @Override protected void onCreate(Bundle savedInstanceState) { (...) EulaDialogFragment.checkLicense(this); (...) } という感じで使う。最新バージョンのライセンスが未受諾であれば、DialogeFragment が実体化される。 また、MainActivity 側では、イベントリスナー（後述）を実装することで、拒絶された場合にアプリを終了する等の挙動を組み込むことができる。 public class MainActivity extends AppCompatActivity implements EulaDialogFragment.Listener { (...) @Override public void onDialogPositiveClick(DialogFragment dialog, long eulaVersion) { Bundle params = new Bundle(); params.putLong("EULA", eulaVersion); params.putBoolean("accepted", true); firebaseAnalytics.logEvent("Installation", params); } @Override public void onDialogNe

クラス クラス名 + メンバー名: 型 ~ メンバー名: 型 - メンバー名: 型 # メンバー名: 型 + メソッド名(引数: 型): 型 ~ メソッド名(引数: 型): 型 - メソッド名(引数: 型): 型 # メソッド名(引数: 型): 型 スコープは +: public; ~: package; -: private; #: protected スタティック変数／メソッドを示す場合はアンダーラインで修飾する。 インスタンス同士の関係 Dependency（依存） independent <- - - - - - - - - - dependent どちらが「依存する側（dependent / client）」で、どちらが「依存される側（independent / server）」なのかを表す。依存する側から依存される側に向かう破線矢印。 Association（関連） label independent <------------------- dependent     1                 1,* 実線で結ばれ、関係名を付す場合には、線の中央の上にテキストを記す。また、多重度（multiplicity）を表す場合には、各ノードの付け根に m..n といった形式で範囲を示す。 さらに、関連性に方向性がある場合には、双方向（bi-directional）か片方向（uni-directional）かによって、矢印で示すことができる。また、自分で自分を参照するような反射的（reflexive）な関連の記述も可能である。 Aggregation（集約） bag ◇------------------- item 集約は関連の中でも特殊なケースで、has-a で表される全体←部分の関係のこと。ただし、合体（Composition）と違って、部分側は全体のライフサイクルに依存せず、独立して存在する。ショッピングバッグに入った色々な野菜のようなもの。 白抜きの菱形で集約先を示す。 Composition（合体） puzzle ◆------------------- piece 合体も関連の中でも特殊なケースで、has-a で表される全体←部分の関係のこと。ただし、集約（Ag

馬場紀寿『上座部仏教の思想形成──ブッダからブッダゴーサへ』によると、「説一切有部や正量部といった諸部派が四諦観察を中心とした修行体系を構築した」としているが、これは語弊のある表現ではないかと思う。というのも、「元々初期仏教には存在しなかった修行体系を、部派時代に新たに作り出した」かのような誤解を生むかもしれないからだ。もちろん、修行体系の詳細にいたるまでの全体的な体系は、各部派がそれぞれ生み出しているわけだが、四聖諦を仏教修行の最も基礎的な枠組みとして中心に据えることは、四聖諦が経典のあちこちで説かれていることからも、部派以前のブッダ在世当時から仏教修行者の間で綿々と実践されていたはずである。 ところが、ゴータマブッダが、菩提樹において、「何を」悟ったのか、という悟りの目的物に関する話題において、初転法輪経などでは明らかにそれが「四聖諦」であることは動かしようのないことなのだが、四聖諦では何ら神秘性がないことから、意味不可解な「縁起」こそがブッダの悟りの目的物であるとする説が生じ、やがて四聖諦を押し退けて縁起に究極の重要性を持たせようとする数百年の活動によって、仏教に歪みを蓄積させることになった。 また、四聖諦の「滅諦」が「単なる苦の抑止」ではなく、「涅槃」を意味することになったため、四聖諦の意味することが本来の意味とは別のものとなってしまい、矛盾を生じることになってしまった。その涅槃へと到達するための鍵・パスポートとなる概念として縁起が神秘性を持って語られるようになった。 そのようにして、（本当はこちらがブッダの悟りの目的物であったはずの）四聖諦が正常に機能しなくなり、一方で縁起がブッダの悟りの目的物であるという思想が一般的となってしまった時代に、上座部大寺派にブッダゴーサが登場する。彼は正常に機能しない四聖諦についての問題を解消すべく、縁起が（縁起も）ブッダの悟りの目的物であるという説に基いて、依然として四聖諦がブッダの悟りの目的物であるという説と併存していた状態からさらに進んで、むしろ縁起こそがブッダの悟りの目的であるという説の方を強調して、四聖諦がブッダの悟りであるという説の方をフェードアウトさせたのである。 ここで一つ忘れてはならないのが、ブッダゴーサの仕事は、本来あくまでも上座部大寺派「内部」でのものだったという点である。馬場の論文によると、ま

最近、個人的な経験がきっかけで四聖諦について考えていて、ある一つの発見があった。そしてふと、（中身がすっかりすり代わって実質的に別物と化してしまった大乗仏教はそもそも論外としても）現存する仏教の中で最も原始仏教寄りである上座部仏教（テーラワーダ）にしても、より古い時代の仏教とは違っている部分があり、元々は四聖諦そのものが修行内容だったというような話があったのを思い出した。東大の学者で馬場という名前だけが記憶に残っていたので、早速調べて、馬場紀寿『 上座部仏教の思想形成──ブッダからブッダゴーサへ 』であることがわかり、再度、手に取って読み直してみた。 上座部の系譜 この部分の話はこの本の主題そのものではないのだが、上座部仏教の系譜について知らない人にとっては簡潔に良くまとまっている（流石は東大出身の人だけはある）文章なので、一読の価値はあると思う。 したがって、上座部仏教の〈独自性〉と〈同一性〉の両者は、五世紀前半、スリランカの上座部大寺派へ集約される。上座部仏教が他の仏教とは異なる固有の性格を帯びて、その〈原型〉を形成したのは、5 世紀前半の上座部大寺派においてなのである。そこで 5 世紀前半の上座部大寺派が果たした歴史的役割を検討するために、上座部仏教の歴史を概観した上で、上座部仏教がその〈原型〉を形成した時代・場所・人物を改めて特定し、そこに研究の焦点を絞ることにしたい。 スリランカには、紀元前 3 世紀頃にインドから仏教が渡り、アヌダーダプラの都に大寺（Mahāvihāra）が建てられた。紀元前 1 世紀頃には、同じアヌラーダプラに無畏山寺（Abhayagirivihāra）が建てられ、その後、祇多林寺（Jetavanavihāra）が建てられた。これら 3 派はいずれも「上座部」の系統だったが、大乗仏教に対する態度は、大寺派とその他 2 派ではまったく異なっていた。 大寺では、紀元前後から三蔵に対する註釈が作成されるなど、思想活動が続けられていたと考えられるが、5 世紀初頭にブッダゴーサ（Buddhaghosa）という学僧が登場し、これらの古資料を踏まえて、上座部大寺派の教学を体系化した。現存資料を見る限り、「上座部」や「大寺」の伝統を掲げて作品を著し、思想を体系化したのは、ブッダゴーサがはじめてであって、彼以前に遡ることはできない。ブ

既に時代遅れ機種になっている Nexus 6P だが、昨日、適当に野良 APK をインストールしたら、何となく怪しい挙動を見せたので、ファームウェアのファクトリーリセットのついでに、最終バージョンの 8.1.0 から 7.1.2 にダウングレードした。 ダウングレードであろうが、アップグレードであろうが、任意に選んだファームウェアを焼くだけなので、基本的な手順は同じである。 ファームウェアの焼き方 公式ページ（ Flashing instructions ）に基本的な情報は揃っている。 基本的には、該当ファームウェアをダウンロードすると、ファームウェアを焼くためのスクリプト（flash-all.sh）が含まれているので、それを実行すればいい。ただし、このスクリプトが前提としている fastboot コマンドが実行可能な状態を整えておく必要がある。 また、セキュリティのために、ファームウェアの書き込みロックがかかっている場合は、書き込み作業の間は解除しておく必要がある。 Nexus6P を fastboot モードにする fastboot コマンドの準備（Mac 側） ファームウェア書き込みのロック解除 以上の 3 点を除いて、USB ケーブルで Mac と接続し、Mac 側で公式ページからダウンロードした Nexus 6P 用の 7.1.2 のファームウェアファイル（👉 N2G48C, Aug 2017 ）の中の flash-all.sh を実行するだけのシンプルな作業である。 Nexus6P を fastboot モードにする fastboot モードは、fastboot コマンドと同じく Android SDK Platform-Tools（後述）に含まれている adb コマンドを使う（'adb reboot bootloader' コマンドを実行）か、Nexus6P を操作してボリューム下げボタンを押し続けながら電源ボタンを押し続けて起動することで、fastboot モードに入ることができる。 fastboot コマンドの準備（Mac 側） fastboot コマンドは Android SDK Platform-Tools に含まれるものなので、Android アプリ開発用の Androids