March 10, 2021
3月9日、令和2年の確定申告を無事に終えることができました。
ただし、今年は初めてマイナンバーカードを使った電子申告を行おうとした結果、いろいろと思い出深いできごとがあったので、ブログに記録しておくことにしました。
マイナンバーカードの取得 # まずは何はなくともマイナンバーカードを取得しなければなりません。11月の終わりにスマホで渋谷区に申請を行い、申請自体はスムーズに完了しました。
スマホ申請だと他よりも早く4週間程度で完成すると書かれていたので、年内にできあがるかと思ったのですが、混雑していたのか完成連絡は1月の中頃になりました。
受取は要予約でしたので、予約しようとしたところ、最寄りの出張所はすでに2月中頃まで予約で埋まっていたので、1月中に受け取れるヒカリエのサービスセンターで受け取りをしました。
その際に署名用電子証明書のパスワードを登録するのですが、どたばたしていてメモを取るのを忘れていて、後ほどパスワードを忘れてしまうという失態を犯してしまいました。
マイナンバーカードのパスワードリセット # 3月に入り、いよいよ確定申告をする段になって、iPhoneでマイナンバーカードが読み取れるかどうかを確認するため、JPKIMobileアプリで署名用電子証明書を確認しようとしたところ、パスワードが思っていたものと異なり、5回間違えてしまったためロックされてしまいました。
パスワードロックされてしまうと、市区町村のサービスセンターでしかリセットが行えないらしく、そのため最寄りの出張所へ足をはこび、パスワードリセットを依頼しました。
窓口で「マイナンバーカードの署名用電子証明書のパスワードを5回間違えてロックされてしまったので、パスワードリセットをして欲しい」とお願いしたところ、「ちょっと意味が分からないです」と言われてしまいました。
どうやら、マイナンバーカードは英数を使っていても「パスワード」ではなく「暗証番号」で用語統一されていて、さらに申請書にはリセットではなく「署名用電子証明書の再設定」と書かれていたので、「署名用電子証明書の暗証番号を再設定して欲しい」と伝えなくてはならなかったみたいです。
ただ、「署名用電子証明書の再設定」というと、証明書自体が書き換えられてしまうのでは？と思ったので、念のため「証明書自体は書き変わりませんよね？」と確認してみたのですが、想定通り「ちょっと言ってる意味が分からない」という回答を得ました。
覚悟を決めて再設定をお願いすると、今度は操作画面に「暗証番号を初期化します」と書かれていました。初期化だと、元に戻ちゃうよなぁと思いつつ、そこは無視して新しい暗証番号（パスワード）を入力して、書き換えてもらった後、その場でスマホを使って読み取ってみたところ、今度は無事に表示されることを確認しました。
なお、証明書が書き変わっていないかは確認するすべがありませんが、おそらく変わっていないかと思います。
確定申告のために購入したもの # 確定申告をできるかぎり快適に行うため、いくつかのアイテムを購入しました。
ICカードリーダー # 当初、iPhoneさえあればMacBookから電子申請が行えると思っていたのですが、どうやらAndroidと違ってiPhoneは、パソコンのICカードリーダーとして使えないみたいで、iPhoneから確定申告をすれば電子申請できるけれど、僕はパソコンからしたかったのでICカードリーダーを購入しました。
I-O DATA ICカードリーダーぴタッチ USB-NFC3 amazon.co.jp いまMacのデバイス界隈では、M1やmacOS 11などでデバイスドライバの互換性が失なわれるケースがあり、現時点でIntel MacBookのmacOS 10.15を利用している僕としては、今後のことを考えて両方のOSとハードを公式にサポートしているICカードリーダーを購入しようと思って、これを選びました。
ちなみに他には、エレコム ICカードリーダー MR-ICA001BKくらいしか選択肢がなかったのですが、値段が安くて即納されるI-O DATAを選択しました。
到着後、すぐにIntel MacBookのmacOS 10.15でも問題なく読み取れることを確認しました。
テンキー # 経費関連はカード明細など電子データを利用しているので、これまでたいした情報を入力することがなかったのですが、今年は年齢のせいもあり、医療費控除を受けられるくらいの医療明細が溜っていて、医療明細は現金払いの紙データしかないため、これを入力して計算する必要があり、HHKBやMacBookのキーボードで大量の数字を入力するのはつらいと思ったので、テンキーを購入しました。
東プレ REALFORCE23UB テンキー WC01B0 amazon.co.jp なんとなく、黒くてBluetooth接続できるやつがいいなと思っていたのですが、いつものvim-jp Slackの#hobby-gadgetで相談してみたところ、最高のテンキーはやっぱりREALFORCEやろJKとの煽りを受けました。
さすがに高いし、USB Type-Aなのもなと思ったのですが、中古の備品で8000円のものがあったので、8000円だったらまぁいいかと思い、これを購入しました。
実際に医療明細を入力してみた感想としては、やはりテンキーがあると圧倒的に入力が早く、静電容量無接点方式で普段使っているHHKBとの使用感の差もほとんどないため、ストレスなく快適に作業ができて、REALFORCEテンキーにして正解だったなぁと思いました。
ちなみに、USBはAtoCアダプタを使ってUSB-Cで接続して、DIPスイッチは1010にして利用しています。写真のように、HHKB、MX anywhere3と色の統一感もあります。
...
January 8, 2021
謹賀新年あけましておめでとうございます。
2020年に買って良かったものをブログに書こうと思っていたら2021年になってしまったのですが、ようやく重い腰を上げて書き上げましたので新年の挨拶とあわせて公開しておきます。
ガジェット編 # まずは、2020年に購入したガジェット系です。
これは、購入したモニタとiPadで5モニタ環境を作ってみたときの写真です。
エルゴトロン LXデュアルデスクマウントアーム 45-248-026 amazon.co.jp これまで外で作業することが多く外部モニターに頼らない縛りを自分に課していたのですが、コロナ禍があり自宅作業の比率が圧倒的に上がったため、外部モニターの購入を決断しました。その際にはじめてモニターアームを買ってみたのですが、リビングでの仕事 + 小さな子供がいる生活だと、モニターアームはとても便利で、結果的に2020年に買ったもののなかで一番良かったのはこのモニターアームになりました。
モニターアームがあると、食事の時でもさっとリビングテーブルの上を片付けられて、かつ、LXデュアルにはノートトレーが付属しているため、作業中断時ははトレーを子供の手の届かない高さに上げることで、素早くPCを子供に触れられないようにできるのも良かったです。
LG 23.7インチ UltraFine 4Kモニター 24MD4KL-B amazon.co.jp 外部モニターは、MacBook専用の24インチの4Kモニターを最初に購入しました。24インチはサブモニターとしてちょうど良いサイズで、作業がとても捗るようになりましたし、明さの調整などもMacBookのキーボードから簡単に行えるため、MacBookで作業するには確かに最適なモニターのひとつだと思いました。
ただ、このモニターは、MacBookのThunderbolt 3専用であるため、iPadやSwitchなどと接続ができませんでした。そのため、他のデバイスも接続できる汎用モニターが欲しくなったため、次のモニターも追加購入することにしました。
LG 31.5インチ エルゴノミクススタンド 4Kモニター 32UN880-B amazon.co.jp モニターアームの味をしめたのでアームタイプの32インチモニターを追加で買ったのですが、32インチはサブモニターだと大き過ぎるため、MacBookはクラムシェルモードにして32インチをメインモニターとして使うのが適していると感じました。
HHKBを持っているので、試しに32インチをメインに、24インチをサブモニターにして使うスタイルで作業してみたら、なかなか良い感じでしたが、16インチMacBook Proでの作業に慣れている身としては、作業環境をセットアップするのがやや面倒な気もしました。
ですが、HDMIやUSB-Cなどの入力インターフェイスが使えるので、SwitchやiPadなども映すことができて、便利に使っています。
Apple iPad Air スペースグレイ amazon.co.jp かなり初期のiPad miniを使っていたのですが、最新OSでの動作がだいぶもっさりしてきたため、第4世代iPad Airが発表されたタイミングで、Apple Pencilと一緒にiPad Airを購入してみました。
主に動画を見たり、本を読んだりする専用なのですが、iPadはAmazon Fireタブレットに比べて価格が高い分、動作もスムーズなので、特にストレスを感じることもなく使えました。
...
September 26, 2020
結婚の条件みたいな話は昔から色々と言われているが、個人的に考える最重要条件がある。それは「子供の有無」と「妻の仕事」に関する2軸だ。
この2軸の条件について、合意形成しないまま結婚してしまうと、長い結婚生活で常に後悔がつきまとい、いずれ必ず不幸が訪れると確信している。
なので、交際中の人も交際前の人も、結婚を前提に考えているのであれば、必ず結婚前に確認しておくべきだし、確認しないまま結婚してしまった人も、できるだけ早急に確認をして、条件が一致しなかった場合は、すぐに離婚してして新しい人生を歩みはじめることをオススメする。
条件1: 子供の有無 # まず最初の条件は「子供の有無」で、これは単純に子供を「欲しい」か「欲しくない」かの2択だ。
何となく「子供を欲しいと思うのが当たり前」と思っている人が多いと思うが、現実は意外とそうでもない。なので、勝手な思い込みは禁物だ。
条件2: 妻の仕事 # 「妻の仕事」は「仕事をする」か「仕事をしない」かの2択で、「仕事をしない」は一般的に専業主婦と呼ばれている。
これも、特に男性側が勝手に「子供が生まれたら仕事をやめるのが当然」と思い込んでいるケースがある。逆に経済的な理由で、本当は仕事をしたくないのに、仕事をさせられている人もいるだろう。
なお、本当は「旦那の仕事」という軸もあるのだが、現時点での日本社会において、その条件不一致により問題が発生するケースはほとんどないため今回は考慮しないこととする。可能であるならば、「旦那の仕事」についても条件に加えておくのが望ましい。
結婚条件の4パターン # 条件の話はここまでにして、次はパターンの話をしよう。まずは、このマトリクス図を見て欲しい。
「子供の有無」と「妻の仕事」の2軸で作られるパターンは次の4つになる。
パターンA: 専業主婦になって子供の面倒を見る オールドクラシックな日本的パターンで、おそらく男女ともに多くの人が考えている条件 パターンB: 保育園に預けながら共働きで子供を育てる 現代の標準的なパターンで、現実的に一番数が多そうな条件 パターンC: 専業主婦になって夫婦だけで暮す おそらくもっともマイナーなパターンで、自分のまわりでは見たことがない パターンD: 共働きで夫婦だけで暮す 最近増えてきたパターンで、自分のまわりにも増えてきている この4パターンを結婚条件として男女それぞれが選択すると、何通りの結果が生まれるだろうか。
1/4の条件一致、3/4の条件不一致 # 4つの条件を男女それぞれが選択する独立試行なので、16通りの結果が生まれる。
そして、16通りの中で男女の条件が一致するのは4通りしかない。つまり、12通りの条件不一致が存在することになる。
男女それぞれ条件がある以上、「AB」と「BA」は条件一致にはならない。だから、不一致の方が多くなるのである。ということは、数学的な確率で言えば、男女の条件が一致する確率は1/4となり、3/4は不一致となるので、圧倒的に不一致になる確率の方が高いということになる。
要するに、こんな単純な2択でも2つ合わさると16通りになり、互いの条件が一致する確率の方が低くなってしまうのだ。だから、勝手な推察や思い込みで相手の条件を決めつけてしまうと、思わぬ落とし穴が待っているかもしれないのだ。
期限と残りの人生 # 出産にも仕事にも期限がある。
人生100年時代で考えると、40代までが子供を作るかどうか判断できる期間だとしても、更に倍の人生が残されていることになる。仕事も30代までに復帰できなければ、現実的に仕事を辞める前と同じようなキャリアは難しいだろう。
つまり、判断を間違えたままタイムリミットを過ぎてしまうと、残り半分の人生を後悔し続けて生きることになってしまうのである。
子供を欲しいと思っていた人が、相手が子供を望んでいないという理由で諦める例をよく見るし、仕事についても同様に、本当は仕事がしたいのに専業主婦になった例もよく聞く。
色々悩んで気持ちの整理をして決めたのであれば、30代、40代は無理矢理にでも気持ちを納得させられるかもしれない。だが、60代、70代になったときも本当に後悔しないと言い切れるだろうか。
子供も仕事も、生きていく上で自分の人生にも等しい存在だ。その選択を間違って後悔しないなんて、僕はできないと思っている。本当の後悔は、その積怨の思いが積み上がって、もう取り返しがつかないと悟ったときに訪れるだろう。
後悔しないたったひとつの方法 # 後悔をしないための方法はただひとつだ。できるだけ早いタイミング（結婚後よりも結婚前、交際後よりも交際前）で、この結婚条件マトリクスからお互いが希望するパターンを選択するのだ。
パターンが同じであればひとまず問題はない。あとは具体的なライフプランに落とし込むだけだ。
ただし、もしパターンが異なる場合は、お互いがなぜその選択に至ったのかをプレゼンして、ポジティブな理由によるパターン変更が望めない場合は、秒で別れて次の道に進むしかない。
ネガティブな理由によるパターン変更は論外で、なぜならば、結果的に倍以上の人生を後悔し続けることになるためだ。
3年付き合おうが、5年付き合おうが、条件パターンが異なれば、その後の人生は後悔しかない。だから、サンクコストを気にせずに、さっさと損切りして次に進むのが正しい選択なのだ。
まとめ # 僕の場合は、最初にお互いにパターンを確認し、僕がB（子供を生む、仕事をする）、妻がD（子供を生まない、仕事をする）だったが、相談の結果Bで合意形成をして、現在までに子供2人を作り共働きしているが、本当に何も問題なく今日まで生活をしている。
妻も仕事をするので、子供は0歳から保育園に入って、保育園の送り迎えや家事などは、お互いが得意かつ負担にならない範囲で分担して行っているので、子供の世話や家事の負担などで揉めることも一切ない。
だが、もし合意形成がない状態で本当は望まないパターンの生活を送ることになってしまっていたとすれば、きっと、本当はこんなことしたいわけではなかったなどの不満が日常的に蓄積して、日々の喧嘩が発生したり、離別の道を選択をしていたかもしれない。
結局、人生は決断して全力で行動するしかないのだが、きちんと決めずに色々なものに流されてしまう人がいる。結局のところそれがすべての元凶なのだが、なんとなく相手もこう思っているはずだと勝手な解釈をして、確認せずに物事を進めて、後になって意見違いに気付くというパターンが多くの原因を占めるのではないだろうか。
結婚という重要な決断をそのように勝手な解釈で決めてしまわないためにも、ぜひ、この結婚条件マトリクスを活用して、納得のいく合意形成を結んで欲しいと願っている。
February 17, 2019
継続的な学習は、僕の中で近年のひとつの大きなテーマとなっています。といっても、どうすれば継続学習ができるのかという話ではなく、世の中には日々の学習を行わない人がいるけど、どうして学習をしないのか、というのがこのテーマの中心課題です。
今回は、そのテーマについて論じる前に、僕が日々実践している学習方法を紹介したいと思ったのでブログに書いておきます。
毎日学習するための方法 # 僕が実践している毎日学習するための方法はとても簡単で、具体的には次の通りです。
特定のリポジトリを毎日git pullして、追加されたコミットを見る 面白い変更があればシェアやメモする 見ての通り、とても簡単です。僕は毎日これを1日の作業開始前に行っています。
毎日リポジトリをチェックすることで得られるメリット # これを続けていることで得られるメリットは色々ありますが、僕が考える代表的なものは次の通りです。
そのプロジェクトについて詳しくなれる そのプロジェクトで使われている言語について詳しくなれる 一般的なコミットメッセージの書き方を知ることができる 一般的なコミットの粒度を知ることができる それでは具体的にそれぞれのメリットについて説明していきます。
なお、ここからは僕が現在ウォッチしているEmacsのリポジトリを題材に話をすすめていきます。
そのプロジェクトについて詳しくなれる # プロジェクトを毎日git pullすると、少しづつ変化を確認できます。大きめなプロジェクトの場合、リリースが行われると大量の変更が入るため、変更をすべて確認するのはとても大変ですが、毎日の変更であればそこまで労力はかかりません。
例えば、この記事を書いているときの最新のコミットは上図のように1行（3文字）だけです。これだけあれば、時間をかけずに読むことが可能です。
Emacsの場合、リリースは平均して1年以上の間隔が空くのですが、コミットはほぼ毎日行われています。そのため、リリース後にすべての変更を確認するのはほぼほぼ困難となりますが、毎日であれば、おおよそ漏らさずに確認が行えるため、普通の人よりもEmacsについて詳しくなれます。
これは、もしそのプロジェクトについての書籍を書くことになるような場合にとても有益です。
そのプロジェクトで使われている言語について詳しくなれる # コードリーディングは、スキルの向上にとても役立ちますが、すでにできあがったプロダクトのコードを一から読むのはとても大変です。ですが、毎日のコミットを読むだけであれば、そこまで時間をかけずに行うことが可能となります。
Emacsは、基本的にEmacs LispとCで書かれているプロジェクトです。そのため、毎日コミットを読めば、この2つの言語について少しづつ詳しくなれます。
僕自身はCは書くことがないので、ほぼコミットメッセージだけ読んで流していますが、Emacs Lispについてはコミットされたコードを見て、少しづつ他の人の書き方を学習しています。
お陰で、自分がEmacs Lispコードを書くときには、そこで得た知識を活用してコーディングできるようになります。
一般的なコミットメッセージの書き方を知ることができる # もし、コミットメッセージと関係のない変更が行われているコミットがあれば、変更を見たときに意味を考えてしまいますが、Emacsのリポジトリではそういったコミットは一切ありません。そのため、悩むことなくコミットを読むことが可能となっています。
逆に、コミットを読んでいて、変更の意味が理解できずに悩んでしまうことがあるとすれば、それはコミットメッセージかコミット粒度のどちかが悪い可能性がありますので、自分自身がコミットを行う際に、そのようなことがないように気をつけるポイントとして学習しておく必要があります。
一般的なコミットの粒度を知ることができる # コミットの粒度は、明確な答えがないため、なかなか学習が難しいスキルです。ですが、色々なプロジェクトのコミットを見ていると、一般的に正しいとされているコミットの粒度を知ることができます。
個人的にコミットを見つづけることであらためて最重要と感じたのは、コミットメッセージ以外の変更は行わないという、当たり前のことを当たり前に行っていく姿勢です。
例えば、上図のドキュメント変更のコミットは、どちらもminibufferに関するコミットですが、それぞれ追加と修正が分けれていて、コミットメッセージと変更が等しくなっています。
更に言えば、ドキュメントのタイポや単純な空白の削除であっても、Emacsのリポジトリではコードの変更と合わせたコミットは行っていません。タイポの修正はタイポ修正として、空白の削除は空白の削除として、コードの変更はコードの変更として、変更内容と一意のコミットメッセージでコミットされています。
そのため、コミットメッセージとコミットに乖離がなく、コミットを読む際に余計な意味を考えずに変更を確認することができます。
こういった適切な粒度でコミットを行うことは、当たり前と思えるかもしれませんが、会社などでは意外とできていなかったりするため、こういったプロジェクトで当たり前に行われていることを噛み締めることで、あらためて肝に命じておくことができます。
毎日コミットを読む方法 # 僕が毎日コミットを読むために利用しているツールは基本的にはTig だけです。git pullしてTigを起動（lをTigのエイリアスにしています）して、コミットにひとつづつ目を通していきます。
ターミナルに慣れていない人であれば、SourcetreeやGitHub Desktopなどのデスクトップクライアントでもまったく問題ありませんので、好きなツールを使うと良いしょう。
おわりに # 今回は僕が実践している毎日の学習方法を紹介してみました。本を読むなどの方法ももちろん効果的ですが、こういった方法でもプログラマは自主的に学習できます。
学校や本では学べない、より実践的なエッセンスを学習することができますので、もし、何か気になるプロジェクトがあればぜひ試してみると良いでしょう。
February 15, 2019
13年振りのインフルエンザになりました（過去のブログで確認しました）。おそらく人生で3度目のはずで、記憶の怪しい1回目が20歳以前、2回目が13年前、そして今回の3回です。
僕がインフルと無縁の生活を送っている13年の間に、インフルエンザ界では大きな変化がありました。
昔はインフルに特効薬がなかった # その中で最も大きい変化はやはり、特効薬的な薬が生まれたことでしょう。そう、登場時に色々と問題になった「タミフル」です。いまでは普通に使われていますよね。
もしかしたらミレニアム世代には「インフルエンザは特効薬なんてなくて、かかったら熱が下がるまで、ひたすら耐えるしかなかったんだよ。」と伝えたら、あきれられるのかもしれません。でも、13年前は実際にそうでしたし、医学の進歩が早いのか、時の流れが早いのかはさておき、色々と変ったものです。
そんなわけで、今回、いよいよ話題のタミフルを飲むときがやってきたのかと思って、ドキドキしていたのですが、処方されたのは「イナビル」という聞いたことのない薬でした。
新薬イナビルを体験 # タミフル以後、どうやら「リレンザ」というやつと「イナビル」という2種類の薬が増えていたそうで、一気に浦島気分です。
イナビルは口から吸い込む吸入タイプの薬で、1回使えば5日間くらい効果が持続するという便利なやつだそうです。使い方は、第一三共がオウンドメディアでイナビル吸入方法｜インフルエンザの情報ならインフル・ニュースというページやiPhoneアプリまで作って頑張っていますが、処方する際に医師から「薬局で飲んで帰ってね」と言われたので、特に困ることはありませんでした。
久しぶりのインフルの感想 # 僕の場合、熱が上がりきる前にインフルだと判明して薬を服用したので、僕の中のイメージでは、そのまま熱が出ず、5日外出を控えれば大丈夫くらいに思っていたのですが、残念ながらそんなことはなく、次の日から2日間は熱と頭痛で動けず、3日目でようやく動けるようになりました。
残念ながらまだまだ世の中甘くはないですね。
まとめ # というわけで、昔懐しい感じのインフルエンザになったときの記録をしただけのブログになります。
13年の間にはてなダイアリーはお亡くなりましたが、こちらは生き残っていると信じて、またお会いしましょう〜。
February 4, 2019
今年というか去年末に35歳になりまして、いわゆるプログラマ35歳定年説の歳になったのだということに、最近気づきました。
35歳になってまだ2ヶ月くらしか経っていないのですが、いわゆる35歳定年説について、どのように感じるかを記録しておきたいと思います。
ここからは実感値として以下の5項目について触れていきます。
学習能力 集中力 体力 速度 品質 学習能力は上がっている # 学習能力については上がっていると思います。最大の理由は次の2つの能力が20代に比べて向上しているからです。
知識量が増えた 英語の文章を読む速度が上がった この結果、検索能力は20代と比べようもないほどに上がっているかと思います。そのため、分からないことがあっても、回答を得るまでかなりスピーディーですし、新しいことを学ぶときにも、ポイントを絞って要領よく学ぶことができるようになりました。
これらの能力が向上した理由としては、2冊の本（Emacs実践入門とAtom実践入門）を書いたことが大きな要因だと思います。なので、技術書を何のために書くのかと聞かれれば「自身の成長のため」と答えるのも良いでしょう（お金持ちにはなれません）。
集中力は特に変わらず # 集中力については特に変っていない気がします。小中と9年くらい書道していたからか、わりと集中するのは得意なのかなと思っています。
集中力に関しては幼少のトレーニングと性格が関連しているのかなと思っています。
体力は徐々に衰えている # 体力は徐々に衰えを感じています。特に20代には特に感じなかった肩凝り（というか正確には首痛）が慢性的に火を噴いていて、月に最低でも2万円は治療代に費しています。
結局のところ、肩首の疲れから目が痛くなったり、頭痛がしたりすると仕事を続けるのが困難なので、その日はもう終了といった感じです。
また、執筆業的には1日に1万文字以上書くこともあるのですが、それが続くと腕が痛くなって、キーボードをタイプするのが困難になって、仕事ができなくなるということもあります。
これについては、音声入力とかに本格的に切り替えるなどして対策を講じれば何とかなるかもしれないので、そろそろ真剣に検討していきたいと考えています。
速度は下っている # 仕事をするスピードは20代の頃に比べて下がってきている気がします。しかし、これは次の品質とのトーレドオフのような気もしていて、作業スピード自体は下っていても、完成したものの品質は以前よりも上がっていると思われるので、総合的に見れば完成までのスピード自体は維持、あるいは向上しているような気がします。
プログラミングについては、いきなり書き出すよりも脳内での設計に時間を割いて、実際に書く時間は短くなっている気がします。そのため、場当たり的なスピードは下ったかもしれませんが、結果的に手直しするコストは下がっているかと思います。
品質は上がっている # 上記で述べた通り、スピードは低下したものの完成したものの品質は向上していると思われます。
特に日本語の文章では、校正時の手直しが減っているように思われますが、ここらへんについては担当編集の意見も聞いてみたいところです。
まとめ # 以上、35歳定年説について自分自身が現状仕事をしている上でやっていけているのかという部分を5つの項目から振り返ってみましたが、体調について気をつければひとまずあと5年くらいは特に問題なくやっていける気がしました。
もちろん、これまでの仕事や学習の積み重ねで今があるので、今後も成長し続けていかなければ、将来的にはかなり厳しくなるという自覚はあります。
なので、今後については健康第一にしつつ、これまで同様に学習を続けていこうと思いました。
ちなみに学習する方法については、WBD+DB PRESSに特集を書くのが個人的には良いと思います。強制的に学習できて、かつ、しばらくの間WEB+DB PRESSが貰えますのでオススメです。いまだとTypeScriptあたりの特集を提案すると良いでしょう。