投稿

父の死 10 法定相続情報証明制度

各所における相続手続にあたって、法務局の 法定相続情報証明制度 を利用した。 不動産や銀行預金などの相続手続において、相続される財産をもらおうとするその人間が「はたして本当に正当な相続者なのか?」を、財産を預る銀行等は判断する必要がある。その判断は、戸籍と遺言書や遺産分割協議書に基く。 被相続人(故人)の戸籍 まず、法定相続人(法律的に正当な相続権のある人間)の全員を把握するために、被相続人の出生から死亡に至るまでの戸籍謄本を揃える。これによって、被相続人の結婚・離婚歴とを通じた全ての子供を把握することができる。これらの子供は全て、法定相続権を持つからである。一方、配偶者の場合は、死亡時の配偶者にしか法定相続権はなく、離婚した場合の元妻(元夫)には法定相続権はない。 法定相続情報一覧図 基本的に、法定相続情報証明制度は、法定相続一覧図(家系図のような形で、被相続人とその配偶者・子供を示した図)が、戸籍に基いて正確なものであるということを、法務局がチェックし、お墨付きを与えるものである。この場合、戸籍謄本等を提出するのは、法務局に対してすればよく、銀行などに手続する際には、不要となり、法務局が発行してくれた法定相続情報一覧図を提出するだけで済むようになる。 今回実際に利用してみたところ、提出後一週間で発行された。記載事項にいくつか不備があったが、法務局から連絡があり、都度指示に従うなどして修正することで対処できた。法定相続情報一覧図には、各相続人の住所も含めることができ、住所を含めておくと、さらに各所の手続で住民票の提出が必要な場合に省くことが可能になる。この場合、ぴったり住民票の記載通りに記載しなければならなかったのだが、そこがいい加減だったので、修正が必要だった。 遺産分割協議書 法定相続情報一覧図が準備できたので、次に、遺産分割協議書を作成した。ウチの場合は、父が遺言書を遺していなかったためである。そのため、法定相続人である、母と自分と 2 人の弟との 4 人の協議で、父の遺産をどう分割するかを決めることになる。その決めた内容を文書にしたものが遺産分割協議書というわけである。この遺産分割協議書の正当性を示すものが、先述の法定相続情報一覧図になる。つまり、その分割協議が、相続権のある者全員の合意によるものであることを証する。 遺産分割協議書...

父の死 9 遺族年金

本日、母と年金事務所に行き、死亡届や遺族年金(遺族厚生年金や寡婦加算)に関する手続をしてきた。ネットで調べた前情報によると、遺族厚生年金は父がもらっていた額のうちの報酬比例部分の 3/4 程度の額をもらえるとの話だったが、だいたいその通りの額になったみたいだ。母自身の国民年金の額は微々たるものだったので、遺族厚生年金がもらえるかもらえないかは今後の問題として大きい。手続が終って、一安心である。(後記:11 月に入り、無事の予定通りの金額が通知された) これであと残るは、相続の問題である。父は遺言を残していないのだが、生前の遺志により、基本的に母が全てを相続する予定である。これから遺産相続協議書を作成するにあたって、まず、法務局の 法定相続情報証明制度 を利用するつもりであり、本籍地の市役所に出生から死亡までの連続した戸籍謄本を請求中である。法定相続情報というのは要するに、全ての相続人をその相続人一覧図が網羅していることを証明するものである。例えば、再婚するなどして、故人の子供にとって片親違いの兄妹姉妹がいるような状況になっていた場合、ちゃんと全ての相続人の同意が得られた遺産分割内容なのかを明確にする必要があるためだ。 従来は、相続人一覧図と、それを証する出生から死亡までの連続した戸籍謄本などを、遺産を管理する各関係窓口(法務局や銀行、証券会社)で手続する毎に提出し、窓口の担当者がそれらを照合して内容が正しいかを判断していた。法務局の法定相続情報証明制度を利用すると、内容の照合は法定相続情報証明の登録時に行い、あとは法務局から証明付きの相続人一覧図を必要な部数だけ無料で発行してもらえるので、それを各関係窓口に提出するだけでよくなる。

父の死 7

