日本の親露派 [日記]
twitter で、日本人が
「ウクライナがネオナチで、ウクライナのロシア語話者を保護するロシアは正義」
みたいなこと言っていて、この人なんでこんなになっちゃったんだろう？と思う。
ちょっと調べれば、ゼレンスキー大統領はユダヤ系でロシア語話者で、ロシアが言っている敵とは全く違うんだけど・・・
陰謀論者は、色々な分野にいるけど、親露派の人の気持ちが一番わからない。
「ウクライナがネオナチで、ウクライナのロシア語話者を保護するロシアは正義」
みたいなこと言っていて、この人なんでこんなになっちゃったんだろう？と思う。
ちょっと調べれば、ゼレンスキー大統領はユダヤ系でロシア語話者で、ロシアが言っている敵とは全く違うんだけど・・・
陰謀論者は、色々な分野にいるけど、親露派の人の気持ちが一番わからない。
YubiKey [日記]
PyPI にパッケージをアップロードしたら、
[PyPI] Your PyPI account will soon require 2FA
というメールが来た。
5/25 にアナウンスされ、2023年中には 2FA を有効にしないといけないとのこと
https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2fa/
以前から、いつかは使おうと思っていた YubiKey を購入して 2段階認証の設定をしてみた。
（以下、自分用メモ）
PyPI の YubiKey による 2FA 設定
----------------------------------------
- pypi.org に ID/Password でログイン
- アカウント設定
- 二要素認証（2FA) で Generate recovery codes 押下
- 表示されたリカバリーコード（8個）を保存して Continue
- リカバリーコードの入力を促されるので↑の1個を入力
- 成功したら↑で入力した以外の7個を保存しておく
- Add 2FA with security device (e.g. USB key) を押下
- 端末に名前をつけて「セキュリティ端末を設定」
- YubiKey を刺す
こんな感じで YubiKey による２段階認証を設定したあと
- ユーザーID/パスワード入力
- 端末で認証
でログインできる。
自分が買ったのは YubiKey 5C というやつなのだが、
https://www.amazon.co.jp/dp/B07HBCTYP1
YubiKey で認証するときに両側の金属部分を指で触れてやる必要があった。（最初気づかなかった）
pypi にアップロードするためには、同じく「アカウント設定」から APIトークンを生成して
[pypi]
username = __token__
password = pypi-XXXXXXXX
と書いておけば twine でアップロードできる
Google アカウントで YubiKey 使う
------------------------------------
Class Method さんの記事が参考になった
https://dev.classmethod.jp/articles/set-up-fido2-enabled-security-key-for-google-account/
・・・と言ってもセキュリティ → 2段階認証→セキュリティキー→セキュリティキーの登録
と、普通に進めていけばよかった
Github で YubiKey を使う
------------------------------------
自分は、すでに SMS で2段階認証になっているので、
- Settings -> Access の Password and authentication
- Two-factor methods の Security keys の Edit→ Register new security key
これで、 Two-factor methods の Preferred 2FA method が Security keys になっていて Yubikey による認証が優先される
[PyPI] Your PyPI account will soon require 2FA
というメールが来た。
5/25 にアナウンスされ、2023年中には 2FA を有効にしないといけないとのこと
https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2fa/
以前から、いつかは使おうと思っていた YubiKey を購入して 2段階認証の設定をしてみた。
（以下、自分用メモ）
PyPI の YubiKey による 2FA 設定
----------------------------------------
- pypi.org に ID/Password でログイン
- アカウント設定
- 二要素認証（2FA) で Generate recovery codes 押下
- 表示されたリカバリーコード（8個）を保存して Continue
- リカバリーコードの入力を促されるので↑の1個を入力
- 成功したら↑で入力した以外の7個を保存しておく
- Add 2FA with security device (e.g. USB key) を押下
- 端末に名前をつけて「セキュリティ端末を設定」
- YubiKey を刺す
こんな感じで YubiKey による２段階認証を設定したあと
- ユーザーID/パスワード入力
- 端末で認証
でログインできる。
自分が買ったのは YubiKey 5C というやつなのだが、
https://www.amazon.co.jp/dp/B07HBCTYP1
YubiKey で認証するときに両側の金属部分を指で触れてやる必要があった。（最初気づかなかった）
pypi にアップロードするためには、同じく「アカウント設定」から APIトークンを生成して
[pypi]
username = __token__
password = pypi-XXXXXXXX
と書いておけば twine でアップロードできる
Google アカウントで YubiKey 使う
------------------------------------
Class Method さんの記事が参考になった
https://dev.classmethod.jp/articles/set-up-fido2-enabled-security-key-for-google-account/
・・・と言ってもセキュリティ → 2段階認証→セキュリティキー→セキュリティキーの登録
と、普通に進めていけばよかった
Github で YubiKey を使う
------------------------------------
自分は、すでに SMS で2段階認証になっているので、
- Settings -> Access の Password and authentication
- Two-factor methods の Security keys の Edit→ Register new security key
これで、 Two-factor methods の Preferred 2FA method が Security keys になっていて Yubikey による認証が優先される
ファミレスの自動化のさらなる進化 [日記]
昨日、久しぶりにファミレス行った。
待合の発券から、席番号の発券（この紙に精算の時のバーコードが書いてある）から座席の案内、注文までタブレットを使い、配膳はロボットが行い、ドリンクは自分で取りに行くので、お店の人に接するのは、お金を払う時だけになった。
配膳ロボットは一台しかないので、人間が料理を持ってくることはあるが、ほとんどをロボットが賄っていた。お店の人の配膳ロボットの使いこなしが向上していて、最初に見た頃は
「これ、面白いけど、役になっているの？」
と思っていたが、配膳ロボットでかなりの省力化ができているように思えた。
この頃は、配膳ロボットはなかったようだが、
https://nakagami.blog.ss-blog.jp/2022-11-23
この頃から比べて、発券や注文のソフトウェアの動作もわかりやすくキビキビ動くようになっているように思う。
タブレットの性能が上がっているのかもしれない。そういえば、最初の頃はバッテリー切れになっていたタブレットが多かったように思う。
注文がスムーズにいったのは自分たちが使い方を理解してきたからかもしれない。
お店の人が接客する場面が少なくなっているので、お店の人のストレスも減っていると思う。
今後は最後にお金を払うところが省力化され、例えば、お客さんのスマートフォンから
モバイルオーダーのような形で支払いするようになるかどうか・・・
- 労働力不足
- 治安の良さ
- 自動販売機の普及
- チップがない
などの要因が日本にはあって欧米では難しそう。まだファミレスでは外国人をあまり見かけないが、観光地かするのではなかろうか。
（中国でもスマホで注文するのは当たり前になってきているらしいが、それよりも省力化が進んでいるように思う）
待合の発券から、席番号の発券（この紙に精算の時のバーコードが書いてある）から座席の案内、注文までタブレットを使い、配膳はロボットが行い、ドリンクは自分で取りに行くので、お店の人に接するのは、お金を払う時だけになった。
配膳ロボットは一台しかないので、人間が料理を持ってくることはあるが、ほとんどをロボットが賄っていた。お店の人の配膳ロボットの使いこなしが向上していて、最初に見た頃は
「これ、面白いけど、役になっているの？」
と思っていたが、配膳ロボットでかなりの省力化ができているように思えた。
この頃は、配膳ロボットはなかったようだが、
https://nakagami.blog.ss-blog.jp/2022-11-23
この頃から比べて、発券や注文のソフトウェアの動作もわかりやすくキビキビ動くようになっているように思う。
タブレットの性能が上がっているのかもしれない。そういえば、最初の頃はバッテリー切れになっていたタブレットが多かったように思う。
注文がスムーズにいったのは自分たちが使い方を理解してきたからかもしれない。
お店の人が接客する場面が少なくなっているので、お店の人のストレスも減っていると思う。
今後は最後にお金を払うところが省力化され、例えば、お客さんのスマートフォンから
モバイルオーダーのような形で支払いするようになるかどうか・・・
- 労働力不足
- 治安の良さ
- 自動販売機の普及
- チップがない
などの要因が日本にはあって欧米では難しそう。まだファミレスでは外国人をあまり見かけないが、観光地かするのではなかろうか。
（中国でもスマホで注文するのは当たり前になってきているらしいが、それよりも省力化が進んでいるように思う）
日本への帰化 [日記]
YouTube は、コンテンツが suggest され、見るものが偏っていくので気をつけないと・・・と思っているのだが、
最近は、（自分には全く必要のないものだけど）日本に住む外国人のビザ発給や帰化の書類作成をしている行政書士の動画を見てしまっている。
年々条件が厳しくなるものの、帰化は大雑把に
- 期間3年のビザが発給されている
- ５年以上正当なビザで日本に滞在して、そのうち３年以上は就労ビザ
- 安定した収入で生計が立てられている
- 小学校３年程度の日本語ができる
くらいで（悪いことしてないとか、思想的に問題あるとかはダメだけど）帰化するのって僕が思っていたより簡単らしい。
年収300万くらいあれば良くて、持っている資産は関係ないとのこと。
大金持ちなら帰化できるみたいなのではなくて好感が持てる。
日本は亡命は難しいことで有名なので、外国人が帰化するのはほぼ不可能と思っていたが、そうでもないらしい。
よく、日本代表のスポーツ選手で帰化している人がいて
「法務省の忖度で素早く帰化できたんだな」
と思っていたが、そういう人たちのインタビューを見ると日本語は要件を満たしているし、５年以上は日本でプレイしてるっぽいし、普通に帰化できる人たちなんだな。
最近は、（自分には全く必要のないものだけど）日本に住む外国人のビザ発給や帰化の書類作成をしている行政書士の動画を見てしまっている。
年々条件が厳しくなるものの、帰化は大雑把に
- 期間3年のビザが発給されている
- ５年以上正当なビザで日本に滞在して、そのうち３年以上は就労ビザ
- 安定した収入で生計が立てられている
- 小学校３年程度の日本語ができる
くらいで（悪いことしてないとか、思想的に問題あるとかはダメだけど）帰化するのって僕が思っていたより簡単らしい。
年収300万くらいあれば良くて、持っている資産は関係ないとのこと。
大金持ちなら帰化できるみたいなのではなくて好感が持てる。
日本は亡命は難しいことで有名なので、外国人が帰化するのはほぼ不可能と思っていたが、そうでもないらしい。
よく、日本代表のスポーツ選手で帰化している人がいて
「法務省の忖度で素早く帰化できたんだな」
と思っていたが、そういう人たちのインタビューを見ると日本語は要件を満たしているし、５年以上は日本でプレイしてるっぽいし、普通に帰化できる人たちなんだな。
自社サービスで飯食っている人すごい [日記]
色々見聞きしていると、自社が運用するサービスで飯を食うのってめちゃくちゃ難しい。
プレゼンでうまいこといって投資を募って、その金がある間は
「開発してまーす」
って言ってプログラム書いて（一回でもリリースできればいいほうで）資金的に行き詰まって、 Buy Out して
「おめでとう！」
って言われてるけど、実際には会社にいるエンジニアを買収しただけで、サービスは終了するってことのなんと多いことか。
受託開発という堅実な路線があるだけに、優秀なのにあえて自社サービスにチャレンジする人たちすごいって思う。
一時期調子いいな、ってところまできても、徐々にうまくいかなくなっていくこともある。
収支がトントンまでいってたら相当優秀なんだと思う。
僕は、調子いいサービス、調子悪くなっちゃうサービスのどこが良くてどこが悪いのかさっぱりわからないので、こんなセンスない人間は自社サービスに参画しちゃダメだなっと思っている。
でも夢があって羨ましいなとは思う。
受託開発では、同じ人数で売り上げ10倍は無理でも、自社サービスだとその可能性あるんで。
自社サービスのある会社で、受託開発で売り上げを支えるって仕事が一番自分にあってるかな、と思う今日この頃
プレゼンでうまいこといって投資を募って、その金がある間は
「開発してまーす」
って言ってプログラム書いて（一回でもリリースできればいいほうで）資金的に行き詰まって、 Buy Out して
「おめでとう！」
って言われてるけど、実際には会社にいるエンジニアを買収しただけで、サービスは終了するってことのなんと多いことか。
受託開発という堅実な路線があるだけに、優秀なのにあえて自社サービスにチャレンジする人たちすごいって思う。
一時期調子いいな、ってところまできても、徐々にうまくいかなくなっていくこともある。
収支がトントンまでいってたら相当優秀なんだと思う。
僕は、調子いいサービス、調子悪くなっちゃうサービスのどこが良くてどこが悪いのかさっぱりわからないので、こんなセンスない人間は自社サービスに参画しちゃダメだなっと思っている。
でも夢があって羨ましいなとは思う。
受託開発では、同じ人数で売り上げ10倍は無理でも、自社サービスだとその可能性あるんで。
自社サービスのある会社で、受託開発で売り上げを支えるって仕事が一番自分にあってるかな、と思う今日この頃
自分の無能さに耐える [日記]
１つ前のエントリの続き。
N さんも T さんも、勤続年数は長くて、昔はプログラムを書いていたこともあるようだが、今は SE の名のもとに、なんだか色々と雑用をやっているようだ。
ずっとプログラムを書くというキャリアパスが社内にはないので、今は（僕が会った15年くらい前にも）もう書いていない。
その T さんが、（僕が、いまだにプログラムを書いているというので）
「たまに、遊びでプログラムを書いてみるんですけど、全然書けなくて、若い人と一緒に仕事したら自分の無能さに悔しくて耐えられないと思うんですよね」
と言っていた。
「ずっと書き続けていればなんとかなりますよ」
とは思うが、確かに自分も、50歳過ぎると、若者の知識量には叶わないし、新たに何かを学ぼうと本を読んでも、理解力も集中力も落ちていると実感するし、プログラムを読むのも書くのも衰えを感じる。
使うツールが変わったので、簡単に比較はできないが 30代の自分には敵わないんだろうなぁ、と思うと寂しいものはある。
今は、
「nakagami さんが、あの年までプログラム書いているみたいなので、自分も 60歳くらいまでできるかな」
と思ってもらえるように（将来、あの程度くらいはできるなと思ってもらえる指標として）頑張っている。
N さんも T さんも、勤続年数は長くて、昔はプログラムを書いていたこともあるようだが、今は SE の名のもとに、なんだか色々と雑用をやっているようだ。
ずっとプログラムを書くというキャリアパスが社内にはないので、今は（僕が会った15年くらい前にも）もう書いていない。
その T さんが、（僕が、いまだにプログラムを書いているというので）
「たまに、遊びでプログラムを書いてみるんですけど、全然書けなくて、若い人と一緒に仕事したら自分の無能さに悔しくて耐えられないと思うんですよね」
と言っていた。
「ずっと書き続けていればなんとかなりますよ」
とは思うが、確かに自分も、50歳過ぎると、若者の知識量には叶わないし、新たに何かを学ぼうと本を読んでも、理解力も集中力も落ちていると実感するし、プログラムを読むのも書くのも衰えを感じる。
使うツールが変わったので、簡単に比較はできないが 30代の自分には敵わないんだろうなぁ、と思うと寂しいものはある。
今は、
「nakagami さんが、あの年までプログラム書いているみたいなので、自分も 60歳くらいまでできるかな」
と思ってもらえるように（将来、あの程度くらいはできるなと思ってもらえる指標として）頑張っている。
楽しくなければ仕事が続かない [日記]
Facebook の誕生におめでとうのやり取りをきっかけに、
前々職の時に知り合った２人と竹橋で飲み会をした。
Nさん: 60歳。定年のはずなのに、まだいていいよと言われ仕事を続けている
Tさん: 54歳。システム系の大企業勤務
３人とも平社員。だからこそ急な集まりに参加できた。
最後に会った時には、僕は前職の話をしていたらしい。
そうすると、前回会ったのは 10年以上前ということになる。まじか。
N さんは、大炎上中のシステム開発案件のテコ入れ・・・といっても、本人はコード書かないのでプロジェクト回すという点で何かできることないか？みたいな感じで参加しているらしいが、「どうしようもない」状態らしい。
Tさんは、自社の受託している運用案件で、全然上手く回っていないところのテコ入れみたいな感じ。
顧客満足度 100% を闇雲に目指すもんだから、今30% のところまずは 60% を目指しましょう、というのも受け入れられず、そもそも今のメンバーとか体制がスキルが足りてないので、「どうしようもない」らしい。
どちらも、硬直的な仕事の進め方で、工夫のしようがないのに今のままでは改善の余地はなさそうで、Tさんは、怒られるだけの仕事と言っていた。
一言で言えば、どちらも仕事がつまらない。
若い頃は、生活のために仕事しなきゃいけない、つまらないことも仕事なら我慢しなきゃいけない・・・と思っていたけど、年をとってみると仕事の中に多少なりとも楽しみとかやりがいを見つけないと続かないということで３人の意見は一致した。
Tさんは、55歳になると早期退職で退職金が上積みされるので、早期退職しようかと真剣に考えているようだ。
「近所のパソコン教室で、お年寄り相手にパソコン教えるのとか、時給低そうだけど、なんか楽しそうじゃないですか」
とのこと。
次に会うときに T さん、会社辞めてるだろうか？
前々職の時に知り合った２人と竹橋で飲み会をした。
Nさん: 60歳。定年のはずなのに、まだいていいよと言われ仕事を続けている
Tさん: 54歳。システム系の大企業勤務
３人とも平社員。だからこそ急な集まりに参加できた。
最後に会った時には、僕は前職の話をしていたらしい。
そうすると、前回会ったのは 10年以上前ということになる。まじか。
N さんは、大炎上中のシステム開発案件のテコ入れ・・・といっても、本人はコード書かないのでプロジェクト回すという点で何かできることないか？みたいな感じで参加しているらしいが、「どうしようもない」状態らしい。
Tさんは、自社の受託している運用案件で、全然上手く回っていないところのテコ入れみたいな感じ。
顧客満足度 100% を闇雲に目指すもんだから、今30% のところまずは 60% を目指しましょう、というのも受け入れられず、そもそも今のメンバーとか体制がスキルが足りてないので、「どうしようもない」らしい。
どちらも、硬直的な仕事の進め方で、工夫のしようがないのに今のままでは改善の余地はなさそうで、Tさんは、怒られるだけの仕事と言っていた。
一言で言えば、どちらも仕事がつまらない。
若い頃は、生活のために仕事しなきゃいけない、つまらないことも仕事なら我慢しなきゃいけない・・・と思っていたけど、年をとってみると仕事の中に多少なりとも楽しみとかやりがいを見つけないと続かないということで３人の意見は一致した。
Tさんは、55歳になると早期退職で退職金が上積みされるので、早期退職しようかと真剣に考えているようだ。
「近所のパソコン教室で、お年寄り相手にパソコン教えるのとか、時給低そうだけど、なんか楽しそうじゃないですか」
とのこと。
次に会うときに T さん、会社辞めてるだろうか？
僕と松村邦洋さんの56回目の誕生日 [日記]
ここ10 年くらい、「だいたい50歳」と自分に言い聞かせていたが、今日から「だいたい60歳」と言わなくてはいけない。
自分のことを「おじさん」じゃなくて「おじいさん」と呼ばなくてはいけない。
そんなことを言い聞かせる誕生日。
自分のことを「おじさん」じゃなくて「おじいさん」と呼ばなくてはいけない。
そんなことを言い聞かせる誕生日。
プログラマーのキャリアパス [日記]
僕が就職した会社で、
「nakagami 君も、早くプログラマーから SE になって」
と言われていた。
そのうち課長になって部長になって・・・
少なくとも、その会社での課長や部長は管理職であると同時に仕事を取ってくる営業だった。
プログラマーは35歳で定年と言われていたし、そのキャリアパスは、あの頃には正解だと思われていた。
あの会社でずっと我慢していたら、今頃、中小企業の部長になれていたとしても、他の会社では通用しないし、残りの10年頑張ってしがみついていくしかない人間になっていたと思う。
今のご時世、中途半端な中間管理職は必要ないので、実際にはしがみついても今日まで勤め続けることはできなくて、
できない課長になったあたりで、会社にいらないと言われているか、自分でやめていたかもしれない。
驚いたことに、自分は 55歳になっても、まだプログラマーをしている。
色々使うツールは変わったが、本質的には 30歳の頃からやっていることはあまり変わらないように思う。
ここにきてプログラマーが圧倒的に不足していて、凡庸で老いぼれた自分でも、あと10年くらいはプログラマーとしてやっていけるんじゃないかと思えてきた。
人間、40〜50年くらい働かないといけない時代だが、30年経ったら昔考えていたキャリアパスは間違いだったってことになるもんだなぁ。
今の若い人がずっとプログラマーを続けるのが正しいかどうかはわからない。好ましいキャリアパスは、時代によって変わっていくだろう。
自分の人生に必要なキャリアパスは会社の偉い人は責任を持ってはくれないし、結局、自分にとって一番良い選択を自分でしていくしかないなあ、と思う今日この頃。
「nakagami 君も、早くプログラマーから SE になって」
と言われていた。
そのうち課長になって部長になって・・・
少なくとも、その会社での課長や部長は管理職であると同時に仕事を取ってくる営業だった。
プログラマーは35歳で定年と言われていたし、そのキャリアパスは、あの頃には正解だと思われていた。
あの会社でずっと我慢していたら、今頃、中小企業の部長になれていたとしても、他の会社では通用しないし、残りの10年頑張ってしがみついていくしかない人間になっていたと思う。
今のご時世、中途半端な中間管理職は必要ないので、実際にはしがみついても今日まで勤め続けることはできなくて、
できない課長になったあたりで、会社にいらないと言われているか、自分でやめていたかもしれない。
驚いたことに、自分は 55歳になっても、まだプログラマーをしている。
色々使うツールは変わったが、本質的には 30歳の頃からやっていることはあまり変わらないように思う。
ここにきてプログラマーが圧倒的に不足していて、凡庸で老いぼれた自分でも、あと10年くらいはプログラマーとしてやっていけるんじゃないかと思えてきた。
人間、40〜50年くらい働かないといけない時代だが、30年経ったら昔考えていたキャリアパスは間違いだったってことになるもんだなぁ。
今の若い人がずっとプログラマーを続けるのが正しいかどうかはわからない。好ましいキャリアパスは、時代によって変わっていくだろう。
自分の人生に必要なキャリアパスは会社の偉い人は責任を持ってはくれないし、結局、自分にとって一番良い選択を自分でしていくしかないなあ、と思う今日この頃。
20年使える業務システム [日記]
最近 Oracle8 + Java でできている業務システムをバージョンアップして新サーバーに移行したという話を聞いて
https://nakagami.blog.ss-blog.jp/2023-05-06
とりあえず 20年、その後 30年、40年と使っていく業務システムを作りたいとなったら何を使えばいいんだろうか？
と、たまーに考える
- 機能改修は継続的に行われる
- 業務アプリなので、UI 的にシュッとしたかっこよさは必要ない
- OS, RDBMS, プログラミング言語とライブラリは LTS サポートがなくなる前にバージョンアップする
と考えた時に、 1番下の（業務的にはあまり必要とされてない）バージョンアップの負担がどれだけ減らせるか？
ということと、使っている要素が廃れてしまって適切にセキュリティパッチが出なくなったり、扱える人が減ったり、しないようにしたい。
・・・つまり、 Visutal Basic 6.0 や Perl で書いて20年後の人に迷惑かけないようにしたい、というあたりが、長く使うためのポイントかなぁ。
- SPA は業務アプリに必要ない一方、フロントのライブラリーやツールを更新するのは大変。サポートされる期間も非常に短い
- Web フレームワークは３年くらいで LTS でなくなる一方変化が激しいので、バージョン上げたてそのままってことが少ない
というあたりが 20年〜40年って考えた時にネックになるかなぁ
- RDBMS は PostgreSQL か MySQL (今の時点だと PostgreSQL を選ぶ方が安心かなぁ）
- プログラミング言語は Go
- 極力外部パッケージは使わず、 Web フレームワークの薄ーいやつ (ginとか) と、データーベースドライバーだけ使う
くらいだと 100年くらい使えるかなぁ
https://nakagami.blog.ss-blog.jp/2023-05-06
とりあえず 20年、その後 30年、40年と使っていく業務システムを作りたいとなったら何を使えばいいんだろうか？
と、たまーに考える
- 機能改修は継続的に行われる
- 業務アプリなので、UI 的にシュッとしたかっこよさは必要ない
- OS, RDBMS, プログラミング言語とライブラリは LTS サポートがなくなる前にバージョンアップする
と考えた時に、 1番下の（業務的にはあまり必要とされてない）バージョンアップの負担がどれだけ減らせるか？
ということと、使っている要素が廃れてしまって適切にセキュリティパッチが出なくなったり、扱える人が減ったり、しないようにしたい。
・・・つまり、 Visutal Basic 6.0 や Perl で書いて20年後の人に迷惑かけないようにしたい、というあたりが、長く使うためのポイントかなぁ。
- SPA は業務アプリに必要ない一方、フロントのライブラリーやツールを更新するのは大変。サポートされる期間も非常に短い
- Web フレームワークは３年くらいで LTS でなくなる一方変化が激しいので、バージョン上げたてそのままってことが少ない
というあたりが 20年〜40年って考えた時にネックになるかなぁ
- RDBMS は PostgreSQL か MySQL (今の時点だと PostgreSQL を選ぶ方が安心かなぁ）
- プログラミング言語は Go
- 極力外部パッケージは使わず、 Web フレームワークの薄ーいやつ (ginとか) と、データーベースドライバーだけ使う
くらいだと 100年くらい使えるかなぁ
