Enjoy＜(。ε゜)＞ appcompat_v7は増え続ける

一ヶ月ぶりじゃねーかうわあああ
スイヤヘェェン！

KitKatが出始めた時から出てきた開発上の問題で死にかけたので忘備します。

4.4対応のAndroidプロジェクトを作ってると、勝手にappcompat_v7_3みたいなプロジェクト
がガンガン作られていく。

その時の対策を「appcompat_v7 エラー」とやらでぐぐってみると、やっぱり同じことで苦しめられている人が何人かいる。その中の一番手軽な内容を手順的に書いておく。

ただこの方法で留意することは、最初にでてきたappcompat_v7は消してはいけないということ。
今回の方法ではこのappcompat_v7を使いまわしていくからだ。

1. 4.4対応のプロジェクトを2回目以降に作ると、忌まわしきappcompat_v7_*が出てくる。
2. appcompat_v7_*を削除する。僕は「パッケージマネージャー　→　appcompat_v7_*プロジェクト右クリック　→　削除をクリック　→　ディスクから削除にチェックを入れて削除」をした。
3. 自分が作ったプロジェクトがエラー祭りになる。これはappcompat_v7_*が削除されることで中にあったパッケージをインクルードできなくなったから。
4. エラー祭りのプロジェクトをパッケージマネージャで選択し、右クリックメニューからプロパティを選択する。
5. 右のリストからAndroidを選択して、下の方にあるライブラリを見る。するとこのプロジェクトがappcompat_v7_*をインクルード使用としてることがわかると思う。
6. appcompat_v7_*を選択し、削除をクリック。
7. Addをクリックして、appcompat_v7を選択。
8. エラーがなくなったよ！やったねたえちゃん！

画像はめんどかった。ごめん。

ただ、これでちゃんとコンパイルが通るはず。

よいよい本の紹介

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

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

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

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

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

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

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

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

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

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

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

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

アジャイル開発

　某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

© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。 

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

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

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

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

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

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

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

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

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


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

初めてのおわすれ対策

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

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

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

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

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