卒論/プチ論/研究発表の原稿見本

このリポジトリは研究発表のための書式見本として提供する。

事前準備

GitBucket にSSH鍵を登録し、
ssh-agent で自由にログインできるように設定しておくこと。
httpsは毎回パスワードを打たねばならず効率低下を招く。
やり方が分からなかったら必ず分かる人に聞くこと。分かる人に聞いたら
誰かにすぐ教えること。

使い方

新規リポジトリを作ってそこにpushする。

% git clone ssh://git@www.yatex.org:29418/yuuji/2019-Template.git
% cd 2019-Template
% git remote add origin ssh://git@www.yatex.org:29418/yuuji/2019-自分のリポジトリ.git
% git push -u origin master

あるいは、このリポジトリをcloneして出てきたファイルなどの
ディレクトリ構成を真似て自分のリポジトリに add していく。

内容物

ディレクトリごとの内容を示す。
自分が取り組む論文も、ディレクトリごとに整理して格納する。

取り組むときの心構え

大学生の研究は慌てて2、3週間で終わる程ユルくない。
取り組むまでの基本知識の獲得ができていると仮定した場合でも目安として、
自分なりの提案とその構築のための技術獲得(卒論スタート50項目等)に100時間、
そこから新しい提案をするための調査(論文探しなど)に20時間、
システム構築(プログラムや仮説の作成)に100から200時間、
検証に50時間、論文へのまとめ上げに50時間、修正に20時間、
リハーサルや印刷作業に10時間程度は必要である(プチ論はこの半分程度)。

目の前の問題に総合的にすくなくとも300時間程度は取り組まなければなしえな
い課題であることを早期に認識し、計画的に時間を割いて取り組むこと。
アルバイトなどを除いて平日に何時間確保できるか考え、
全く余裕がないことに気付かなければならない。
300時間を年末ぎりぎりに持ち越すので、徹夜を毎日して不満足な結果を
残す者が出てくるのは見ていて哀れである。

Milestones/Issues/Kanbanによる自己進捗管理について

カンバン方式

GitHub(とその互換のGitBucket等)には、作成物が抱えている課題と
それらをいつまでに区切りをつけるかの期限(マイルストン)を管理する機能がある。
Kanban(カンバン)はトヨタが採用していたプロジェクト有名なプロジェクト推進手法で
トヨタが世界的企業になるにつれ「カンバン方式」は英語にも浸透した。

1. リポジトリホームの左メニュー「Milestones」で、自分なりの区切りとなる
   日時をいくつか設定する(週に1、2個程度)。これを繰り返しいくつかマイル
   ストンを設定する。
2. 左メニュー「Kanban」を開き右上「Add lane」ボタンを押し、
   「Doing」と「Done」をそれぞれ追加する。
3. 以後、目の前の問題を細分化した問題をできるだけ多くに分割したのち、
   左メニュー「Issued」で「Create a new issue」を選び、おおまかな
   締切を「Milestone」に設定する。

締切が守れなかった場合に決して自分を責めず、「なぜその見通しが外れたか」
を考え、次に活かす。

Issues管理

修正/改良すべき点は自分、若しくは他者からコメントとして Issues に書く。
疑問なども Issues に書く。
その課題が解決したときは、コミットするときのコミットメッセージに

hoge hoge hoge hoge (fixes #123)

のように「Fixes #番号」を沿えて書くと自動的にIssuesが解決済みにされる。

リポジトリ運用時の注意

Emacs(その他エディタ)でコミット/pushできる操作を覚える

SSH鍵でリポジトリに繋げるようにし、ssh-agentで鍵を覚えさせる。
その上で起動したEmacsではパスフレーズなしでpushまでできる。
その他の操作についてもキーボードショートカットでできるようにする。
s4#22968
参照。

不要なファイルをリポジトリに登録しない

自分が手で作成したファイルのみをリポジトリに add する。
作成したファイルから自動的に生成されたもの、たとえばLaTeX変換時に
できる.logファイルなどや画像をリサイズして得られた中間ファイル、
OS X 独自の .DS_* ディレクトリなどは入れない。そのために
.gitignore ファイルにそのファイルのパターンを追加しておく。
大きなゴミファイルを一度でもリポジトリに登録するとずっと履歴が残り
その後に影響する。

小さな単位でコミットする

慣れるまでは、できるだけ意味のある変更をしたらコミットする。
たとえばプログラムのエラーが出なくなったとき、文章の1段落を書き終わったとき、
など一息つくタイミングでコミットする。
pushはコミットがまとまったタイミングでよい。

コミットログを正しい文句にする

できれば英語で書く。どうしてもだめなら日本語でよいが1行で完結する
文にする。書く内容は どのような意図でどう変えたか を書く。
どのファイルを変えたかは履歴に残るのでそれを書いてもしょうがない。
英語で書く場合は

• 命令文形式
• 受動態のbe動詞抜き
  で書く。たとえば、「リセットするためのボタンを足した」であれば、

Add a button to reset values

あるいは "Button to reset values is added" のbe動詞を抜いた

Button to reset values added

とする。

間違ってもよいので、単文を考えることを繰り返すと、
意外に早く技術英文は書けるようになる。やらないとまったく上達しない。

こまめに文章化する

論文本体はタイトルだけでもすぐに埋めること。目次も作ること。

頭の中で考えているだけのことは 絶対に全くあとで役に立たない ので
必ず文章化する。文章化したものは必ず決まった場所に書く。
そうすることで、論文本体を書くとき、過去の自分の仕事に相当救われる。