米NASAは12月12日（現地時間）、惑星探査機「ボイジャー1号」のコンピュータに問題が発生していると発表した。探査機に搭載された3つのオンボードコンピュータのうち、「FDS」（フライトデータシステム）で発生したもので、エンジニアが解決に動いているという。
NASAの「ボイジャー1号」でシステム障害 エンジニアが「数十年前に書かれた資料」と格闘中 - ITmedia NEWS
現在、ボイジャー1号は地球から240億km以上離れた場所にあり、地球から最も遠い位置にある人工物として知られる。地球から送信されたコマンドがボイジャー1号に届くまで片道で22.5時間掛かるため、エンジニアがコマンドを送信して結果を確認するまで合計45時間が必要になるとしている。
NASAの「ボイジャー1号」でシステム障害 エンジニアが「数十年前に書かれた資料」と格闘中 - ITmedia NEWS
⇧ う～む、通信1回におよそ2日...
Amazonが10月に2基のプロトタイプを打ち上げた低軌道衛星通信「Project Kuiper」(プロジェクトカイパー)は、100Gbpsの光衛星間リンク(OISL)のテストに成功した。これにより将来的に宇宙空間で衛星同士のメッシュネットワークを構築する。
プロトタイプ衛星である「KuiperSat-1」と「KuiperSat-2」で行なわれたもので、テスト期間全域にわたってほぼ621マイル(1,000km)の距離にわたり、100Gbpsのリンクを維持した。これにより、Kuiperの通信技術の検証が成功し、2024年前半に打ちあげ予定の最初の量産型衛星でOISLが動作することが確認できたという。
⇧ 1000km毎ということは、240億kmの距離だと、
2400万基の衛星を配置する必要があると...
創作の世界のように、人類が宇宙で生活できるのはいつ頃に実現されるのかしら...
DBのテーブルのコード値（区分値）とは
そもそも、データベースのテーブルの「コード値（区分値）」って何ぞ？
⇧ 上記サイト様によりますと、
- フラグ
- 区分
- コード
を厳密に分けていらっしゃいますと。
結構、人によって解釈がまちまちになってくるかもしれないですが、データベースのテーブルの「コード値（区分値）」はザックリ言うと、『ある特定の値』のみ許容するという感じでしょうか。
身近な例で言うと、
日本十進分類法（にほんじっしんぶんるいほう、Nippon Decimal Classification; NDC）は、日本の図書館で広く使われている図書分類法である。最新版は新訂10版（2014年12月発行）。もり・きよし（森清）原編、日本図書館協会分類委員会改訂。
⇧ 図書館で活用されてる図書分類方法などを見ると、『ある特定の値』の値以外を許容したくないってことが分かります。
ただ、後から、分類が増減することも有り得るわけで、当然、データベースのテーブルの「コード値（区分値）」として管理してる場合は、「コード値（区分値）」も増減することになりますと。
例えば、
人類学（じんるいがく、英: anthropology）とは、人類に関しての総合的な学問である。生物学的特性について研究対象とする学問分野を形質人類学もしくは自然人類学と呼び、言語や社会的慣習など文化的側面について研究する学問分野を文化人類学もしくは社会人類学と呼ぶ。さらに言語学や考古学、民俗学や民族学、芸能も包括する。
人類学は人文科学、社会科学、自然科学の全てに根を持つ。人類学は対象を人類に定めている以外には、特に固有の方法論を持っているわけではない。そのため、その内容は、生物学的な手法を用いたゲノム研究や生理学的な研究から、社会科学や人文科学的な手法を用いてあるコミュニティの行動科学的な研究まで多岐に渡る。かつては自社会から遠く離れたコミュニティ、ないしは先史時代の人間を対象にすることが学問的な特徴とされていたが、現在ではそういった制約はない。つまり研究手法にとらわれない学際的な研究によって人類とは何かを全体として明らかにしようとする学問分野である。
⇧ 文化人類学は、人類学の一分野で、人類学が、
- 人文科学
- 社会科学
- 自然科学
の全てに関連するということで、既に日本十進分類法だとどう分類するのが正しいのかよく分からんのだけど...
まぁ、例えが悪かったのだけど、「コード値（区分値）」は、明示的に決めてあげる必要があるってことですな。
DBのテーブルのコード値（区分値）を一元管理するAll-in-Oneテーブル区分値（コードマスタ）という解
で、何某かのWeb系のシステムであれば、何某かのデータベースが利用されていることが大多数な気がしており、テーブルの数も何だかんだで100ぐらいあることは多そうですと。
で、困るのが、どのテーブルに「コード値（区分値）」が存在していて、「コード値（区分値）」としてどんな値が定義されているのか、網羅的に確認したいってこと無いでしょうか？
だって、既に定義されているものが分からない状態で、新しく定義しようとしたら既存の「コード値（区分値）」で定義済みの値と重複して定義してしまいかねないものね。
じゃあ、どこを見たら「コード値（区分値）」の一覧って把握できるん？
⇧ 上記サイト様によりますと、「All-in-Oneテーブル区分値」という方式が、「DBFlute」に存在するとのこと。
この考え方は、「DBFlute」に限ったものでは無いと思うのですが、「All-in-Oneテーブル区分値」という用語は「DBFlute」が発祥ですと。
⇧ 一般的にはコードマスタって呼称になるのかしらね。
- データベース
- ソースコード
のどちらでも定義が必要になるから、二重管理になってしまうのは致し方ないと。
「コード値（区分値）」が増減する場合に、
- データベース
- ソースコード
の両方を更新していく必要があるってことですな。
ソースコード側で「コードマスタ」のテーブルを利用しているのがすぐに特定できれば良いですが、分かり辛いと改修漏れに繋がりやすいですな。
特に、画面側の改修で「コードマスタ」のテーブルを使っていないけど、バッチ処理側で「コードマスタ」のテーブルを使っているようなケースだと、改修漏れに繋がりやすいですね。
ちなみに、別のスコープだと、
⇧「マスターデータ管理（MDM：Master Data Management）」って概念もあると。
まぁ、昔からマスター系の情報を管理するのは困難だったということで、その状況は変わらず現在進行形っぽいですかね...
「コード値（区分値）」が、どのテーブルのどの列（カラム）で利用されているのかも把握できるようにしておきたい気持ちはありますかね。
勿論、「コードマスタ」のようなテーブルで管理しないという方針のプロジェクトもあると思うので、その場合は膨大なソースコードや設計書などのドキュメントを精査するしかないわけで、このあたりに、
【顧客】『何故、たった1つの「コード値（区分値）」の追加の改修に、そんなに時間がかかるのか？』
という発言が出てくるような原因があって、回答としては、
【エンジニア】『影響範囲が全く見えて来ないからですよ』
となるわけですな、これが、リファクタリングされていないような可読性の著しく低いソースコードとかになっていると、尚更に影響範囲の調査に時間がかかるわけですと。
そもそも、調査していても必ず答えが見つかるとも限らないですし...
障害を引き起こすかもしれないコーディングを埋め込む要因にもなりかねないから、定期的な見直しやリファクタリングで可読性の高いソースコードを保つようにしたいってのがエンジニア側の視点なんだけど、ビジネス側としてはシステムが動いてるんだから不必要でしょ、という思考に落ち着くと。
まぁ、システムが爆弾を抱えた状態になったとして、それ故に、障害が起きたとしてもエンジニアのせいにしないでくれるなら構わんのんだけど...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
