ヒトの人工多能性幹細胞（iPS細胞）から作製した腎臓のもとになる細胞を慢性腎臓病（CKD）のマウスに移植したところ腎機能の低下が抑えられた、と京都大学などの研究グループが発表した。
慢性腎臓病をiPS技術で治療 京大など、マウスで効果確認 数年以内に臨床試験目指す | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
CKDの患者は国内に約2000万人いると推計され、病状が進行して末期の腎不全になると人工透析や腎移植が必要になる。研究グループは安全性を確認した上で、数年以内に臨床試験の開始を目指すとしている。
慢性腎臓病をiPS技術で治療 京大など、マウスで効果確認 数年以内に臨床試験目指す | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
iPS細胞を使う再生医療は現在、さまざまな医療分野で実用化に向けた研究が進んでいる。京都大学iPS細胞研究所名誉所長・教授の山中伸弥氏が2007年、ヒトのiPS細胞の生成技術を開発して一躍注目された。さまざまな細胞に変化できるのが特長で、病気やけがで機能が失われた組織や臓器の再生が主な狙いだ。
慢性腎臓病をiPS技術で治療 京大など、マウスで効果確認 数年以内に臨床試験目指す | Science Portal - 科学技術の最新情報サイト「サイエンスポータル」
⇧「人工透析」が不要になる世界線が来る可能性があるかもしれないのは、インパクト大きいですね。
「それは2012年にノーベル賞を受賞した山中伸弥氏の功績です。iPS細胞作製の成功は歴史上最も画期的な出来事の1つです」
「2099年に寿命という概念がなくなる」若返りの研究がここ10年で急速に進んでいる理由「山中伸弥氏のノーベル賞受賞がきっかけで…」 | 文春オンライン
老化の研究が急速に進んだのはここ10年である。山中氏の研究成果が嚆矢となって、この分野を研究対象にした人は世界中にいる。
「2099年に寿命という概念がなくなる」若返りの研究がここ10年で急速に進んでいる理由「山中伸弥氏のノーベル賞受賞がきっかけで…」 | 文春オンライン
血液の幹細胞は生まれたときは十万個ぐらいあると言われています。歳を取るとともに減っていって、100歳ぐらいの人で血液の幹細胞が何個残っているかを調べたところ、一個しかなかったという研究報告があります。幹細胞というのはすごいですね。僕たちもびっくりしたんですけれど、その一個もなくなると終わりです。
寿命の限界は120歳!?...老化の研究から判明した「不老不死」実現の「残酷すぎる」真実（山中 伸弥,谷川 浩司） | ＋αオンライン | 講談社
「不老不死」はなぜ実現不可能なのか
山中 ええ。100歳で残り一個だから、120歳になったら間違いなくゼロになってしまいます。仮に全身にがんができず、事故にも遭わず、タバコも吸わず、体に悪い物を食べず……といくら気をつけても、おそらく120歳ぐらいが寿命の限界ということです。
寿命の限界は120歳!?...老化の研究から判明した「不老不死」実現の「残酷すぎる」真実（山中 伸弥,谷川 浩司） - 2ページ目 | ＋αオンライン | 講談社
ただ、血液の幹細胞の場合は、外から幹細胞を移植することができます。それをすると、120歳は乗り越えられるかもしれません。けれども脳はそういうわけにはいきません。脳は先ほどもお話しした通り、移植してしまうと、もはや本人かどうかわからなくなってしまいますから。
谷川 幹細胞の限界が寿命の限界になるわけですね。
寿命の限界は120歳!?...老化の研究から判明した「不老不死」実現の「残酷すぎる」真実（山中 伸弥,谷川 浩司） - 2ページ目 | ＋αオンライン | 講談社
⇧ なるほど、「記憶」などの「脳」の情報を引き継ぐことができる技術があれば、理論上は「不老不死」も実現できるってことですかね。
「脳科学」の領域の研究で、「脳」のメカニズムが解明されないことには、「脳」の情報をバックアップできるのか分からないので、「不老不死」の研究は頭打ちになりそうな感はありますかね...
「記憶」だと「遺伝子」とかの領域の話も絡んでくるのかな？
どちらにしろ、「記憶」を引き継げないのであれば、別人格で再スタートすることになるのだが、Wikipediaの「不老不死」の説明が正しいと仮定すると、
⇧ そもそも、「記憶」など人格に関係してきそうな点については言及されていない...
まぁ、「記憶喪失」の状態を「病気」と捉えるならば、「記憶」が引き継げることも「不老不死」の条件となるわけなのだが...
「不老不死」の定義がハッキリしませんな...
Confluenceとは
Wikipediaによりますと、
Confluence（コンフルエンス）は主にビジネスで使用される企業向けウィキ（ナレッジマネジメントソフトウェア、コラボレーティブソフトウェア）である。Javaで記述されており、サーバー側の動作にJDK（Java Development Kit）が必要となる。
アトラシアンが開発・販売を行っている。Confluence（コンフルエンス）は、クライアントソフトウェアとしてもホスティングサービスとしても販売されている。非営利団体やオープンソースプロジェクトであれば無償ライセンスプログラムを利用できる。
⇧ まさかの「Java」製。
Rendering frameworks
There are two frameworks that do the template rendering in Confluence: Struts and Sitemesh. Maybe confusingly, they both use Velocity as their templating engine. We try to distinguish between them by using *.vm for templates processed by Struts, and *.vmd for those processed by Sitemesh.
https://developer.atlassian.com/server/confluence/confluence-ui-architecture/
Rendering pipeline
The following diagram shows the flow of control through the Confluence UI.
https://developer.atlassian.com/server/confluence/confluence-ui-architecture/
⇧ 衝撃的なのが、「Apache Struts」を利用しているらしいということ。
ちなみに、
本ページは、「Apache Struts（脚注1）」の脆弱性対策情報をまとめたものです。
なお、本ページの対象とするのは「Apache Struts 2」 です。「Apache Struts 1」は既に2013年4月5日を以ってサポートを終了しているため対象としておりません。
⇧ 脆弱性が多過ぎて震える...
そして、「Confluence」なのだが、
アメリカサイバー軍所属のサイバー国家作戦部隊(CNMF)が2021年9月3日(土)に、Atlassian Confluenceの重大な脆弱性「CVE-2021-26084」について、「脆弱性の悪用が依然として続いており、今後加速すると見られます。まだ修正パッチを適用していない場合は今すぐ行うべきです。週明けを待つことはできません」と呼びかけました。
アメリカサイバー軍が「Atlassian Confluenceの重大な脆弱性の修正パッチを今すぐ適用すべき」と警告 - GIGAZINE
⇧ ほぼ毎年、脆弱性が発見されているっぽい...
DRY（Don't Repeat Yourself）原則
Wikipediaによりますと、
Don't repeat yourself（ドント・リピート・ユアセルフ、DRY）は、特にコンピューティングの領域で、重複を防ぐ考え方である。この哲学は、情報の重複は変更の困難さを増大し透明性を減少させ、不一致を生じる可能性につながるため、重複するべきでないことを強調する。
DRY は、Andy Hunt と Dave Thomas の著書 The Pragmatic Programmer (邦題:達人プログラマー) において中心となる原則である。 彼らはこの原則を、データベーススキーマ、テスト計画、ビルドシステムや、ドキュメンテーションにいたるまで非常に幅広く適用している。
⇧ とあり、同じ内容の記載を繰り返すのは避けようという考え方ですと。
ConfluenceはDRY原則に適応できておらずデリバリ手順の用途には不向きと思われる話
一応、「Confluence」の公式のドキュメントでは、
Confluence を技術文書の作成に使用する
Confluence は、技術文書の取り込み、配布、更新を支援する一連の機能やアドオンを備えた柔軟なプラットフォームです。独自の技術文書スペースを開き、ドキュメントのライフサイクルを管理する時間や労力を節約するためのヒントについて、以降で説明します。
https://support.atlassian.com/ja/confluence-cloud/docs/use-confluence-for-technical-documentation/
コンテンツの再使用による時間の節約
If there's something you're going to use multiple times in your documentation space – whether it's a word, sentence, or paragraph; an image; a product version number; or anything else – you can create it once and include it on as many pages as you like (or use it in the header and/or footer). Inclusions not only save you typing the same thing many times, they also make it easier when things change – it's much better to update the info in one place than 47!
There are three macros that allow you to re-use content:
-
抜粋マクロ: ページ上で再利用可能な部分を定義または「抜粋」します。このマクロの中にコンテンツを追加すれば、好きなだけページで再利用できます。
-
抜粋インクルード マクロ (
excerpt-include): 抜粋のコンテンツを別のページに含めます。 -
インクルード ページ マクロ (
include): ページのコンテンツ全体を別のページに含めます。
https://support.atlassian.com/ja/confluence-cloud/docs/use-confluence-for-technical-documentation/
⇧ とあるのだが、かなり残念な仕様となっている。
と言うのも、何かと厄介者扱いされるExcelなどのように、セル参照っぽいことができないので、デリバリ作業の際に実行するコマンド部分の動的生成ができないという...
例えば、ソフトウェアでデリバリしなければならない案件が100件あった場合に、Excelなどのセル参照が利用できれば、「パラメーターシート」の各セルの値を参照して、デリバリ作業の際に実行するコマンドが案件毎のものに自動で生成できることになるのだが、「Confluence」だと同じようなことが実現できないので、金太郎飴方式で作業する案件の数の分だけコマンドの修正作業が発生することになる...
特に、リソース名などは、案件毎に一意に識別できるものである必要があるので、手動でコマンドを修正する必要が無い形になっていないと辛いことになる...
By the way、「ソフトウェア開発」におけるデリバリ作業で頻出してくる「パラメーターシート」が何かというと、
⇧ 上記サイト様の説明がイメージし易いかと。
実際の「パラメーターシート」はというと、
⇧ 上図のような感じで、人間が見やすい形になっていることが多いのだが、デリバリ作業の際に実行するコマンドで欲しいのは、「設定値」の部分。
案件毎に「設定値」が異なるからして、セル参照などでコマンドの部分を可変になるようにしておいて、手動で変更しないで済むようにしておきたいわけだ。
「https://www.slideshare.net/nttdata-tech/infrastructure-as-code-2019-nttdata-sasaki-takai」のスライドは必見の価値あり。
まぁ、一次情報のフォーマットを変えられない場合もあるので、スライドで紹介されている改善案の実現は難しいことが多いと思うのだが...
して、「パラメーターシート」の方を「マスターデータ」と見なせば二重管理ということにはならないとは思うが...
Excelのようなファイルだと複製されて嫌だというのなら「パラメーターシート」の各々の項目の値をデータベースなどで管理するなどして一元管理になるように頑張るでも良いのだが、デリバリ作業の「ステークホルダー」が共通で参照できるデータベースを複製されない前提で運用しておかないと、Excelのようなファイルで管理する場合と同様の問題に行き着くので、ルールを決めておくしかない気はする...
ちなみに、
2つ目のコンセプトは、宣言的設定です。従来、サーバの管理にはExcelのパラメーターシートなどを用いて管理していました。さまざまなミドルウェアの設定を全てExcelのシートに書き出し、一つずつそれに沿ってサーバを構築します。しかし、これにも問題があります。
「Excel手順書にさようなら」――運用管理者の不安を解消する「Kubernetes」のコンセプト：これから始める企業のためのコンテナ実践講座（2）（3/4 ページ） - ＠IT
Excel手順書を用いた更新作業後、パラメーターシートが更新されないことが多々あるのです。その結果、パラメーターシートを確認してもサーバ側の設定が分からず、結局サーバでコマンドを操作して確認するという「2重管理」が起きます。
「Excel手順書にさようなら」――運用管理者の不安を解消する「Kubernetes」のコンセプト：これから始める企業のためのコンテナ実践講座（2）（3/4 ページ） - ＠IT
宣言的設定では、この2重管理を起こさないため、Kubernetesでのマニフェストファイルを基準にします。サーバ側の設定を変更する際は、このマニフェストファイルを先に修正し、Kubernetes環境に適用します。その結果、必ずKubernetesのマニフェストファイルの設定とKubernetes環境の設定が同一のものになります。もし同じ環境を再現する場合は、このマニフェストファイルを別の場所で適用すればいいのです。
「Excel手順書にさようなら」――運用管理者の不安を解消する「Kubernetes」のコンセプト：これから始める企業のためのコンテナ実践講座（2）（3/4 ページ） - ＠IT
⇧「Kubernetes」のような「コンテナオーケストレーションツール」を利用できているのであれば、Excelのデリバリ作業のようにセル参照っぽいことが「マニュフェストファイル」で実現できるっぽい。
なのだが、「継続的インテグレーション/継続的デリバリー（CI/CD：Continuous Integration/Continuous Delivery）」的な仕組みが構築されていない以上、手動によるデリバリ作業が必要になって来るのだが、案件毎にコマンドを修正する作業が発生せざるを得ない「Confluence」は「デリバリ手順」の用途として不向きだと思った次第...
案件100件分のデリバリ作業があったとして、実施するコマンドが100個あった場合に、修正が地獄なのよね...
とは言え、「Confluence」の代替として使えそうなツールが無さそうなのよね...
現場で、
- Atlassian
- JIRA
- Confluence
⇧「JIRA」も利用してることもあって、よりベターなツールが見当たらない...
妥協案として、「継続的インテグレーション/継続的デリバリー（CI/CD：Continuous Integration/Continuous Delivery）」的な仕組みが構築されるまでは、
- パラメーターシート
- 実行するコマンド ※1
※1 パラメーターシートの各々の項目の値は、セル参照して、コマンドを生成する
部分の手順については、Excelで管理していく感じが良いのかなぁ...
「銀の弾丸」は無いとはいえ、茨の道を行くようなことは避けたいので「ベストプラクティス」的な方法が知りたいと思うのだが、過渡期でのベターな方法についてのノウハウ的な情報が見当たらないのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
