以下の文章は Markdown として記述しています．
視認性が悪い場合は https://sksat.net/misc/seccamp2024-entry.html を見てください（同じもののレンダリング結果を掲載します）．

# 探査機自作ゼミ 応募課題

## はじめに・評価について

この応募課題は，あなたに考えてもらい，講師があなたのことを知るためのものです．

明確な答えの無い設問となっているため，分からないと思っても，何をどう調べ，どう考えたかを途中まででもぜひ書いてみてください．

- 評価は加点方式で行います．
  - あなたが考えた道筋やあなたの熱意を重視します．
  - 不正確なことを書いても減点するようなことはしません．
- 文字数の制限はありません．
  - 回答の長さによって評価が有利になることはありません．
- 一部の設問には発展課題を付けています．
  - 発展課題の回答はあくまで任意です．無理に回答するよりは，それ以外の回答を丁寧に考えて書いてもらうことに価値があります．
  - 発展課題の回答は元の課題と混ぜて書いても分けて書いても構いません．
- 回答を考えるにあたって，Web で情報収集をしたり，ChatGPT のような LLM を用いても構いません．
  - 適宜出典や引用元は明記してください．
  - LLM などへの入力（プロンプト）を回答に含めても，含めなくても構いません．
- 回答に擬似コードやソースコードを含めても構いません．
  - 実装のポイントや意図が分かるコメントがあると助かります．


## Q1
あなたが今までに作ったことのあるものを自由に語ってください。複数人で作った場合は、どの部分をどう担当したのかを明示してください。それがソフトウェアないしソフトウェアを含むものであれば，どのような言語・ライブラリを使ったかも教えてください．作ったものが公開リポジトリなどにある場合は，そのリンクも書いてもらえるとうれしいです．


## Q2
Q1 で作ったものを作る前や作る最中，作った後にあなたが感じた壁のうち，特に印象に残っているものを教えてください．あなたはその壁をどう調査し，克服しようとしましたか？具体的に教えてください．壁が克服できなかった場合は，何が不足していたと思われるか，今やり直すならどうするかなどの考えを聞かせてください．


## Q3
あなたの印象に残っている「これは便利だ」と感じたものを教えてください．工具でも，エディタやその拡張機能のようなソフトウェアでも，5回のクリックを1回にするショートカットでも，なんでも構いません．また，それはなぜ便利だったのでしょうか．つまり，どのような課題があり，どう解決しているのでしょうか．

### Q3.1（発展課題）
どのようにすれば，そのような便利なものを自分で開発できるか考えてみましょう．

もし既に自分が作った便利なものがあれば，そのエピソードも教えてください．


## Q4
宇宙開発においては，「枯れた技術」と形容されるような，比較的古めの技術が使われることが多いです．特に情報技術においては一般的なIT業界と比較して10年，20年程度の開きがあることも珍しくありません．例えば，C89 や XML が幅を効かせていることはよくあり，PIC や SHマイコン，PowerPC，SPARC も現役です．

これはなぜでしょうか？そして，この方針にはどのようなメリット・デメリットがあるでしょうか？
ソフトウェア以外とソフトウェアの両方の面について，それぞれ論じてください．

### Q4.1（発展課題）
ちなみに，講師の sksat はかなり新しいエコシステムである Rust を実際に仕事の衛星開発で使っており，講義でも Rust を使用する予定です．つまり，前述の「枯れた技術」に対して，少なくともソフトウェア開発の観点ではどちらかというと否定的な立場なわけですが，これに意見があれば自由に述べてください．

ヒント：意見は賛成でも反対でも「それでは足りない」のようなものでも構いません．sksat と意見が異なっても減点するようなことはありません．意見がすれ違うのは当然のことです．ぜひ語り合いましょう！


### Q5
宇宙機はロケットという輸送手段で地上から宇宙に輸送され，軌道にデプロイされます．一度デプロイされた宇宙機は，原則として物理的に修理することができません．なぜなら，宇宙に出張に行って機体に近づいて蓋を開けることができないからです．そこに行って蓋を開けられないということは，ノートPCを持っていってデバッガをアタッチし，ソフトウェアを書き換えることもできません．これが非修理系です．

これは非常に不便な特性です．打ち上げて運用を開始してからバグが見つかったらどうしましょう？そのバグは姿勢制御系の秘孔を突いて高速回転を発生させ，遠心力で機体が破壊されてしまうような致命的なものかもしれません．

また，バグでなくとも，途中から要求が変わるかもしれません．例えば気象目的の人工衛星で，特定の種類の雲を衛星上で認識するミッションがあるとします．これは問題なく動作していたのですが，運用開始後，また別の種類の雲を衛星画像から判定するアルゴリズムの研究が発表されました．これを即座に軌道上の衛星に組み込めると非常に価値があります．

このような問題に対して，どのような技術的解決が考えられるでしょうか？また，どのように宇宙機やそのソフトウェア，送信するコマンド群などの運用計画を設計しておけば，運用時に後から発生する問題に対して対処しやすくなるでしょうか？自由に提案してみてください．

ヒント：漠然としていて考えにくい場合は，宇宙機を普通のLinuxサーバだと仮定してみるとよいでしょう．ただし，物理筐体を直接操作することはできず，通信機会が1回数分で1日に1回程度の不便なサーバです．インターネットにも繋がっていません．このような制限は適宜調べたり，想像してみたりしてください．