今日は最寄りの年金事務所へ、死亡届と未支給年金請求(+母の遺族厚生年金)の手続のために行った。戸籍謄本を始めとする予め必要な書類を揃えて、さらに申請書なども Web からダウンロードして記入済の状態で、満を持して、14日以内とされる期限ギリギリのタイミングで行ったわけだが、「コロナ禍のため、予約がないと駄目」とあっさり門前払いされた。予約だけしか受け付けてもらえなかった。こういうことならば、もっと早めに電話で問い合わせておいた方がよかったのかもしれない。「コロナ禍の密を避けるため」なんて大義名分を掲げているが、どうも国家公務員のこの種のセリフは、国民側のためではなく、職員(国家公務員側)をコロナ禍から守ったり、仕事が忙しくなることを避けることにむしろ本音があり、おためごかし的に掲げられた大義という感じが拭えない。 この辺り、地方自治体の窓口の地方公務員とは、市民との距離感が対照的な気がする。 ちなみに、14 日以内という期限だが、弁護士・司法書士・行政書士などの法律家が執筆しているようなあちこちの相続関係の情報サイトなどで、さも当たり前のように書かれていたのだが、自分で政府( 日本年金機構 )のサイトを調べた限りでは、どこにもそのような期限は書かれていなかった。今日、年金事務所の窓口で門前払いされる時、「14 日以内に手続きしなければいけないのでは?」と言うと「そういうわけではない」と言われた。一体、弁護士資格とは……。 まあとりあえず、年金関係はひとまず来週の水曜日(10/6)に延期になった。 もう一つ、国民健康保険関係で、こちらは市役所の窓口に行った。後期高齢者医療の資格喪失届と、葬祭費の申請。さらに介護保険の資格喪失手続を行った。

アフガニスタン最大民族パシュトゥン人=ユダヤ人の失われた10部族の末裔

2015-04-12 だからもう 6 年以上前の記事 になるが、「現代のアフガニスタン全域とイラン東辺部までを含む領域が、シャカ族の勢力圏だった」というラナジット・パール氏の説を足掛りにして、シャカ族の王都カピラワットゥ=(現代の)カブールであるという説を展開した。また、パール氏の「シャカ族とヘブライのダン族の関連性」から、ガンダーラ地方全体が、実際の「約束の地=イスラエル」ではないかという説にも発展させた。 今日、「 アフガニスタン最大民族パシュトゥン人=ユダヤ人の失われた10部族の末裔 」という説があったという話を初めて知った。 この民族はかねて「イスラエルの子孫」であると口述伝承してきたという。 加えて、生後8日目で割礼を行い、肉とその乳を共に食さない。安息日の前夜にろうそくを灯すこと、寡婦が死亡した夫の兄弟と結婚する「レビラト婚」などを慣習としており、古代ユダヤ教の戒律や習慣と共通する。 自分がパール説を元にして展開した説は各種状況証拠から推理したものだが、このような直接的証拠があったということはむしろ、自分の推理の展開の仕方が妥当であったということの裏付けになるのではないかと思う。

ステップアップ OpenGL ES 2.0

イメージ
0. OpenGL スケルトン Android では、GLSurfaceView の枠組みの中で OpenGL を処理する形になる。 1. タイルを表示するサンプル 4 個の頂点座標データに基いて、たった一つの矩形のタイルを描くだけだが、この最初の一歩の段階で一挙にハードルが上がる。主には、シェーダーで定義した変数を通じて頂点データを入力するための手続。あとは Kotlin / Java 固有の話として、ダイレクトバッファの形でデータを OpenGL 側に入力するという点。 シェーダー Kotlin / Java 側では、シェーダーは String データに過ぎないが、OpenGL 内部での処理を GLSL で定義するもの。C 言語的なスクリプトであり、公式の クイックリファレンスカード によくまとまっている(詳細な リファレンス も公開されている)。gl_* が予約された変数で、この変数に意図した値を出力することで OpenGL 内の次の処理へと頂点データが渡ることになる。 このサンプルでは、a_Position を通じて Kotlin / Java 側から入力した値をそのまま次へリレーしている。またフラグメントシェーダーにおいては、u_Color を通じて Kotlin / Java 側からセットした値をそのまま各フラグメント(ピクセル)の色として渡している。ちなみに、u_Color は uniform なので、いわゆるグローバル変数的なものとして定義されており、4 つの全ての頂点間で共有されている。一方の a_Position の方は attribute であり、各頂点毎に属する値である(cf. クイックリファレンス p3 Qualifiers)。 シェーダーの使い方 各シェーダーをコンパイルし、バーテックスとフラグメントを組み合わせて一つのシェダープログラムとし、さらに今有効なプログラムとしてそれをセットする(シェーダープログラムは複数用意して使い分けることも可能なため)。 シェーダー変数の確保 シェーダープログラムから、OpenGL への入力に使用するシェーダー変数(のポインターインデックス)を得る。 頂点データの配列 Kotlin / Java 固有の話として、JavaVM 内部のメモリーヒープを使うわけにはいかな...

