大規模ソフトウェアを手探る
田浦健次朗
(the page is encoded in UTF-8)
What's New
括弧内は投稿日. 新しいものを上に書き足します.
(過去ログ),
(過去レポ)
- (投稿日 2024/10/06)
2024年度版ホームページ開設
スライド・資料
- テキスト
- 説明スライド
- 課題設定ヒント
- 日々の進め方ヒント
-
進捗の書き方:
「同じことを他の人がもう一度やるのに役に立つ情報」を
書くことを推奨します. 例えばビルドにしても, 日本語でこうしたああした,
というレベルの情報ではなく, 打ち込んだコマンドラインを
そのまま残す(貼り付ける)のが推奨. 特に,
公式サイトの指示では上手く行かなったような場合, 代わりにどうした,
ということを「他の人はそれをコピペすればいい」
レベルでそのまま書いておくことがよいです.
- 他のメンバーの役に立つ
- 後輩の役にも立つ
- トラブル発生時に他の人が介入・ヘルプするのにも役に立つ
(重要)
-
トラブル報告の仕方:
同じ理由で, トラブルに遭遇しているときも「やったことをありのまま書く」
というのが大事です. 特に他の人に見てもらう場合,
「ビルドしたけど◯◯がないとか言って上手く行きませんでしたがどうすればいいですか?」ではなく, 打ち込んだコマンドラインとシステムの出力, エラーメッセージなどをそのままベタッと(修正なく)貼り付けるのが重要です.
これはこの授業だけでなくオンラインコミュニティにヘルプを求める際にも重要な作法です. 「読んだ人が同じ現象を再現できるため」の情報, それも「最短時間で」再現できる(相手の時間を節約する)情報が重要で, それはすなわち, コピペすればいいだけのコマンドラインと, 起きることが同じかどうかを確かめられる出力,
ということになります.
-
トラブルも進捗:
「こうやったけどこんなエラーになって困っている」というのも
進捗です. 進捗報告に残したり,
最後のミニ発表でそれを見せるようにしましょう.
有用なヘルプをもらえる可能性が高まります.
色んな情報・ヒント
- 参考スライド・ページ
- もろもろのtips集
- GDB中級編
-
GDBマニュアル.
同じものはinfoコマンドやEmacsのM-x infoでも閲覧可能.
infoのメニューにGDBが現れない場合,
apt-getでgdb-docをインストールする
-
Google Summer of Code
の
プロジェクト集.
興味があれば
参戦記も
- JavaScript Engine (SpiderMonkey) 関連
(2016年, SpiderMonkeyの開発者である藤澤氏がTAをやっていた時に,
関連して提供した情報. 関係者と近くで相談が出来るため,
SpiderMonkey課題へ取り組むことを推奨したが今でもオンラインでの
相談はきっと可能)
コンタクト
授業時間以外の質問等の送り先: doss アットマーク eidos.ic.i.u-tokyo.ac.jp
はじめに
この演習では,世の中で実際に使われている大きな
ソフトウェアを変更,機能拡張することを目標にする.
テーマは,
「全容を把握できるわけがない程大きなソフトウェ
アをいかに扱い,必要な動作を理解し,変更す
るか」
ということである.
この課題を作った理由
多くの大学の情報系学科
の演習・実験は,小さな(たまに中規模程度の)ソフ
トウェアを一から書くというものである.しかし大
きなソフトウェアは,全てを自分で書くことは稀で
あるし,一人で書く場合も,どこかで誰かが書いた,
すでに存在するソフトウェアを元にして拡張・修正
を重ねていくことがほとんどである.この先研究でソフト
を実現する場合も一から全てを作るより,既存のソ
フトウェアを元にして拡張することが多い.一から
作る場合でも,やがれそれが大きくなっても大丈夫な,
他の人でもいじれるソフトを作らなくてはならない.
それらができるためには,小さなソフトウェアを一から書く
のでは身につかない,「全容がわからないながらも
関係ありそうな部分を探り,修正する方法」を習得
する必要がある.また,世の中の人が大きなソフトウェアを書くときに
常識的に使っている流儀やツールにも習熟する必要がある.
それらはあまり体系立てて説明でき
ないノウハウや知識の寄せ集めが7割を占めるのか
もしれない.そうであるがゆえに大学の授業や演習
で正面切って扱われることは稀で,この演習ではそ
れをあえて行って,大学の普通の演習レベルと本格的ソフ
トウェア開発のギャップを埋めることを試みるのが,
この演習である.
進め方
チーム
まずは2-3人で一つのチームを作る
基本練習
最初は,多くの
ソフトウェアが踏襲するビルド方式(configure,
make),デバッガを使いこなして未知のソフトの動
きを追いかける方法など,基本ノウハウを説明し,
実践する.
共通課題
次に,ポピュラーであるが比較的単純なソフトウェア(例:
gnuplot; 10万行程度)を対象に,共通課題を設定し
てその動作の解析と変更を試みる.ソフトウェアを,
デバッグ可能状態でビルドする,デバッガでステップ実行する,
必要なところで止める,などの機能を正しく,効率的に駆使して,
「変更したい動作と関連するコード」に到達する練習をする.
自由課題
残り時間は各チー
ムで対象ソフトウェアと目標を設定して取り組む.
対象ソフトウェアの分野は限定しないが,世の中で
広く使われている,ポピュラーなプロジェクトを対
象にすることを推奨する.例:
- 言語処理系: gcc, LLVM, Python, JavaScript, etc.
- データベース: sqlite, Maria DB, etc.
- OS: Linux, FreeBSD
- オフィス系: gnumeric, inkscape, etc.
- ...
など.ただし,ビルドするだけで一晩かかってしまうようなソフトは,
やり方を工夫しないと難しいかもしれない.
達成目標
- 少なく教わり,大きく学ぶ
- 大きなソフトウェアと格闘できるようになるということ
- 大きなソフトウェアの書かれ方を感じる
- よく使われるソフトウェア設計のパターン
(拡張のためのインタフェースやマクロ言語など)を知る
- ソフトの中身を知ろうにも座学で習う,
OS, データベース,言語処理系,etc.の理屈がわからないと,
手出しが出来ないこともあるかもしれない.わからないなりに格闘する
根性(オンデマンドに学ぶ姿勢)と,それらの座学を聞く際の
モチベーションアップ
その他のご利益
- ソースを追いかけることで,
普段使っているソフトの知らなかった機能を知る
- エディタやデバッガなど普段使っているはずの道具も,
作業を効率的にするための投資をし,より高度に使いこなす
- ソフトウェア構築や問題追求のための色々な道具を知る
(valgrind)
過去レポ集
過去のお知らせログ
- 2021/10/4:
自己紹介用Google spreadsheetの共有を飛ばしているので,
Google Drive から見てください. Gmail (@g.ecc.u-tokyo.ac.jp) が行っていると思われる.
- 細かいお知らせや質問, 学生間の情報共有のためにSlackを使います.
参加は強制ではないですが相談用に便利なので是非.
チャンネル名は 2022a-大規模ソフトウェアを手探る.
参加方法
- 2021/10/2:
ITC-LMS 後期実験コースページ
- 2021/10/2:
2021年版ホームページ開設
2020年度
2019年度
- レポートその他の提出手続き
に従って最終提出物を提出してください.
-
2019プロジェクト一覧
(遅ればせながら直リンを作った. 中身はおなじみのページ)
- 2019/10/8:
参考: uftraceが上手く行かないときの代わりになるかもしれないツール
libitrace
- 2019/10/2:
進捗の書き方:
「同じことを他の人がもう一度やるのに役に立つ情報」を
書くことを推奨します. 例えばビルドにしても, 日本語でこうしたああした,
というレベルの情報ではなく, 打ち込んだコマンドラインを
そのまま残す(貼り付ける)のが推奨. 特に,
公式サイトの指示では上手く行かなったような場合, 代わりにどうした,
ということを「他の人はそれをコピペすればいい」
レベルでそのまま書いておくことがよいです.
- 他のメンバーの役に立つ
- 後輩の役にも立つ
- トラブル発生時に他の人が介入・ヘルプするのにも役に立つ
(重要)
- 2019/10/2:
トラブル報告の仕方:
同じ理由で, トラブルに遭遇しているときも「やったことをありのまま書く」
というのが大事です. 特に他の人に見てもらう場合,
「ビルドしたけど◯◯がないとか言って上手く行きませんでしたがどうすればいいですか?」ではなく, 打ち込んだコマンドラインとシステムの出力, エラーメッセージなどをそのままベタッと(修正なく)貼り付けるのが重要です.
これはこの授業だけでなくオンラインコミュニティにヘルプを求める際にも重要な作法です. 「読んだ人が同じ現象を再現できるため」の情報, それも「最短時間で」再現できる(相手の時間を節約する)情報が重要で, それはすなわち, コピペすればいいだけのコマンドラインと, 起きることが同じかどうかを確かめられる出力,
ということになります.
- 2019/10/2:
トラブルも進捗:
「こうやったけどこんなエラーになって困っている」というのも
進捗です. 進捗報告に残したり,
最後のミニ発表でそれを見せるようにしましょう.
有用なヘルプをもらえる可能性が高まります.
- 2019/9/25:
初回アンケート
に答えてください
- 2019/9/25:
2019年版ホームページ開設
2018年度
- お疲れ様でした.
レポートその他の提出手続き
のページを更新しました(再読込してください)
- 10/2 の終了状態
- gitlabになんかプロジェクト追加
- そこに基本情報を書く
- チーム名(決まり次第)
- メンバー全員の実名
- 進捗ログ(googledocsなど,
読めれば形式は自由)へのポインタ.
プロジェクトに .md ファイルの追加とか
でも良い
- ログに作業日記を残す習慣を始める
- Slackを見れるようになっとく
2017年度第二期用
2017年度第一期
2016年度第二期
2016年度第一期
2015年度第二期
2015年度第一期