outputがないとinputできない
仕事でも勉強でも、日々何かをinput ∈ {調べる, 勉強する, 調査する, 聞いてみる, まとめる, やってみる} しないといけないケースが多い。今は学生なので日々やってることの9割はinputである。
ただ、他の人はどうかは知らないが、自分にはoutputのイメージがないとinputが続かないという問題がある。outputのイメージがないと途中で迷走してやる気がなくなってやめてしまったりすることが多い。
例えば「とりあえずScala勉強してみよう」みたいなのがすごく苦手で、具体的な成果として何をoutputするかが決まってないと続かない。例えば「とりあえずPlay Frameworkのチュートリアルやる」みたいなのがすごく苦手で、大抵途中で飽きてしまう。「今度Play使ったプロダクトの開発するからPlayチュートリアルやってCRUD一式を持つweb appを自分で作って概要を知る」とか、「こういう設計をしたいけど分からないので類似プロダクトのコードを読んで設計を理解して自分のプロダクトに反映させる」みたいな感じでないと続かないタイプである。
なので何も考えずに勉強するだけ、というのもすごく苦手である。そのため、今取ってる講義は全部何らかの応用目的があるものだけに絞っている。とりあえず直近で使わないものは全部「競プロに使えそう」ぐらいなのだが、それでも「ただ単位のため」という目的しかないよりは遥かにマシである。
ささやかでもoutputしながらinputする
自分が普段採用しているスタイルはこれである。*1 以下は研究室で使っているpukiwikiに自分が調べたことをまとめているページである。 基本的に備忘録としてoutputしている感じだが、それ以外にも研究室の定例ミーティングで進捗を報告するときに「XXXについて調べました」というような報告をするときに、当該ページのURLを貼って報告する、という使い方をしている。
あと今気づいたがMPIとかBLASみたいな、個別の研究に影響しない一般的な内容についてはあとで編集しなおしてQiita辺りに投稿してもいいかもしれない。
同様に論文も要約を書きながら読んでいる。
論文をまとめるフォーマットはいろいろあるのだが、とりあえず自分の場合は以下のようにまとめている。
- 3行でまとめると
- この論文が批判していること
- この論文の貢献
- 以下要旨（ここはフォーマット決めてない）
*1:もちろん具体的なソフトウェアを書くことがoutputの場合もあるが、直近だと具体的なブツが公開できてないので今回は説明を割愛。