Android / Java と OpenGL ES 2.0 の要点

以下のような人(要するに僕自身のケースと同じ)を対象にしている: Android / Java のアプリ開発についての一般的な理解はある ImageView.onDraw や SurfaceView による動画ならそれほど苦労せずに理解できた しかし、OpenGL (ES 2.0) のことになると色んな解説やサンプルコードを見ても理解に苦しんで中々はかどらない なぜ OpenGL はわざわざああいうことをするようになっているのか? ImageView.onDraw や SurfaceView による動的グラフィックスなら理解しやすかった人にとって、動画とは、パラパラ漫画のようなものというほとんど無意識的な大前提があるわけだ。パラパラ漫画に限らず、映画やアニメなど、世の中の映像記録方式としては、こちらが圧倒的主流。ImageView.onDraw や SurfaceView の場合も、ループを回して、フレームバッファに次々とコマを描き込むだけ。 ところが、OpenGL はそれを許してくれないので、何か物凄く高度な、GPU のハードウェア的な性能を引き出すために、OpenGL の API を通じて描画する必要があるのかと、勘違いする。実際はそう(高度な GPU のハードウェア的な性能を引き出した上でレンダリングするのが目的の API 体系)ではないので、架空の妄想を相手に戦う羽目になり、決して勝利することができない戦いに挑む形になる。 OpenGL はそもそも、パラパラ漫画的なことをプログラマーが自らやることを想定していない(GPU 側の内部処理として行われる)。その一歩手前の部分(モデリング)を主にするのがプログラマーの仕事。モデルを基にしてラスタライズしてフレームバッファに落し込む処理は、GPU 側が(プログラマーが予め定義したフラグメントシェーダーに従って)内部的に行う形になっている。つまり、プログラマーがすべき仕事の領域がそもそも異っている点に気付かなければならない。 言ってみれば、フレームバッファ描き込みによるパラパラ漫画的動画はチカチカと瞬く GIF アニメみたいなもので、OpenGL はヌルヌル動く Flash アニメーションみたいなもの(Flash ももう過去の遺物だが……)。他にも、ペイント系グラフィック(ビットマップ...

MVVM のバランス──DataBinding を使うのをやめた

以前の記事「 LVMC (a.k.a. MVVM: ViewModel + DataBinding) と Fat View 」では、使い方を覚えた DataBinding で調子に乗って、何でもかんでも処理を View-Controller 側に詰め込んでしまい、Fat View に陥いるという反省を経た。 結局、MVVM というより DataBinding がイマイチ良くなかった気がする。DataBinding を使おうとすると、どうしても無理してレイアウトで静的に記述しようとするために、その皺寄せを View-Controller 側なり、ViewModel 側なりに押し付けてしまうわけである。以前の記事の時は、DataBinding の皺寄せを、View-Controller 側に詰め込んだのを、ある程度 ViewModel にも分担させるべきだという反省だった。今回は実のところ、ViewModel 側に DataBinding の皺寄せを詰め込み過ぎたのである。 例えば、モデル側から画像のリスト(LiveData)を得てスライダー操作でその中から一つの画像を表示するとする。この場合、DataBinding と ImageView の立場からすると、ImageView は単に DataBinding で記述された静的なレイアウトから src を読んで表示するのが楽である。src がリストから抜き出されて変化するかどうかなどということは、ImageView 側は何も意識する必要がない。 となると、スライダー操作によってリストから一つの画像を抜き出す処理は全てバインドされた ViewModel 側に記述する必要がある。これがやってみると恐ろしく大変な作業で、抜き出される画像は、まず LiveData であるリストの変化を observe する必要があり、さらにスライダー操作によって抜き出すインデックスの変化をも observe する必要がある。こういった形でスパゲッティのように絡み合った observe / observant の LiveData で連鎖する回路を ViewModel 中に記述する羽目になる。 一度、上記のようなスタイルでアプリを構築したのだが、結局リファクタリングの際に見直して、普通に Activity / Fragment 側のイベン...

Inkscape 0.92.5

Inkscape (0.92.5) の macOS 版は MacPorts 版を使うべし。 MacPorts 版の Inkscape をインストールするには、もちろん、, MacPorts 自体 をインストールして使えるように準備しておく必要がある。.pkg のインストーラーが使えるので、難しくはないはず。 そして、MacPorts によってインストールするのは、Inkscape だけでなく、X.Org Server も必要になる。 sudo port install inkscape sudo port install xorg-server これで一旦再起動する。X.Org を先に立ち上げてから、ターミナルで inkscape コマンドを実行すれば Inkscape が立ち上がる。 起動時の警告 起動時に、ターミナル画面に警告メッセージが表示されるが: Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded! Failed to get connection dbus とやらのセットアップに関するもののようなので、sudo port load dbus による指摘に従えば解消できる: port notes dbus dbus has the following notes: Startup items (named 'dbus-system, dbus-session') have been generated that will aid in starting dbus with launchd. They are disabled by default. Execute the following command to start them, and to cause them to launch at startup: sudo port load dbus つまりこの場合 sudo port load dbus を実行して一度セットアップしてしまえば、以後...

Mac → Mac のメールアカウントの移行

イメージ
旧 Mac(MacBook 12inch Early 2015)から新 Mac(MacBook Air M1)へメールアカウントを移行した。IMAP なので、データをエクスポート&インポートするような必要はなく、新 Mac 側でメールアカウントをセットアップするだけである。それもメールアカウントの設定自体、iCloud で管理しているので、新 Mac 側で iCloud へサインインした段階で復旧される。 メールの動作に不具合が発生 ところが、メールの動作に不具合が発生した。削除したはずのメールが何度も何度も受信ボックスに戻ってくる。 仕方ないので、一旦メールアカウントを iCloud に保存された設定も含めて削除して、改めて手動で設定し直した。すると問題は解消された。 IMAP アカウントの設定 Gmail などのテンプレートにあるアカウントの場合は問題ないと思うが、その他の一般の IMAP アカウントを設定する場合、デフォルトでは、メールボックスの設定がうまくいっていなかった。メールサーバーに元からある受信・送信済・ゴミ箱・迷惑メールが使われず、新たなメールボックスがそれぞれ作られてしまうので、手動で設定し直して、重複するものを削除する手間が必要だった。 @sakura.ne.jp(独自ドメインメール): IMAP を使っているのでポート番号などのサーバ設定等は細かく設定し直す必要があり、単に iCloud からの復旧されたデフォルト設定のままでは上手く機能しない。旧マシン(macOS)の各設定画面を記録しておいてそれを参考にすると復旧しやすい。 @gmail.com: メールボックスなどの反映に少々のタイムラグがある。そのままでも大丈夫だと思うが、メールボックスの割り当ては再設定し直した方がより確実かもしれない。 署名の設定 署名もデータ自体は残っているものの、アカウントとの紐付けが復元されなかったので、改めて手動で設定し直す必要があった。すべての署名からアカウント毎にドラッグして移動した上、「署名を選択」で該当署名を選択しておくことで、メール作成時に自動で署名が入るようになる。

タリーズ Wi-Fi で Mac をインターネットリカバリー

イメージ
新しい Mac(MacBook Air M1)を入手して移行作業が終了したので、これまで使っていた MacBook 12inch(Early 2015)の方は初期化することにした。ディスクユーティリティで Macintosh HD を一旦消去してから、Big Sur を再インストールしようとしたが、その時はネットワークが遅かったせいか中々進まなかったので後でやり直そうと思い、電源を切った。そして改めて再インストール作業をしようと立ち上げたところ、Macintosh HD 自体を消去してしまっているため、macOS 復旧プログラム自体が起動しない状態になってしまっていた。まあ、ある意味当然と言えば当然である。 初めてこのような経験をした時は青くなったものだが、今は特に致命的ではないことを知っているので冷静に インターネットリカバリーモードで起動 する。ただし、この場合は macOS 復旧プログラム自体をネットワークからメモリーに読み込んで起動して行うことになるので、途中で作業が失敗して中断してやり直したりする場合は、最初の macOS 復旧プログラムをネットワークから読み込む段階からの再開となる点に留意したい。致命的ではないものの、それなりの手間(時間)のかかる作業となるのである。 リカバリーモード には次の 3 種があるわけだが: Command + R(Macintosh HD からのブート) Option + Command + R(最新 OS のインターネットブート) Option + Shift + Command + R(購入時 OS のインターネットブート) (1) は Macintosh HD を初期化してしまっているので当然使えない。使えるのは (2) か (3) だが、(3) だと購入当時の旧い macOS 復旧プログラム(Yosemite)のものが使われ、APFS にすら対応していないので、やはり論外。(2) だと Big Sur 用の復旧プログラムが使われるので、これを選ぶ。 ※ この macOS 復旧プログラムのネットワークブートは、回線の繋がりがあまりにも悪いと、-2006F エラー等でブート途中で失敗してしまうことがある。回線の繋がり方にも、モバイル回線のせいや、Apple のサーバーのせいなど、様々な要因が...