赤血球や白血球、血小板になる造血幹細胞を再生医療で移植した際、幹細胞は血液の流れの刺激がきっかけとなって免疫細胞からの攻撃を回避し、長期にわたる再生能力を維持することを名古屋大学などのグループが明らかにした。
移植した造血幹細胞の免疫回避と再生能力維持、血液の流れがきっかけに 名大など | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
薬剤など化学物質を使わなくても血管へ物理的刺激を与えると幹細胞や周りの免疫を制御することを示しており、再生医療への新たなアプローチになる可能性がある。
移植した造血幹細胞の免疫回避と再生能力維持、血液の流れがきっかけに 名大など | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
⇧ amazing...
あらゆる領域で資源は不足してますし、
医薬品供給不測の原因
供給不足の原因については、2019年12月に欧州の製薬企業団体が供給不足の根本的要因 （root causes）について、以下の4点を挙げている 4) 。
ジェネリック医薬品を含む特許切れ製品については、価格引き下げを背景に供給不足のリスクや頻度が高いが、供給不足は必ずしもジェネリック医薬品だけの問題ではない。
- ①規制：各国規制当局の薬事承認や保険収載の判断による供給不足。
- ②製造と品質：製造キャパシティ、自然災害、GMPに関連する製造上の問題、需要急増、原薬等のサプライチェーンに起因する問題など。
- ③経済的要因：競争環境、市場規模、価格引き下げなどによる商業的撤退など。
- ④製品サプライチェーン：非効率な物流。
これらの要因に加え、時間的要素（短期、長期の一時的な中断か、永久的な撤退か）ならびに地理的要素（局地的、全国的、グローバル）についても分けて考える必要がある。
移植した造血幹細胞の免疫回避と再生能力維持、血液の流れがきっかけに 名大など | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
⇧「薬品」の不足もしてますし、「薬剤」や「化学物質」を利用しなくても良くなるようにできれば、インパクトは大きいですな。
ソフトウェアエンジニアにとって依然として環境構築は悩ましい...
ソフトウェアエンジニアにとってストレスとなる作業の代名詞とも言っても過言ではない「環境構築」について、仮に構築手順があったとして手順通りに実施して動くことは100%の確立で無いので（知見のあるインフラエンジニアの方がおられる現場であれば手順などもメンテナンスしてくれていて、問題なく環境構築が実現できるかもですが、そのような恵まれた現場はほぼ無いのが世の常...）、有識者に確認したりすると『自分の環境では動いたけど？』って言葉を聞くことあるあるでは無いでしょうか？
いや、実際、手順通りに実施して動かないから困っているわけなんだが、『自分の環境では動いたけど？』だけ言われても、
- 手順通りに実施していないんじゃない？
ってことが言外に含まれているってことを「忖度」しないといけないんですかね？
で、確認すると十中八九が手順がメンテナンスされていないことが原因、所謂、手順の不備が問題だったりするのだが、何故かこちらの不手際であるかのように見なされる理不尽さに耐える必要がありますと...
まぁ、ソフトウェアエンジニアを続けていると、少なからず、こういった不条理な現場に遭遇することはままあることと思われますと。
で、極力、「属人化」となる部分、所謂「秘伝のタレ」化を回避しようという思想で生まれたのかは分かりませんが、「IaC（Infrastructure as Code）」という考え方がありますと。
Infrastructure as Code（IaC） はコンピューティング・インフラ（プロセス、ベアメタルサーバー、仮想サーバーなど）の構成管理・機械処理可能な定義ファイルの設定・プロビジョニングを自動化するプロセスである。定義されたファイルはバージョン管理システムで保持することもある。
従来、手動のプロセスではなくスクリプトや宣言的な定義によって行われていたが、IaCの開発は今では、宣言的なアプローチに焦点が当てられている。
⇧ とあるように、従来のアプローチでは、「シェル芸」や「黒魔術」といった究極の「属人化」に陥りやすいこともあり、必要な情報を事前に全て「定義」してしまうというアプローチですと。
「IaC（Infrastructure as Code）」的なアプローチの嬉しいところは、
- 冪等性が高くなる
- 各々で解釈の揺れが少なくなる
という点なのだが、逆に、ツールによって独自の記法などが採用されていると、
- 職人芸になり得るリスクは依然として残る
→ 各々で解釈の揺れが大きくなる - 痒い所に手が届かない
→ ツールで未サポートのことを実現しようとすると複雑になりがち
という問題が出てきますと。
結局のところ、「銀の弾丸」は存在しないので、
トレードオフ（英: trade-off）とは、何かを得ると、別の何かを失う、相容れない関係のことである。平たく言うと一得一失（いっとくいっしつ）である。対義語は両立性（コンパチビリティ、英: compatibility）。トレードオフのある状況では具体的な選択肢の長所と短所をすべて考慮した上で決定を行うことが求められる。
⇧ 上記を加味して、『能々（よくよく）吟味あるべき也』と言ったところでしょうか。
とは言え、「IaC（Infrastructure as Code）」的なアプローチであれば、『可読性を完全に無視して、且つ、ワンライナーで実現しました』的な「イレギュラー」な要素の発生を抑制することができそうな気はする。
ツールの仕様上、力業でしか実現できない部分も出てくるとは思いますが...
VagrantのプロバイダーでWSL 2は未対応。WSL 2では環境構築の属人化から逃れられないか...
で、ローカル環境においての「環境構築」の1つの妥協案と言いうのが、「HashiCorp」が提供している「OSS（Open Source Software）」の1つ「Vagrant」を利用するという方法。
なのだが、
Vagrant（ベイグラント）は、仮想機械を構築するためのソフトウェアである。構成情報を記述した設定ファイル (Vagrantfile) を元に、仮想環境の構築から設定までを自動的に行うことができる。最新版v3はGoで開発されている。ソースアベイラブルの Business Source License で配布されている。
サポート
当初はVirtualBoxをターゲットとしていたが、1.1以降のバージョンではVMwareなどの他の仮想化ソフトウェアやAmazon EC2のようなサーバー環境も対象とできるようになった。Vagrant自身はRubyで作成されているが、PHPやPython、Java、C#、JavaScriptといった、他のプログラミング言語の開発においても用いることができる
⇧ とあり、元々「VirtualBox」を対象としていたこともあり、
⇧「Vagrant」は「プロバイダー」として「WSL（Windows Subsystem for Linux）」をサポートしていませんと。
2021年に上がっていた話らしいのだが、続報が無いところを見ると、2025年になっても未サポートであるということになりそう...
で、「Vagrant」の公式のドキュメントを見た感じでは、
⇧ 明示的に「WSL（Windows Subsystem for Linux）」がリストに無いことから、「Vagrant」の「プロバイダー」として「WSL（Windows Subsystem for Linux）」は依然としてサポート対象外ということになりそう。
ちなみに、
⇧「WSL（Windows Subsystem for Linux）」内で「Vagrant」を利用することはできるらしいのだが、「じゃない感」が半端ない...
つまり、「WSL（Windows Subsystem for Linux）」を使って環境構築する場合は、「冪等性」は担保されないことを意識しておくことが必要と言うことですかね...
と言うことは、「再現性」が保証されないので、「幻の逸品」的な「環境」が語り継がれることもありますと。
ソフトウェア開発は、未だに改善されない課題が多い...
エンジニアの生産性云々の前に、「環境構築」の問題を何とかして欲しいところなんだが、一番後回しにされがちなんよね...
「環境構築」がコマンド1つ実行で解決できれば、開発に注力できるようになるんだが...
「環境構築」の「冪等性」が担保されない状況だと、気軽に「概念実証（PoC：Proof of Concept）」をできないものね...
つまり、『自分の環境では動いたけど？』問題が解消できない...
解決されることの無い、永遠のテーマということになるんかね...
猫も杓子も「AI」が日進月歩で性能改善されているという話で持ち切りなのだが、エンジニアリングの開発環境を整備する領域は改善されないなぁ...
俗に言うところの「オレオレ環境」が今日も今日とて乱立しているのであろうな...
個人開発なら「オレオレ環境」でも何の問題もないのだろうけど...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
