2014年8月10日日曜日

よいよい本の紹介

　今日某所のアトレにある書店でいい本を見つけたんすよ。ええ。

　「15時間でわかるGit」っていう本なんだけど、自分が読んだGit本の中で一番わかり易い本だと思う。他のGit本を否定する気は無いんだけど、正直な話発展的な話題が多すぎるせいで導入の妨げになっている感じがあるんだよね。

　一方、上で言っていた本は凄くシンプルでわかりやすいなぁとおもったのです。なんというか文章が簡潔だったり写真が多かったり、ぶっちゃけ「やさしいC」みたいな雰囲気があって大変良い。だから正直な話、このブログを書きながらポチったわけですよ。はい

2014年8月4日月曜日

なんとなく思った事：「授業というツール」について

課題、レポート、テスト、平常授業、実習…

　まぁ高専で色々と体験した事は大量に有るんだけど、その体験って基本的に「学校のカリキュラム」で組まれたものばかりなんだよね。

　実際、課題やレポートを解く、書く力って社会でも凄く重要になるんだけど、なんというか「重要なこと成分」を凝縮しすぎた印象を感じる。特にテスト前は一層強くそんな印象を受ける。

　ぶっちゃけた話スキル向上のためにある「授業というツール」に使われている感じで正直キツイところがある。2年時の「emacs使えなくてプログラミング出来ないよー」みたいなそんな感じに近いなぁ。(今はemacsが手放せないけどね！)

　道具に使われるのは本当に非効率だし、最悪慣れるだけの労力で作業が終了するパターンだってあるから、とてもよろしくない。悪化するとモチベ下がって堕落の道へ行くかなと。

　逆に成績がいい人は、多分「授業というツール」を使いこなしている方なんだよね。もっと極端な話、教員に質問バンバンする人は教員をツールとしてバリバリ扱える人だとおもうのよ（教員の人格否定をしているわけではありません。ご了承ください）。実際にそういう人は尊敬出来るし、見習いたい。

　まぁぶっちゃけ今回の話の結論は、「授業というツールに使われないようにしないとね！」という感じ。もっと言うと「授業というツールを使いこなしてやろうね！」っていう所。まぁアバウトすぎる結論で、「じゃあどうすりゃいいのさ」って話だけど、授業によってやることなす事は変わるからなんとも言えないなぁ。基本的には「分からないなら質問する」、「分からないことを明確にするために勉強する」みたいな所かなぁ

散々言っておいてクッソ意識高すぎんぞこれ。コミュ症な自分にはとっても難しい話だ。うー

2014年8月2日土曜日

アジャイル開発

　某DB授業でグループ作業をするんだけど、そのグループ作業の方法とかそこら辺が把握できていないと色々と死にそうだから書いておく。

　アジャイル開発にはXP、RUP、スクラム…etcと色々とあるらしいけど、アジャイル開発全体の目的は「コミュニケーションコスト増大のリスクを避ける」ってことなんだよね。まぁぶっちゃけなにができて欲しいかっていうと

[8/2投稿直後に訂正]
すっげー誤解。つーか手書きメモに書いていた内容が死んでてマジ大草原。

アジャイル開発全体の目的って決定してた。「アジャイルソフトウェア開発宣言(価値)」ってググってくれれば幸せになれると思う。お言葉に甘えて http://agilemanifesto.org/iso/ja/ からコピペ

------------------------以下コピペ------------------------

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler

James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick

Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

------------------------以上コピペ------------------------

原文は上記URLで見ると凄く良いと思う。まぁつまり、

・メンバー間の意思疎通
・問題の全部理解
・動くブツ作って

って事らしい。僕の理解も相当浅いってはっきりわかんだね。

　アジャイル開発の特徴として「1つの開発サイクルを小さくする(1サイクルの要求が小さい)」ってのがあるけど、その理由がやっぱり上記リストアップとか上記宣言に行き着くのかなぁ…。

ちなみに「1つの開発サイクルが小さい」ってのは、「一発でブツを作るなタコ！」ってことなんだよね。ウォーターフォール開発プロセスと比較すると

[ウォーターフォール]
要求分析→設計→実装→テスト(ブツ一部のテスト)→結合（ブツ全体のテスト）

[アジャイル]
要求分析→設計→実装→結合→
→要求分析→設計→実装→結合→
→要求分析→設計→実装→結合→
…→全体テスト

みたいな。一スパンに作ってるものが小さいのがアジャイル開発ってそれいちばん言われてることだから。

こんなこと書いてて分かったけど開発プロセスについて全然わかってねーなと痛感。なんじゃこりゃー

初めてのおわすれ対策

研究とかプログラミングとか、とにかく最近忘れ事がおおいのよね。
正直な話キツイっすー(´・ω・`)

あと理解が浅かったり違ったり、その手の問題には割りと速く気づきたいっていう目的もあったりするんだけど、やっぱり前者の方が強いかなぁ。

まぁ理由は色々とあるけど、後々の自分のスキル向上(?)もふまえて忘備録ブログをつけようと思う。(｀･ω･´)

　内容は並列処理クラスタ(主にベオウルフシステム)関連、C/C++みたいな手続き形言語関連、QtみたいなGUIライブラリ関連と割と広く浅くみたいな感じになるかなぁ…

というわけで、3日坊主にならないように頑張ろうとおもいまひ