川の防災情報サイト
kokorokagami
はい、どうも、kokorokagamiです。
東田です。
今週も一週間振り返っていきたいと思います。
はいはい。
今週といえば、台風2号エグかったですね。
touden
エグかったですね。
はい。台風2号というか、
それに伴う戦場降水帯も含めてっていう感じですけど。
kokorokagami
そうですね。
お宅は逆流しなかったですか?トイレとか。
touden
うちは大丈夫でしたけどね。はい。
でも、いろんなところの川がかなり危険水域になってるところもあれば、
氾濫しちゃったところもあって、
だいぶだいぶ被害も出てて、ちょっと大変ですねというところですね。
kokorokagami
そうですね。全国的に大雨警報が出なかった地域はほぼなくて、
河川地域の人はもう避難指示が片っ端から出てた認識ですね。
touden
そうですね。比較的に本海側はまだマシだったっぽかったですけど、
太平洋側は特に東海道新幹線通っている経路ら辺は、
かなり長い間降られてしまったので、
川という川が全部危険水域まで上がってる感じがありましたね。
kokorokagami
そうですね。特に関東の方だとあれですよね。
埋め立てたとか、もともと平野だった関係とかもあって、
touden
結構河川が溢れると一気に流れ込んじゃうくらい地面が低い。
土地が低いところもあって、
それもあって、かなりちょっと注意してみないな、いけないなという感じのところが多かったですけど、
でもそれを言うと大阪市だって結構埋め立ててるんですよ。
人のこと言えないですよ。
kokorokagami
あっちもやばいと思う。
touden
感じもありますけど。
そこら辺を含めて今日紹介するサイトなんですけども、
なんと国が作った国土交通省が作っている川の防災情報というサイト。
kokorokagami
これが結構よかったので紹介ですと。
touden
国なのに?
はい。国なのにって言うと怒られるかもしれないですけど、国なのにって感じですね。
アクセスしてもらうと日本地図が出てきて、
そっから自分の住んでる町のところバーッと近づいていくと、
川一覧で全部の川の情報が地図上に載っていて、
その情報も観測所で観測している水位の情報とか、
touden
川の量、水量を監視するための監視カメラの映像とか、
川に沿って全部ありますよというのが見れます。
これが結構首都角とかに行っても見れるんですけど、
そこで見れるのは結構首都角の情報だけだったりするんで、
広範囲に見たい時ですとか、会社行って会社から帰ってくる時の途中とか、
そういうところも全部一目同士で見れるんで、
そこがまず便利ですねというところ。
もう一つ便利なのが結構情報が詳しくてですね、
例えば水位観測情報というところをクリックしてもらうと、
横断図みたいなのが出て、今の川の水位がここですよと、
危険水位ここですよと、
溢れるところになるとここまで溢れちゃいますよみたいな、
ここ以上になると溢れますよみたいな情報がグラフと観測値と横断図という図で、
分かりやすく見れることができると。
これだけでも波の下手な仕様とかよりも情報がまとまっているなというところが見て取れるかなというところ。
さらに自分の登録情報とか、何なら浸水想定とかマップに重ねて見ることができるので、
kokorokagami
避難するときにも見ていると結構有用なのかなというところが結構便利だなというところでの紹介です。
いやーこれめちゃくちゃいいですね。
川の防災情報の詳細
kokorokagami
なんか国土交通省が取りまとめてやってたんだっていう認識ですね、どっちかというと。
touden
そうですね。
kokorokagami
ニュースとかでは結構地域ごとの市役所とかの企画でこういう川の水位を測定する設備を導入しましたとか、
そういうニュースは見てたんですけど、国発信でやってるのは全然知らなかったですね。
touden
そうですね。やっぱりなんて言うんですか、たぶん市とかの情報を、
市とかの情報をたぶん国土交通省が集めてるとは思うんですけれども、くしゃみが出そうで出なかった。
それを一覧表示してくれてるのはかなり頑張ってるなという印象です。
市によって情報の流度とかも全然バラバラでしょうね。
kokorokagami
でも取れてるデータとその測定間隔、測定間隔は全部バラバラなのか。
すごいな、ようまとめてるな。
今いくつか見てるんですけど、測定ポイントによっては10分間隔だったり1日単位だったりとかすごくまちまちですね。
touden
それでも一覧性があることでね、上流がやばくなったらここまでやばいんだなみたいなのが見て取れますし。
kokorokagami
避難指示に対しても、もちろん川のそばの人は急いで避難した方がいいんですけど、
川からこれくらい離れてるけど結局この川気にした方がいいのか、この避難指示はどこまで妥当なのかっていうのがやっぱり判断つきにくいっていうのは正直あると思うんですけど、
touden
これで自分の一応最寄りの水位とか実際に見れたり、カメラ映像をリモートで見れたら、これはやべえって動けるでしょうからいいですね。
そうですね。あと、どっちの川があふれそうになってるかっていうのを見て、遠い川に避難したりとかもできるでしょうし。
kokorokagami
そうだね。そうか、関東とかだと川とかの間に挟まれてる地域とかも結構あるのか。
touden
結構多いんでね。
そこら辺も含めて、何かの檻には参照していただけると結構いいのかなと思いますというところでの紹介でした。
ありがとうございます。
次、連続して私の方からなんですけども、1点目で、バンダムゲーミングチェアという椅子の紹介です。
これハーマンミラーさんが出していて、アーロンチェアで有名なハーマンミラーさんですね。
高級チェアやってたんですね。
やってたというか、今回コラボレーションで出したみたいな感じらしいですね。
そうなんだ。
これロジクルグループとのコラボレーションで、
ちょっとキーボードとかマウスとかロジクル信者の私としては是非とも座ってこないといけないかなと思い、
店舗行って座ってきましたという感じです。
そうですね。まずいいところから言うと、何よりも良かったところとして、ヘッドレストがめちゃくちゃ高いところまで上がるというところですね。
私結構身長が高くて、並大抵の椅子だとヘッドレストが頭の位置まで来なくてちょっとなくていいかなっていうレベルだったんですけども、
こいつはなんと私の頭のてっぺんの上まで行くヘッドレストで。
kokorokagami
それは伸びすぎるわ。
touden
ここまで伸びるんかいっていう感じでした。
kokorokagami
それはすごい。
touden
なので2メートルぐらいの身長の人でも普通に座れると思いますと。
素晴らしい言い方ですね。
あともう1個言うところとしては、ハーマンミラーらしくいろんな調整するスポットがあると。
例えば腰のランバーサポート、アームの高さ幅奥行き、腕を乗せるアームですねこれは。
座面の高さ調整、背もたれる深さの角度調整、ディクライニングの硬さ調整、座面の奥行き、ヘッドレストの高さ調整、ヘッドレストパッドの回転と。
欲しいところの可動部は一通り揃えているかなという感じがあるので、物足りないなと思うことあんまりないかなというところ。
あと細かいところで言うと、座面の高さ調整、チルトリミッターですね。
背もたれの深さが確か7段階ぐらい切り替えられる。
ディクライニングの硬さも7段階ぐらい切り替えられて結構細かく切り替えられる割に、
お高い椅子に逆にありがちなぐるぐるめっちゃ頑張って回さないといけないとかじゃなくてカチカチカチッと回すタイプなので調整もしやすい。
という意味でそこの機構はかなり好印象でした。
ハーマンミラーとロジクルグループのゲーミングチェア
touden
で、こんだけ機能が付いて15万弱、13万円ぐらいだったかな。
なので起動の前にだいぶコスパもいい椅子というところで、お勧めといえばお勧めかなというところですね。
kokorokagami
普通のアーロンが確か25万くらいですよね。
touden
そうですね。アーロンとかはヘッドレストも付いてないですし、そこら辺に比べるとだいぶあれですね。
kokorokagami
そういう製品と比べてどこが安くなっているポイントなんでしょうね。
touden
そうですね。そこなんですけども、細かいところのグレードがちょっと低いかなというところはあるかなと思います。
例えばちょっとチルト角とかを調整するグリップがタイヤみたいな感じで黒字に赤なんですけど、これがちょっと安っぽい見た目しているとか。
kokorokagami
あとはそうですね、アームが結構調整効くとは言いますけど、アーロンチェアーみたいにシータ角が回転しないとか。
touden
アーロンチェアーの特徴である座る座面側のメッシュではないとかですね。スポンジのタイプ。
なのでアーロンチェアーのケツむれないよっていうのを期待するにはちょっと足りないかなという感じとか。
そこら辺細かい部分で低価格感はあるとはいえ、フル機能、一通りの機能をサポートしているというところでは、好みに合えば全然これで大満足する人も多いだろうなという感じですね。
kokorokagami
基本的にはめっちゃいいなと思ってますけど、これどの辺がゲーミングなんですか?
touden
見た目?
kokorokagami
赤と黒っていう基調?でもさっきロジクールって言ってましたけど、赤と黒の基調ってどっちかというとシンクパッドとかそんなイメージだけど。
touden
まあ確かにねという感じですけど、そういう意味では普通にオフィスチェアーとしても使えるよというか、構造的にはゲーミングチェアーというよりオフィスチェアーなので。
そうですよね。
kokorokagami
ハーマンミラーさん、もう一種類?
ハーマンミラーロジクールコラボのエンボディゲーミングチェアーっていうの出されてて、こっちはめちゃくちゃゲーミング感あふれる見た目してるんですけど。
touden
いや、どちらかというとこれは元からあるタイプですね。
kokorokagami
そうなんですか。
touden
エンボディは元からあって、背骨に全部合うみたいな感じで売ってて。
それをゲーミングカスタムした。どこがゲーミングカスタム?なんかちょっと忘れちゃいましたけど。
kokorokagami
ゲーミングのロゴが入ってますね。
touden
あとカラーリングがあれとかかなという感じ。
kokorokagami
なるほど。今回のはもう最初からゲーミングチェアーとして設計されたものってことなんですね。
touden
そうですね。まあそういう意味で逆に、ハーマンミラーさん今までヘッドレスト付けない付けないって言ってたのに付けてきたんで。
そういう意味で、ハーマンミラーのメインストリームには逆におけないのかもしれない。
なるほどね。なるほど。そうか。
kokorokagami
だからゲーミングする上だと、頭の位置がずれて感覚が変わること自体が問題だからヘッドレストが必要だけど、
実際のデスクワークではそんなガチって固定してたら体に良くないからあんまりヘッドレストとか望ましくないとかそういう話なんですかね。
touden
まあ多分そうだと思いますね。ゲームを10時間もやるようなやつは首の骨痛めるからヘッドレスト付けてやろうかという話なんじゃないでしょうか。
kokorokagami
なるほどね。
普通に素直にゲーミングとか関係なく良い椅子だと思いますね。
touden
そうですね。普通にオフィスチェアーというか、ワーキングチェアーとしても関数が高いと思うので、全然これは買いだと思います。
kokorokagami
はい。いつ買うんですか?
touden
ちょっと悩み中。言わなかったんですけど、肩の上の部分がちょっと当たったなーっていうのがちょっと心残り。
kokorokagami
なるほどね。背もったれの形が結構R描いてて角度ついちゃってるから。肩幅が合わないときついのか。
touden
肩幅というか背中の長さっていうのかな。このタイプでそれなりに柔めなんですよね、背もたれが。
フレームにちょっと寄りかかっちゃうとフレーム感が出てきてるんで、それが長時間使って背もたれグイーってやるとちょっと気になるかなーってちょっと思ったり思わなかったりみたいな感じはちょっと心残りでした。
ので、ちょっと迷った。
kokorokagami
それは悩むなー。
touden
そうですね。もしかしたら岡村のどようなやつを買うかもしれないけど。
kokorokagami
うーん。
touden
って感じでちょっと悩んでますね。
でも、普通の人は全然気にならない領域だと思うので、普通におすすめです。
このクオリティで13万円安いと思いますし。
はい。ので、ぜひどうでしょうかという紹介でした。
kokorokagami
いいですね。また椅子沼に回る人が来るといいですね。
touden
いいですね。はい。
kokorokagami
はい。
touden
以上です。
kokorokagami
はい。じゃあ次行きたいと思います。
touden
はい。
NVIDIAとAzureの連携
kokorokagami
2点目。
NVIDIAとマイクロソフトが連携。
AzureユーザーはNVIDIAのAIのフレームワークとツールの利用が簡単に。ということで、ロボスターさんの記事です。
NVIDIAは2023年5月23日、マイクロソフトのAzureマシンラーニングにNVIDIA AI Enterpriseソフトウェアを組み込み、
エンタープライズがAIイニシアチブを加速するのを支援すると発表した。
この投稿により、セキュアなエンタープライズ向けプラットフォームが構築され、
全世界のAzureカスタマーはNVIDIA AIプラットフォームのソフトウェアレイヤーであるNVIDIA AIエンタープライズが完全対応している100を超えるNVIDIA AIフレームワークとツールを使って、
カスタマイズされたアプリケーションを素早く構築、展開及び管理できるようになる。
横文字が多すぎて意味が分からないと思いますけど、平たく言えば、Azureクラウドを使った方が最先端のAI開発できるよっていう話です。
わざわざなんでこれを取り上げたかというと、先日マイクロソフトビルドのイベントでAIにガンブリしてるって話はしたと思うんですが、
それをさらに超えるニュースですね。
NVIDIAは現状すごくAIに振り始めていて、かつそれもオープンでやろうという方針でやってます。
NVIDIAにしてみれば、AIの進化と加速によってNVIDIA製品が多く使われることによってNVIDIAが儲かるので、
AI技術自体がオープンになって加速することは大賛成、大歓迎です。
Azureは現状AWSの2番手としてクラウドを持ってますけれども、
残念ながらAWSに一歩遅れ続けているというところがあって、
クラウドを始める人はまずAWSを検討して、やっぱり自社のマイクロソフトサービスとの関係でAzureかなとか、
Windowsの方が慣れてるからAzureかなということで、
2番目にちょっと別の理由があってAzureにするみたいなことも多くあって、
なかなかクラウドといえばAzureと言われる世界には至ってなかったというところだったんですが、
この提携によってAIやりたかったらAzureという話になります。
AzureのAI開発の進化
kokorokagami
先日オープンAIのサービスもAzureに導入されてきたってことがあるので、
今これだけ盛り上がってるAI関係をやりたかったら正直Azure委託という感じになりつつあります。
このポジションは、実はもともとGoogleクラウドプラットフォーム、GCPがそのポジションにいて、
クラウドというのが立ち上がり始めた例名機、AWS、Azure、GCPの3つがあって、
AWSは仮想サーバー、Azureはマイクロソフトツール連携、
GCPは機械学習、AIみたいなところの住み分けだねっていう世界だったんですけれども、
今回のこのニュースを受けて圧倒的にAzureがAI関係では出し抜いた状態になりました。
どこまで出し抜いてるかというと、
NVIDIAはマイクロソフト、Azureが提供する仮想環境の内部のコンピューティングプリセットに
NVIDIAが持っているスーパーコンピューター的なアーキテクチャも導入すると言っているので、
他のAWSとかでAIをやるのに比べて、
はるかに高速で高効率に低コストな開発ができるので、
同じような開発をするんだったら、
AWSとAzureでAzureを選んだ方が5倍くらい早く開発スピードが上がってしまうという現実が出てきちゃいそうなニュースです。
touden
戦国時代感、ここに極まれるという感じがすごいですけど。
これに他のGAFAはどう対抗するんですかねという感じが正直ちょっと思うんですけど。
どうなんだろう。ここまでやられちゃうと厳しいんじゃないかな。
kokorokagami
結構厳しい。正直厳しいと思います。
マイクロソフトはオープンAIと提携しているけれども、別にマイクロソフト自身がコンピューティングサービスを持っているわけじゃないから、
マイクロソフトとしてはオープンAIみたいなものを開発したサービス、出来上がったものを提供しますよまでしかAzureとしては強みが発揮できていかなかったのが、
その大元も提供できるようになったというので、今まで苦手だった分野は克服できる余地があるという状態になりました。
対抗するためにそのGCPが古くからやっている手法をそのまま言うと、
Googleとしては独自にAIの開発を進めていて、GoogleホームとかAIスピーカー関係で既に実現している通り、いろんな機械学習モデルを持っています。
そういったモデルに最適化されたアーキテクチャ、フレームワークというのはGCP自身が持っているので、
今後Googleが出すAIのベースとなっているモデルがGoogleのこれまで培ってきたアーキテクチャ向きなもので、
かつそれがオープンAIと十分戦っていけるようなものであれば、まだまだやれる余地はあるんだと思うんですけど、
ただこれまでGoogleはその辺の機械学習系をちょっとクローズドにしてきたという背景もあって、
競合他社の対抗策
kokorokagami
このオープン戦略で一気に巻き返そうとしているNVIDIAやマイクロソフトに対抗するにはちょっとスピードが間に合わないので、
今からオープンにしてどれだけ取り戻せるかという議論になっちゃいますけど、まだオープンにするとかそういうニュースもないので、
GCPはかなり苦戦を強いられそうかなというところですね。
AWSはAWSで、Azureの後追いじゃないけど、世の中にはもっといろんなAIサービスあるよねっていうことを打ち出して、
そういったAIを開発するプロセスに注目したサービスを出してきています。
政治メーカーというサービスがあるんですけど、何が違うかというと、
AIのモデルを開発する上で、もともとのあるデータがこんなのがあって、
モデルをワンタン回したらこんな中間データが出てきて、それに人間のチェックを入れてまだモデルに取り込み直してみたいな、
そういう開発プロセスループみたいなのがあるんですけど、それをリッチなGUIで順次やっていける。
そのモデルを解析する瞬間だけPCをずらっと並べて分散環境を作って、その中間ファイルが出た時点でその環境を一気に消してみたいな、
コンピューティングリソース管理と開発プロセスを一括統合で見ますよみたいなサービスの方に振っていって、開発のやりやすさで勝負をかけているって感じかな。
touden
ちょっとGoogleは置いといて、公社の方は市場が広がれば広がるほどワンチャンありそうだなという気はするけれど、
マイクロソフトとエイドビディアとオープンAIのキングキングキングみたいな感じが強すぎるなと思ってしまうな。
kokorokagami
AWSの今話した戦略って、今までやってきた機械学習とかモデル開発の当たり前をサービス化しましたって話なんですけど、
今オープンAIとかでこれだけ劇的に様子が変わってきている中で、そのやり方というのがどこまで通用するのかというのは正直読めなくて、
新しいモデルを取り扱うにはその時点からこのモデルがどういうプロセスで開発されるべきかという議論に毎回ゼロスタートになっていくものだと思うんですよ。
すでにあるプロセスに合わせ込もうとする方が逆に開発速度を遅らせる可能性もあるので、
それを考えるとAzure一興に正直見えちゃうって感じかな。
touden
なるほど。ちょっと本当にパワーバランスが怖いっすね。海の向こうはって感じ。
kokorokagami
マイクロソフトなんてもう一時期オワコンまで言われてたのに、この持ち返しチップリはすごいですね。
touden
あるし、NVIDIAもだってAMDが数年前を盛り返してきた時は、そうそうレアバインちゃうかとか言われてたのに。
kokorokagami
所詮ゲームでしかいけないNVIDIAみたいに言われてたから。
touden
あとどこにグラボ乗せるんだいとか言われてたのに、こうなってしまうとはなという感じがありますからね。
kokorokagami
実際株価だだ下がりしましたからね一時期。作るゲーム、グラフィックボードはハイスペックだけど誰の需要にも応えてないとか言われてね。
touden
そうですね。だって今、年収が確か4倍、3倍ちょっとくらいで上がってる。NVIDIA今検索したら年収が150ドルくらいで今400ドルですからね。
kokorokagami
エグー。
touden
2.5倍?
そんな感じなんで、キング同士がオープン戦略で連携しちゃうとちょっと困るって感じですけど。
逆にキング側からするとそうでもしないとOSSに食われるっていう感じなんでしょうねこれは。
kokorokagami
そうなんでしょうね。
touden
取り込まないとみたいな。
kokorokagami
危機感を持ったのは多分、登場した生成AIの使われ方の部分だと思うんですよ。
touden
はいはい。
kokorokagami
ものすごくクローンされまくって、個人が開発したちょっとしたものだけ変えたモデルだったりとか、その開発プラットフォームだったりっていうのが、
もう無造作に増えまくったというか、インターネット黎明期のようにポコポコ生まれまくって、
touden
誰もディファクトを取る気がないっていう世界が生まれたんですよね。
kokorokagami
ディファクトを取る活動をしてる暇があったら新しいものを作った方が早いみたいな。
早いというかそっちの方が価値があるですかね。
っていう世界に対して、でかい企業がディファクトを取りに行くっていう戦略があまりおいしくないっていうふうにちゃんと見据えられたのがすごいかなって感じですかね。
touden
そうですね。
なので、ハードとソフトと、あとは環境を、
プラットフォーム、インフラを全部提供しますよ。
あとは好きにやってください。
kokorokagami
そうですね。
ということで、皆さんの会社の中でもAIの話はちらほら耳にするでしょうけど、
touden
Azure一択じゃないですかねって言っておいたらいいと思います。
それがいいと思いますというところです。
はい、以上です。
では次3点目は私の方からTechBlasterの記事です。
iSpaceの月面着陸失敗、理由はクレーター地形の影響でプログラムが誤作動か?というタイトルの記事です。
ランダーの誤差による月面着陸失敗
touden
ちょっと長いんですけど、ずらっと読みます。
iSpaceは5月26日、月面端子プログラムHACKTORMISSION1の結果を報告した。
同社が開発したランダーは、4月26日未明に月周回軌道からの効果を開始。
順調に進んでいたものの、最終段階でコードデータに誤差があり、着陸に失敗していた。
フライトデータを詳細に分析したところ、ソフトウェア側の問題だったことが明らかになったという。
同社のMISSION1ランダーは、2022年12月11日に打ち上げを実施。
同3月21日に月周回軌道に到着し、成功すれば民間初、日本初となる月面着陸に挑んでいた。
視線制御などは正常に機能し、ついにコード系がゼロを指したものの、そこに地面はなく効果が継続。
最終的には燃料が尽き、ランダーは自由落下して月面に撃沈したものとみられる。
MISSION後、同社は失敗原因の調査を開始。
そこで分かったのが、ランダーがコードゼロと認識していたのは、実際にはまだコードが5kmくらいあったところだということだ。
なぜこれほど大きな誤差が生じてしまったのか。
その理由を説明する前に、まずはコードについては補足が必要であろう。
実はここで言うコードには3つの種類がある。
もちろん、実際にランダーが引っ越したコードはその1つだ。
ただ、月面で誰かが直接観測していたわけではないので、この真の値については分からないというのが前提になる。
本当のコードは分からないものの、それではシーケンスの実行時に困ってしまうので、ランダーは自分で推定したコードの値を用いる。
ランダーにはそのためのセンサーとして感性計測装置IMUが搭載されており、高頻度に推定値を更新するのだが、時間が経過するほどどうしても誤差が累積して大きくなってしまうという特性がある。
もう1つがレーザーレンジファインダー、LRFで計測したコードだ。
前述のようにIMUのみによる推定コードをどうしても誤差が累積するが、この測定コードでうまく補正してやれば、その累積誤差をリセットできる。
センサーとコードの推定による誤差
touden
更新頻度はIMUよりは荒くなるものの、LRFはレーザーで地表までの距離を直接測定するので、誤差の累積のような問題はない。
今回の着陸では、1時35分、高度15km付近で最初のLRFの測定が行われ、推定コードが修正された。
この時、推定コードと測定コードには3kmほどの差があったが、この補正により2つのコードのほぼ中間点が新たな推定コードとなった。
難しいのは、推定コードと測定コードに違いがあった場合に、一体どちらがより本当の値に近いのか判断することだ。
普通に考えれば測定コードの方が正しそうだが、センサーが故障していたり、故障でなくともバイアスが乗っていたりする可能性もある。
そのために、この2つのコードにはそれぞれ信頼性を示すパラメーターがあるという。
例えばIMUのみで調位時間を推定していれば、信頼度は低下していく。
一方、測定コードは最初の1回目は正しいかどうか怪しいが、その後何度も繰り返し測定してその変化が予想通りであれば正常に機能している可能性が高いといった具合だ。
最初の1分くらいはこれがまさに理想通りに動作した。
LRFの測定コードがいくつか届き始めると、推定コードがその都度修正され、両者の値は収束していった。
しかし1時37分過ぎ、突然測定コードが急激に増上した。
これはタイミング的にアトラスクレーターの縁の上空を追加した時だった。
ランダーは降下を続けていたものの、クレーターの段階で地面が急に下に離れたので、崖の高さは3kmの上がると、数値的には自分が上昇したように見えたというわけだ。
ランダーが急に上昇するはずはないし、普通の地形であればこんな急に変化することはない。
結果として、この急激な高度変化をソフトウェアはセンサーの異常と判断してしまった。
そのため測定コードによる補正が行われなくなり、大きな改良を残したまま降下は最終段階に入り、1時43分の推定コードがゼロになった。
つまりランダーはクレーター外側の高度に地面があると思い込んだまま、着陸しようとしてしまったということになる。
しかし実際には、そこにはクレーターの穴があって、地面は遥か5kmも下、1分ぐらいは頑張って噴射を続けたものも燃料が尽きて自由落下を開始。
1時45分、地面に激突し、通信キャリア電波が喪失した。
なお、高度の測定にはLRFのほか、電波によるレーダーベロシメーターも使う予定だったが、
これは高度2km以下の近距離で使えるセンサーのことで、今回は最後まで測定が開始されることはなかった。
この点も、地面が5kmも下にあったという推測を裏付ける。
この記事のタイトルでは、プログラムが誤作動と書いたものの、プログラムとしては作った通りに動いたと言える。
クレーター外側への上空を通過することは最初からわかっていたことで、問題はなぜこのように動くことを事前に把握できなかったということになるだろう。
もちろん同社も事前に多数のシミュレーションを行っていた。
しかし、シミュレーション範囲を絞っていたため、クレーターの地形による影響が現れなかったのだという。
シミュレーション範囲はなるべく広くできれば理想であるが、広範囲にすればするほど計算時間が長くかかる。
それだと計算できる係数数が少なくなってしまうので、現実的にはうまくバランスを考えて折り合いをつけるしかない。
シミュレーション範囲と着陸地点の変更の影響
touden
同社のCEOは、この範囲の検討の仕方が正しくなかったと述べる。
ミッション後にシミュレーション範囲を広げて再計算したところ、実際に起きた現象が再現されたという。
もし事前にこれをやっていれば、今回の失敗を防げたはずだ。
同社にとっては手痛い経験となってしまったが、今後は例えば時間がかかっても数ケースは広い範囲で計算するなど、検証上の工夫をしていくという。
ただ失敗したとはいえ、今回はソフトウェアの問題。
それもコードの推定部分のみの問題であって、ハードウェア側はほぼ完璧に動作したというのは、
ほぼ完璧に機能したというのは、次回に向けて非常に大きな成果だったと言える。
改修作業としては大規模なものではなく、2024年に実施する次のミッション2の計画には大きな影響はないだろう。
今回の失敗の直接的な原因は、このようにシミュレーション範囲の設定が適切でなかったことだと言えるが、背景要因として言及したのが着陸地点の変更である。
同社は2021年2月に詳細設計審査を完了した後に、着陸地点をルーカスソムニウムからアトラスクレーターに変更していた。
この変更が発表されたのは打ち上げ直前の2022年11月17日で、実際に変更を決断する時期については公表を避けたが、
変更後にシミュレーションにかける時間を十分確保できなかったことが、今回の失敗につながった。
これについては、CTOもプロジェクト管理上の問題があったと認める。
ミッションマンはクレーター内への着陸というかなり特殊なケースだったが、もし変更前の場所であれば、そんな極端な高度変化は起きない。
今回のソフトウェアであっても、十分着陸に成功していた可能性がある。
今回の失敗により、ペイロードの顧客からの売上が1億円ほど減少するものの業績への影響は軽微だという。
同社のCEOはミッションマンの結果をフィードバックし、技術の信頼性や成熟度を上げ、サービスを提供していきたいとコメントすることになりました。
ということで、なかなかと話してしまいましたけども、なかなか不幸な事故でしたねという感じですかねと思っています。
マシンとしては非常に健全であった。
通常範囲であれば設計ルーチも正しかった。
ただし、クレーターの縁を運悪く通過するのが効果タイミングだったために推定を誤って危ない側に転んでしまって、その結果失敗したという感じですね。
これを誤作動と言われるのはソフトウェアエンジニア側からするとちょっと意気地が悪いなという感じですね。
そういう意味も込めて、文中ではソフトウェア誤作動というのは厳密には正しくないと言ってはいるんですけども。
それやったらタイトル変えてほしかったなという感じがありますね。
まあ言い方がないっちゃないんだけど。
kokorokagami
だから使えるセンサーと信頼度を獲得するためのロジック自体がそもそもこういう測定欠陥のノイズに弱いっていうのはおそらく致命だったと思うんですね。
はい。
信頼度の作り方的に、センサーのノイズは当然信頼度を下げる方向にしか働かないので、それは多分みんな分かってたと思うんですよ、開発者は。
touden
はい。
kokorokagami
で、その上で言うて月面の誤算範囲ってこんなもんだからこの範囲のばらつきでテストして問題なければいいでしょうっていう範囲に絞ってやってたんだと思うんですよね。
はいはい。
で、この結果なんで、正直もう多分担当者的にはそんな地形を飛ぶこと自体が効果されてないんだけどレベルの状態なんじゃないかろうかって思っちゃいますね。
touden
そうですね。まさにそれはその通りだと思っていて、途中で変えてしまったので、事前の検証範囲設定は何というか正しかったと思うんですよ。
ただ、現実問題飛んでしまったところがその検証範囲よりも厳しい条件で、かつその結果として危険事象が発生してしまった。
kokorokagami
はい。
touden
という感じなので、なかなかやりきれませんなというところですね。
kokorokagami
やりきれないですね。やりきれないですね。
もちろん今回の問題には対処すると思うんですけど、今回の学びとしてその飛ばせるタイミングとか天候とかのいろいろな関係上、こういうこと部分を通らざるを得ないっていうのが事前にわかるってことはまあまああると思うんですよね。
はい。
直前になってわかる。
そうなった時に、じゃあ対処しようと思って時間がないって言われるんだったら、事前に月におけるあらゆるイリアルフローを見出していって全部シミュレーションにかけるみたいな話になると思うんですけど。
touden
はい。
kokorokagami
ソフトウェア開発コストがべらぼうに高くなっちゃうんで、難しいなって感じですね。
touden
まあというか無理だと思いますね。
月の表面積全てでシミュレーションしろっていうのはちょっと無理なので、ある程度ワースト条件絞ってやるしかないですけど、でもワースト条件って言ってしまうと月の裏側は着陸できないか。
なんですけど、めちゃくちゃでかいクレーターとか5キロとか目じゃないと思うので、それはそれでマジでもう無理って感じだと思いますし、ある程度想定範囲にしないといけなかったけど。
なので最終的に着陸するのはやっぱりプロジェクト上の問題。
飛行する着陸ポイントを変えた時に問題があるとして拾い上げてもう一回シミュレーションをするということができなかったっていうのが問題と言えば問題かなというとこですよね。
kokorokagami
そうですね。エネルギーにも限界があるから着陸地点をそこまでいい場所を選び続けられるってこともないんでしょうから。
そうですね、はい。
これはでも本当頭痛いな。ソフトウェアエンジニアだけの目線で言ったらもう根本的にはセンサー数の限界だと思いますって言いたくなる。
川の防災センサー
touden
この今搭載しているセンサーでできることの限界に近い話なのでっていう気がするな。
kokorokagami
効果シーケンスが始まってからもっと角度の高いセンサーが登場するのが2キロ地点で、この18キロ間はもう2つの方法で見るしかないっていう時点でもう積んでるというか。
それにはセンサーの誤調も検討しろって言われたら冗長ケース足りないじゃんっていうのが単純にソフトウェア目線で言いたいことだけど。
touden
そうですね、はい。
kokorokagami
うーん、まあね、ハード屋さんからしたらもうこれ以上載せられるわけないだろうっていう状態だろうし。
うーん、むずいっすね、ほんと。
touden
まあ、なので、うーん。
まあ、そうですね。
敷地設定ができることとしては敷地設定がまずかったかなって感じはあるかもしれないですけど、このクレーターを通ることが決定した時点で最大4キロか5キロぐらいの高低差が発生するということなんで、
故障した判定を5キロより上にしておくべきだったとかぐらいかなーって感じですね。
kokorokagami
そうですね。
touden
自分がどこにいるかわからないので、
その時間境での最大発生する測定差までは大丈夫というか、エラーとして判定しないようにすべきだったかな。
kokorokagami
そうですね。
あとやれるとしたら、LRFのダブルビーム方式みたいなのができるんかどうかとかかな。
touden
2個乗せろってこと?
kokorokagami
レーザー発光源2つにして、片方はもう同じように飛ばすんだけど決まった範囲で確実に返ってくるように反射板に向けて撃つ。
で、片方のレーザーは地表まで飛ばすっていう。
うーん、それはどうなん?
ドリフトとオフセットくらいは補正しやすくなる?
touden
まあ、それはそうなんだけど、オフセットとドリフトが補正しやすくなったからといってカバレッジが100じゃないからな。
実は即興側が安全率は高まるんだけど、急に値を変えた時に即興側が故障した、発光か重光かわからんけど、ならこっちは落としましょうって結局なっちゃう気がするけどな。
kokorokagami
まあね、何かそのソフトウェアのロジックとして判断する情報が1個2個増えないときついんで、何か増やせないかなって思ってるくらいなんですけど。
推定コードもこれってあれですね、多分加速度センサー3つくらい乗っけて軸別々にしてそれぞれの軸で同じくらいの値を示してたら1つのデータとして扱うみたいな加速度計を乗っけてやってると思うんですけど。
いいアイディアないんですけど、時速とか他の情報を使ってもう少し別の技術ベクトルで推定コードの計算値に盛り込めるようなものを作れないかとかそんな話だと思うけど。
推定コードの算出を2系統3系統でやってとか。
でもいいアイディアじゃないな。
touden
カバレッジが下がる気がする。
kokorokagami
それもそう。
処理増やすっていうのは故障点も増えますからねーとは思ってしまって。
難しい予測だね。
センサー技術の改善
kokorokagami
単に増やせばいい問題ではないので。
効果的に増やさないと意味ないよね。
機能停止して大丈夫であればね、地球上であれば別にいいんだけどなーっていうところがあるんだけどな。
数パーセントでも確率上がるんだったらいいじゃんの世界ではないんだよな。
対策されるってことなので、その対策内容も気になるくらい悩ましいな。
宇宙関係の失敗報告書大体そうですけどね。
こんなのわからんやろみたいなものばっかり言う。
touden
まあでも真にすごいのはそれを追い込んでシミュレーションで実際に確認したから真にこれですところまで原因調査報告書出せるところだよな。
kokorokagami
それはそう。
touden
マジで何にも手がかりない状態レベルからやってるからほんまに探偵レベルですよこれは。
kokorokagami
本当に。
その探偵が最低限機能できるだけの情報がちゃんと装置に組み込まれてるのが素晴らしいですね。
touden
まあそうですね。
kokorokagami
さっき堂田さんおっしゃった通り、増やせば増やすほど故障点が増えて逆にミスというか失敗につながることになってしまうので、
むやみやたらにあらゆるデータを地球に送ればいいというわけじゃないじゃないですか。
送れるデータ量にも限界があるし。
そういった中で今回こういった問題が起きた時に解析するだけの情報は拾えてたというあたりとかね。
touden
優秀だなと思うな。
そうですね。
マジでここで積んでしまうと絶望しかないからね。
kokorokagami
そう、なんかわからんかったけど多分高かったんでしょうねみたいな見解だと投資家は納得しないね。
touden
うん、てか次飛ばせないからね。
kokorokagami
そう。そういったのは改造もできないし。
いやー、そうだな。
ちょっと、まあ。
touden
まあまあまあそういう感じなんで、とりあえずは実験は成功だということで次に行きたいですねと。
kokorokagami
はい、もちろんもちろん。
次はもう覚えに行きたいですね。
touden
はい。
kokorokagami
はい。
Jupyter AIの導入
kokorokagami
じゃあ次行きます。
touden
はい。
kokorokagami
4点目、ジュピターAIが出た試したすごいということで聞いたのを疑似で、
まあもうタイトルの通りなんですけど、
まずジュピターとは何ぞやって話なんですが、
ジュピターっていうのは一般的にジュピターノートブックっていう言葉の方が聞きなじみがあるかなというものなんですけれども、
ウェブ上だったりブラウザ上でPythonを実行できるプラットフォームで、
セクション単位にプログラミングを分けてかけて、
順次実行ができる環境ですね。
なので試行錯誤性に非常に長けた環境です。
Pythonのプログラムを一般的にテキストエディターで書く場合は、
Pythonのコードを上から下まで書いて、
全実行、全実行、もしくはデバッグを実行してステップ実行、みたいな感じになります。
次にもう一つの実行形態としては、Pythonコマンドを叩くと、
Python実行環境コンソールみたいなのが出来上がって、
その上で一個一個コードを書いていくみたいな感じになります。
このJupyterというのは、それをもっと中間点を狙ったものになっていて、
あるセクション単位でプログラミングを書いて実行させて、
そこまでを実行すると。
その後別のセクションを書いた時に、
前のセクションの実行結果を残しつつ実行してくれるというものです。
これによって何がいいかというと、
AIのモデル開発とかグラフの作成とかを試行錯誤する場合は、
データ源は一緒で、こうパラメータを変えてみたらこうだった、
こうパラメータを変えてみたらこうだったということで、
プログラミング全体の一部分だけをちょこちょこ変えて実行することが多いんですね。
そういった試行錯誤に非常に向いたプラットフォームとして、
Jupyter Nodebookというのがありまして、
Web UI上で動くという利便性も相まって、
非常にそういったプラットフォームとしてはデファクトなものになっています。
そのJupyter NotebookにAIが登場しましたと。
内容としては非常にシンプルで、
Jupyter Notebookの左側ら辺にChatGPTのウィンドウが出ていますと。
そこでいろいろ質問ができるんですけれども、
ChatGPTの一般的な質問というよりは、
Jupyter Notebookで書いているプログラムについて質問ができます。
なので、例えばプログラミングのあるセクションとして、
こんなものをここまで書きました。
次こんなことしたいんだけど、次のセクション作ってくれないみたいなことを言うと、
次のセクションにあたるプログラミングを生成してくれたりとか、
あとはJupyter Notebookは他の人もオープンにそのノートブックを公開して、
情報共有するという文化があるんですけれども、
そのブックを取り込んで、
ChatGPTにこのブックがどういうことをやっている、
このセクションで何をやっているか教えてくれというと、
最先端のAI開発とか機械学習をやっている人たちのノートブックを元に、
自分でリバースエンジニアリングしながら勉強できるというようなプラットフォームになっていけるので、
非常に利便性が良いです。
この辺のJupyter AIというのは、
ChatGPTのプラグインで似たようなものも出ていたんですけれども、
これはJupyter Notebook側でスターポートされているので、
今まで使ってきたプラットフォームに一つOpenAIのAPIキーを足すだけで良いということで、
今既に開発している人は簡単にChatGPTありのプラットフォームに移行できるということで、
こういうのがどんどん増えていくだろうなということで紹介です。
touden
普通にまずJupyterから良いなって感じたんですけれども。
kokorokagami
Jupyter良いでしょ。
touden
Jupyter良いですね。
マットラボとかの環境にも展開してくれないですかね。
仕事で使いたいんですけどっていう感じなんですけど。
そのJupyterさんにAIで補助というか、これは何て言うんだ。
AIを被せられるという言い方があるんですけど、
AI側からドキュメントの補正をかけられる。
そうですね。
ということですね。
なんというか非常に正しいAIの使い方だなという感じですね。
ちょこちょこ動かすところでAIで補正してパッと出して、
トライアンドエラーの回転数を上げるということができるというのは非常に便利なので、
全ての言語はこうなるべきではないんでしょうかという感じがしますね。
kokorokagami
そうですね。おっしゃる通りだと思います。
これでものすごく高速化されたユースケースが1個あってですね、
このセクションを実行しました。
エラーが出ましたってなったとき、
今までだとエラーコードを調べます。
そのエラーコードの内容と自分の書いたコードが関連あるかどうかを見て、
直接的なエラー原因なのかどうかを判断し、
直接的であればそのエラー原因を調査して自分の行動の誤りを見つける。
間接的であれば本質的なエラーコードが何なのかっていうのを、
そのエラーが出るケースっていうのを調べ直して再探索するみたいなことが発生するわけですね。
今回のこのJupyter AIであれば、
コードとエラーコード両方見える形で問い合わせができるので、
AI側の回答っていうのが単純にGoogle検索でエラーコードを検索するよりも、
圧倒的に本質をつく可能性が高まります。
ので、これまでのエラーに対するデバッグが非常に高効率化されるだろうと想定されます。
はい。
touden
いやー、いいですね。聞けば結構ほどいいですねという感じですけど。
Jupyterの話になっちゃうけど、これどうやってるの?これ。
全ての中間ポイント全て保存してるの?これ。
そうですね。
kokorokagami
Python自体も実は一行実行みたいなことができるようになってて、
GitLeaksの機能
kokorokagami
一行実行したものをどんどんどんどんメモリに貯めていってくれるっていう機能があるんですよ。
で、Python単便だと一行実行だけ。
テキストで書くと全実行だけっていうところだったんで、その間をうまく作ってるって感じ。
touden
まあでもセクションごとに実行してってのが一番利便性高いだろうし。
そこでAIがセクション関連を認識しやすくもなると、一石二鳥ですねという感じですね。
そうですね。
kokorokagami
Jupyterの宣伝になっちゃうけど、Jupyterはこのコードの外にマークダウンでドキュメントが書けるんですよ。
なので、例えばもう最初からドキュメント形式でこういう画像解析をこの機器の画像解析を行うためのPythonプログラムですみたいなタイトルをつけて、
目的とか背景を書いていって、まずはこういうことをやる必要がありますみたいなことを日本語で書いた下で、
このプログラミングのセクションが埋め込まれていて、このセクションの実行結果はこれですみたいな感じで書いていくと、
今までプログラミングを書いて実行結果をスクショしてワードに貼るっていう手順じゃなくて、
もうマークダウンに書いている間に実行できるプログラミングが埋め込まれているみたいな状態で書ける。
touden
なるほどね。いいじゃないですか。
先ほど言ったノートブックの共有文化がすごく盛んなんですけど、もうそれが全てだからって成果物のっていう。
kokorokagami
なのでそういう文化圏とまたこのAI、見えてる範囲の情報を使って質問できるということがものすごくマッチしてる、いいケースだと思いますね。
touden
いや、いいですね。この開発環境で開発したいなと思います。
kokorokagami
Jupyter自体はただなので、いつでも入れてもらったらいいと思います。
touden
まあまあまあ、それはそうですけども。
kokorokagami
APIキーは御社ではなかなか発行できないと思いますけど。
touden
そもそもマトラボなんでJupyterが使える環境ではないですね。
kokorokagami
マトラボに似たようなのが出てくれるといいですね。
touden
そうですね。マトラボさんもかなり開発意欲が旺盛なので、こういうのも流行っていればそのうちに入れてくれるかもしれないし、
こういうのが流行るのはいいことだと思うんで、今後に期待ですねというところですね。
kokorokagami
次回ですけど、この件こんなもんです。
じゃあ今日最後ですね。
Gitのセキュリティ管理ツール
kokorokagami
5番目、GitLeaksで機密情報の漏洩を防ぐコマンド編ということで、Developers.ioの記事です。
GitLeaksは機密情報の漏洩を防ぐためのツールです。
簡単なコマンド実行を通してGitLeaksの使用感を記事にしました。
コマンドの使い方や実際の出力内容が分かるようになっています。
ということで、Gitのセキュリティ管理ツールのお話です。
Gitにまずこういうセキュリティツールが最近増え出していまして、その背景をお伝えすると、
ニュースでご存じかもしれないですが、パブリックなGitHubの個人リポジトリにアクセスキーとかを埋め込んでしまって、
クラウドの費用が多額に発生した。
ソースコードが流出した。
あとは個人情報が抜きこ抜かれた等々いろんなニュースがあります。
その中にはGitの使い方に対するリテラシーの低さによって起きた事例も少なくないです。
Gitというのはプログラムの構成管理ツールでバージョン管理とか差分チェックとか色々できるので非常に便利で、
あらゆるソフトウェア開発に導入されているツールではあるんですけれども、
一方でGitの中にどんなものが入っていてとかそういう検証はしてくれなくて、
単純にリフを取ってアップロードするだけというツールになっています。
なのでユーザーが例えばある一つの塊をGitHub等にアップロードする際、
あまり考えずに多量な変更を同時にかけて一気にアップロードみたいなことも別にGitとしては防ぐものではないですと。
Git Flowとかそういった推奨のプラクティス的にはNGなんですけれども、
別にツール自体がそれを防いでくれるわけではないですと。
そうなるとGitをアップロードするときの差分というのが非常に多くなるので、
よく分からんからとりあえず今動いてるし上げちゃえみたいな形で上げたり、
あとはそもそもなかなかGitのディフをチェックするという文化すら正直ない現場もあって、
そういうのが続いてしまうとどうしてもこういった機密情報の漏洩というのがなくならないという背景があって、
このGitを拡張する形でセキュリティチェックが自動的にかかるといいよねということで、
いろんなツールが出始めてますという背景があります。
最もメジャーなものはGitSecretsというサービスがあって、
それはGitでデータをアップロードする際にチェックをしてくれて、
こんなものが入ってるからこれをアップロードしたらまずくないっていうのをチェックしてくれるものですね。
あとはGitHubにも自分のリポジトリに上がってくるデータの中にそういうものが入ってたらちょっとまずくないって言って止めてくれるとか、
そういった機能が最新リリースとして入ってきてたりします。
そんな中でこのGitLeaksではもっと直接的にユーザーが自己チェックできるところまで幅を広げているツールです。
GitLeaksでは今自分が開発している差分、最新のリポジトリの状態と自分のローカルな手元の状態の差分を見たときに、
その差分に変なものが埋め込まれてないかっていう検出をかけたりとか、
あとはそのコミットをする前、もう本当に今修正している、今の状態で変なものが含まれてないかっていうチェックをかけたりとかいうことができるので、
自分がそういった情報に気になったタイミングで即チェックをかけられるというのが大きなポイントですね。
なのでこれはGitSecretsと併用することも全然ありで、GitSecretsはアップロードする際の最終防波堤として導入。
このGitLeaksは自分がつつつ開発するときに、そういえば今までどのように開発してたけど、
今のリポジトリの状態って本当に機密情報含まれてないんだろうか、安全なんだろうかというのをチェックするために使うとか、
あとは今までローカルでずっと開発してたけど、他の人が欲しがってるからクラウドや社内のGitサーバーにアップロードしようってなる直前でこれをかけると、
過去のGit履歴を遡ってチェックしてくれますと。
過去のGit履歴を遡ってチェックしてくれるというのは非常に重要で、
Gitというのは全てのこれまでの更新履歴を残しているツールなので、一時的にアクセスキーを追加してしまって、
そういえばこういうアクセスキーって入れちゃいけないんだって決してコミットして最新状態にして、
ぱっと見なかったとしてもGitの履歴を追ったらそのキーは拾えてしまうので、そういったところにも含まれないようにしなければならないですと。
そういう過去に遡ってそういうキーを全削除したりとか、そういうファイルを消すみたいなGitのコマンドもあるんですけど、
なかなかそこまで行くとGit初心者の人には探し方もわからないっていうこともよくあるので、
そういった面でもこのGitLinuxは非常に便利かなと思っての紹介です。
touden
はい。
確かにGitという性質上コミットする前に見れるっていうのは非常に有用かなと思いますと。
kokorokagami
何でしょうね。
touden
でもなんか聞いてて思ったけど、このツールは非常に有用だし、分かった人が使えばいいんですけど。
最終防波堤として分かってない人間が使われてしまうと結局コミットされちゃうなぁと、
勇気がしちゃうなぁ。
でもこれがチェックツールとして、一応チェックツールとしてGOのGO判断を出してくれて、
それを人間側がチェックしてとかなんかで確認すれば、なんとかなるはなるか。
そういう意味では自分が何書いてるか分からなくてもフラグが立つっていうのは非常に重要なので、
そういう意味で普通に有用なツールっていうのはそうですね、そういう感じですね。
kokorokagami
そうですね。今後ちょっとGitHubとかの改善も必要にはなってくるんですけど、
最近GitHubではですね、プリのプルリクエストレビューみたいなのがローカルで見れるようになりました。
イメージとしてはプレビュー版みたいな形で見れるんですけど、
今までプルリクエストっていうのはGitの構成管理サーバーに上がったソースコード2つを比較して、
これをマージしようとする、くっつけようとするけどいいですかっていうのを第三者にレビューしてもらう機能として登場してきてたんですが、
それがクラウド上の差分になって間違いがあるって分かった時に、今回のようなアクセスキーの問題だと、
そのエラーが見つかっている時点でもう手遅れというかアウトなんですよね。
もう公開されちゃってるというか。
なのでアップロードする前にチェックするというのが非常に大事なんですが、
プルリクエストでも同様にそのチェックが手元でできるようになりましたと。
そこでディフも見れるようになったので、今まで以上にディフに気づけやすい環境ができつつあるんですけれども、
今回のようなツールをそのタイミングで強制的にかけられるようにするとか、
そういう拡張が登場してくると、もしかすればそういう開発環境を社内で広めてこの環境で使えよっていうように指示していれば、
定理でらしいでも何とか乗っかれるとか、そういう環境は作っていけるかもしれないです。
touden
なるほど、まあ確かに。
なんかツール側でも何かのフラグが立ったら、そもそもコミットボタン押せないとか。
kokorokagami
そうですね。
touden
そこまでいければいいのかな、それが。
確かにね。
kokorokagami
そうですね。
Gitの普及と問題点
touden
なるほどね。
まあ必要だなと思うし、導入するのは完璧同意ですけど、
なんかこう、Gitってすごい便利だよねというところからなんか遠いところまで来たなと遠い目になりますね。
kokorokagami
そうですね。
こういう問題が騒がれだす時点でようやく業界的にディファクトになってきたなって感じですかね。
touden
まあそれはそうですね。
kokorokagami
リテラシーの低い人でも使うようになってきたということは、ある意味喜ばしいことですね。
touden
そうですね。SVN時代のパブリックサーバーなんてないですから。
うんうんうん。
なるほど。
はい、ということで。
どうぞどうぞ。
kokorokagami
いや、GitLinuxって名前はどうなのってちょっと思ったんだけど。
touden
ああ、確かに。リークさせる方じゃん。
kokorokagami
リークさせる方じゃんって思ったんで、なんかGitとVirusで流行ったのかなと思ってしまいましたね。
touden
確かに、名前よくないね。
kokorokagami
なんでこれにしたんだろうっていう。
確かに。
touden
もしかしたらリークという言葉が和製英語なのかもしれないけど。
kokorokagami
うーん、そんなことはないでしょう。
touden
そんなことない。
kokorokagami
リークはだって、ほら機体配管のリークとか言うじゃん。
そうね。
うん。
川の防災情報
touden
ああ、そうだね。ちゃんと語源からしてちゃんと漏れるんですね。Git漏れるだねこれ。
Git漏れるだね。
というところです。
漏れてるね。
kokorokagami
リークとかじゃダメじゃないでしょうか。
touden
そうですね。解明のリクエストを本気に送った方が良さそうな気がしますね。
はいはい。
じゃあ今日はこんなところですかね。
本日の内容は書の音にまとめていますのでご確認ください。
Recalogでご感想やこんなことを話して欲しいといったこともお待ちしています。
メールアドレスはrecalog-gmail.comになります。
touden
ツイッターもやっていますのでフォローやダイレクトメッセージもお待ちしています。
本番組はpodcast.spotify.youtubeで聞くことができます。
そちらでもサブスクライブよろしくお願いいたします。
はいではお疲れ様でした。
kokorokagami
はいお疲れ様でした。
