アカウント名:
パスワード:
有人宇宙飛行はできませんね。こんな簡単なバグをつぶせないようでは。いっそのこと、プログラムは公開して、バグ発見者には宇宙飛行ご招待すれば。私は、辞退します。
この知見が「はやぶさ２」に活かせれば良いのです。そのための工学試験衛星なんですから。
次は岩石取得方法を多重冗長化できないものでしょうかね。今回うまくいかなかったシステムを修正するほかに何か別の方法も。ガムテープ飛ばして引きずり回して引き戻して格納すればいいんじゃないの、といっている人もいましたが。
http://www.itmedia.co.jp/news/articles/1011/16/news083.html [itmedia.co.jp]
エアロゲルなどを使わない、コンタミ（汚染）のない状態の回収もはやぶさが初めて
とのことなので、粘着剤を使わない方式に意義はあるのでしょう。
あと、原因がソフトウェアの問題だったということは、採取用のハードウェアを冗長化してどうにかなる問題ではないってことだと思います。冗長性という点なら、さきがけ [wikipedia.org]・すいせい [wikipedia.org]みたいに探査機を２機打ち上げて別々に運用するのが理想なのかもしれませんが…
ソフトウェアを多重化しよう↓待機系のソフトを別のベンダに開発させる↓結合試験で微妙な「挙動の違い」が発見される↓どちらかに合わせて修正↓…元の木阿弥?
# いやこれが起きたとしても意味はもちろんあるんですけどね…
トリモチ方式については、1. 宇宙空間で粘着力を長期間維持することが困難。2. ターゲット表面の物質が必ずしもトリモチにくっつくとは限らない。3. トリモチからサンプルを取り外すことが困難。という話を聞いたことがあります。
また、高温になる小惑星表面にとどまる時間を最小限にする(=ごく短時間でサンプルを採取する)という点でも、現行の方式が優れているようです。
「はやぶさ2」においても現行方式の改善版で望む方針のようですので、それなりに自信のある方法なのではないでしょうか(以下、PDF注意)。http://www.mext.go.jp/component/b_menu/shingi/toushin/__icsFiles/afiel... [mext.go.jp]
「プログラムミス」については、こちらにもあるように運用の中でソフトウェアを更新することもあったようなので、その中で発生したミスなのかもしれませんね（全くの憶測ですが）。http://www.nec.co.jp/ad/hayabusa/story/04/ [nec.co.jp]
宇宙空間で変質しないガムテープを発明できたらノーベル賞もらえますよ。あるいはその特許をNASAが買い取ってくれるかもね。
== と != を間違えるようなのをいまさら試験しなくてもいいように思いますがｗ
#なんでも“ベータ版”で済ますのはよくないよね#バグバグの免罪符にはならないし
ソフトウェア上のバグの知見というのは、どういう形で一般化し継承されるのでしょうか。ハードウェア上の不具合については、知見としてデータベース化しやすいと思いますが。
例えば今回のバグは、どんな知見として蓄積され、今後の同様のプロジェクトの成功率を上げるために役立つのでしょうか。
物事は具象的にだけでなく抽象的にも捉えないとな。てか、一般化するなら抽象化するのは当然だが。
例えば「セーフティが働いて何かが中止になった時はassertっぽくソースコード中の位置をメッセージに含める」とか。問題発生から原因解明までの時間を短縮できるから時間切れまでに修正できる可能性が高くなるだろ？コードサイズ気にするならメッセージにはソースラインコードを出力させて、ビルド時に作る対応表牽くようにすればいい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
あと百年は (スコア:-1, 荒らし)
有人宇宙飛行はできませんね。
こんな簡単なバグをつぶせないようでは。
いっそのこと、プログラムは公開して、バグ発見者には宇宙飛行ご招待すれば。
私は、辞退します。
次につながる (スコア:2)
この知見が「はやぶさ２」に活かせれば良いのです。
そのための工学試験衛星なんですから。
And now for something completely different...
Re: (スコア:0)
次は岩石取得方法を多重冗長化できないものでしょうかね。
今回うまくいかなかったシステムを修正するほかに何か別の方法も。
ガムテープ飛ばして引きずり回して引き戻して格納すればいいんじゃないの、といっている人もいましたが。
Re:次につながる (スコア:2, 興味深い)
http://www.itmedia.co.jp/news/articles/1011/16/news083.html [itmedia.co.jp]
エアロゲルなどを使わない、コンタミ（汚染）のない状態の回収もはやぶさが初めて
とのことなので、粘着剤を使わない方式に意義はあるのでしょう。
あと、原因がソフトウェアの問題だったということは、採取用のハードウェアを冗長化してどうにかなる問題ではないってことだと思います。
冗長性という点なら、さきがけ [wikipedia.org]・すいせい [wikipedia.org]みたいに探査機を２機打ち上げて別々に運用するのが理想なのかもしれませんが…
Re: (スコア:0)
障害で待機系に切り換えたら、そこでも同じ障害が発生・・・原因はソフトウェアなんてのは、ありがちな話のはずなのに。
Re:次につながる (スコア:1, 興味深い)
ソフトウェアを多重化しよう
↓
待機系のソフトを別のベンダに開発させる
↓
結合試験で微妙な「挙動の違い」が発見される
↓
どちらかに合わせて修正
↓
…元の木阿弥?
# いやこれが起きたとしても意味はもちろんあるんですけどね…
Re:次につながる (スコア:2, 参考になる)
トリモチ方式については、
1. 宇宙空間で粘着力を長期間維持することが困難。
2. ターゲット表面の物質が必ずしもトリモチにくっつくとは限らない。
3. トリモチからサンプルを取り外すことが困難。
という話を聞いたことがあります。
また、高温になる小惑星表面にとどまる時間を最小限にする(=ごく短時間でサンプルを採取する)という点でも、現行の方式が優れているようです。
「はやぶさ2」においても現行方式の改善版で望む方針のようですので、それなりに自信のある方法なのではないでしょうか(以下、PDF注意)。
http://www.mext.go.jp/component/b_menu/shingi/toushin/__icsFiles/afiel... [mext.go.jp]
「プログラムミス」については、こちらにもあるように運用の中でソフトウェアを更新することもあったようなので、その中で発生したミスなのかもしれませんね（全くの憶測ですが）。
http://www.nec.co.jp/ad/hayabusa/story/04/ [nec.co.jp]
Re:次につながる (スコア:1)
次のターゲットとなる小惑星の表面がどんな固さか、とかは近づいてみないと分からないところが難しいところですよね。
イトカワも、行ってびっくりレゴリスだらけ [www.jaxa.jp]という感じでしたし。
ガムテープが岩に張り付いて、はやぶさ２が引っ張られてビターンッとぶつかるところを妄想。
Re: (スコア:0)
宇宙空間で変質しないガムテープを発明できたらノーベル賞もらえますよ。
あるいはその特許をNASAが買い取ってくれるかもね。
Re: (スコア:0)
Re: (スコア:0)
なにせリアクションホイールの機数も切り詰めたくらいですから。
また粘着材を使用しなかったのは、できれば表面に積もった粒子ではなく、
破片が欲しかったということもあると思われます。
Re: (スコア:0)
== と != を間違えるようなのをいまさら試験しなくてもいいように思いますがｗ
#なんでも“ベータ版”で済ますのはよくないよね
#バグバグの免罪符にはならないし
Re: (スコア:0)
ソフトウェア上のバグの知見というのは、どういう形で一般化し継承されるのでしょうか。
ハードウェア上の不具合については、知見としてデータベース化しやすいと思いますが。
例えば今回のバグは、どんな知見として蓄積され、今後の同様のプロジェクトの成功率を
上げるために役立つのでしょうか。
Re:次につながる (スコア:1)
物事は具象的にだけでなく抽象的にも捉えないとな。
てか、一般化するなら抽象化するのは当然だが。
例えば「セーフティが働いて何かが中止になった時はassertっぽくソースコード中の位置をメッセージに含める」とか。
問題発生から原因解明までの時間を短縮できるから時間切れまでに修正できる可能性が高くなるだろ？
コードサイズ気にするならメッセージにはソースラインコードを出力させて、ビルド時に作る対応表牽くようにすればいい。