ワシの作業効率を劇的にアップするツールたち！
このへんを参考に乗るっきゃ無い！このビッグウェーブに！自分の作業環境ってどうだっけかー？を出してみようかと。
ツールの分類すらマネしちゃうからねっ！ （ちなみに仕事のPCがWindowsなのでWindowsの話です）
ランチャー
デスクトップを便利にカスタマイズできるソフト
ウィジェット系かな。。。何も使ってないっす。。。
キーボードを使いやすくするキーリマップ
- regedit
- capslockをctrlに差し替えてます
ファイルやフォルダの管理に便利なファイラーソフト
昔はMDIEみたいなタブ型の使ってたんですけど、だんだん使わなくなってしまった。「タブを開いておく」事を「ToDoのかわり」チックに使ってたので、管理の方法が変わった、っつう感じかも。
まで書いてから参考サイトを読んだけど、あふがかぶってるのに驚き！
複数デバイス間での高速ファイル転送ソフト
あー、こういうの使ってないっすねぇ。firefilecopyみたいなやつ、かな？
マインドマップソフト
- FreeMind
インストールレギュレーションの関係上直接jarを叩いてます
エディタソフト
そろそろemacsも触れるくらいには。。。
ブラウザ履歴管理ソフト
へーこういうのを使ったりするのね〜
画像管理やリサイズの効率向上に役立つソフト
そんなに画像を編集するシーンが無い。。
編集も可能な画像ビューアーソフト
ん〜。これも仕事では使うシーンがないなぁ。。
多機能なスクリーンショットソフト
- Snipping Tool
- Print Screenキー
後者はソフトではないか。。。
ファイルを管理しやすくなるソフト
んー難しい。
ブラウザ
後者はまれーー、に。
音楽ファイル管理ソフト
仕事じゃぁ使わないなぁ。。。
まとめ
なんかつまらんなーｗ
もっとインストールレギュレーションかいくぐってツールをためし、、、おや？だれかき
そうだ。エディタ。使おう。
ボード使った組み込みTDD勉強会 向けにせっせとボード向けにCppUTestをビルドしようとしたけどどーにも。。。
で、飽きてきたので昼間になんとなく思ったことをメモ。
エディタ？IDE？
どっちが良い・悪いの話ではないですよ。
このへん を見ててぼーんやり考えたり。
IDEから入ると楽！
ですよね。イロイロと。
個人的にはエディタはvimが好きなんですが、vim力無いのに何でもかんでもvimで賄おうとして爆死、とかよくあるパターン。
IDEなら補完とか直接実行とかイロイロ楽ですし、特に初学者（や、プログラミング未経験な感じの人）には、IDEから入ってもらった方がいいんだろうなー、とか。
エディタを使う条件（？
なんとなく、プログラミングするときのエディタの使い方って、
- 事前にやりたいことが頭に具体的にイメージされていて
- それをプロットする
様な使い方になるんじゃないのかなーと思ったり。というか、確かどこかのブログエントリに言及されてた話だった気がするけど、どこのエントリだったか忘れちまった。
ということで
「hogeをやる！」がある程度明確にイメージできる様になってから「エディタをコンパイラ直叩きでゴリゴリ！」とかでいいんじゃないですかね？*1
じゃないとイバラの道過ぎて飽きちゃうんじゃないかな。。。特にワシみたいな人間は。。。
*1:ていうか無理にエディタ使わなくっても。。。ぐは
TDDのデメリットってなんだろう？
いやー怖いタイトルｗ
は、いいとして。純粋に「何があるんだろう？」と思ったりしたのでメモ程度に書いてみる。
ことの始まり
最近 組み込みTDD本 を読んだり勉強会したり同僚に薦めたりする中で、奇特にもこの本を買ってくれた同僚に言われた一言
この本ってTDDのデメリット書いてないっすね
まだこの本をちゃんと読み切れてないけど、慌てて章構成だけ見直し。 で、確かに1章にメリットと、14章にアンチパターンは書いてるけど、明確に「これデメリットよ」という話は無さそう。。まぁ「アンチパターンとデメリットって何が違うの？」ってのに明確な解答を出せてないけど、なんとなく２つってちょっと違うイメージ。
ので禅問答がてら思考遊びでもしてみようかと。
いちおうの前提
単純に「デメリット」っつうことで、この辺の話はナシで。
- 「テストおせーよ」みたいなTDDサイクルにおけるアンチパターン
- 「それhogehogeすればカバーできるよ？」な話
ちなみにTDDアンチパターンはこの記事なんか面白かったです。
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた
ざっと挙げる
バーっと考えてみて、これかな？ってのをざっと列挙。
- メンテナンスの必要なコードが増える
- 見た目の実装工数が増える
メンテナンスコードの増大
どう考えてもこれは発生しますわね。最初は気づいてなかったけど頂いたメンションにより「そっか、そらそうだよね」と。
確かにコードが増加することは避けられない、よなぁ。
見た目の実装工数の増加
コードが増加するのに付随しそうだけど、TDDは「いわゆる実装工程」なタイミングでやるもんだと思うけど、その工数が増えますね。
「イヤ詳細設計レベルのも含んでる」「テストの工数も減少できるし」はもちろんyesと言いたいけど。まぁ今までその辺をちゃんとネゴって実行した事がないので具体的な説得術が無かったり。
そういや
普通に見積もった工数で「実装工数」として取った期間内でTDD的に作って後の工程で"余暇"を満喫
な事もやったりしてたっけ。。。いや余談やけど。
ていうかイチイチ「説得」とか面倒になってしようともしなくなったなぁ。。。勝手にやってしまってる。あこれも余談すね。。
こんなもん？
ん〜。なんかまだあるような気もするけど、ひとまずこんなもんかな。時間かけても出てこないっす。
思いついたら追記なりしてみるかー
p.s.
「デメリット」と「アンチパターン」って何か違う事柄の様なカンジがするんだけど、うまく言語化できてない。。
この辺も整理できると楽かなー
社内プログラミングコンテストをやってみるなど
いろいろ思うところもありつつ、やってみました。
内容
とまぁ、やり方自体は特にこれと言ったものは無いわけですが。
なぜやろうとしたか？
表向きには
- プログラミングを語ろう！
とかナントカ挙げたりしてたわけですけど、ホントは
- 社員のプログラミング熱を測る
のが目的でした。なんかこう、熱い感じの人と仕事したいな！とぼんやり思ったりしてるわけです。*1
仮説/検証
一応仮説・検証を考えてはいました。
仮説
- プログラミング熱のある人はどれくらいいる？
- 熱のある人はこういうのに食いつくはずだ！
検証
- 投稿人数によって会社としての熱具合を探ろう
っつう感じですかね。 で、うちの部署は20人そこそこの人数がいるのですが、
- 2 〜 5人くらいの投稿者だろう
と考えてました。 テーマも可能な限り簡易なものをということでfizzbuzzを選んだわけですが。
結果
つい先日結果発表まで終わったのですが、全部で「5人」の方に投稿いただけました。まぁ予想通りか。ただ
- そのうち１人は別途上司からの勧めがあって投稿してきた
- 勧めがあったのは３人いたのに投稿したのは１人だけだった
といったところは少し残念。
んーむ。
なんかこう、今ひとつ煮え切らず。もちろん第二回以降もやろうとはしてますが。。。
時間の都合上具体的なフィードバックはまだ貰えてないですが、やり方自体はカイゼンしたいところ。
でもなんだろうなー、なんか「doneな感じがしてない」なー。ちょっと検証内容とか練り直すかな。
*1:あまりにも低そうだと、ほら、ね。うん。
「わかりやすいアジャイル開発の教科書」を読んだ！！
著者の @yasuohosotaniさんから「モニターしない？」とかる～く渡された本。
- 作者: 前川直也,西河誠,細谷泰夫
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2013/03/28
- メディア: 単行本
- クリック: 2回
- この商品を含むブログ (5件) を見る
を読みましたので感想おば。
なんというハードル
のっけからまずタイトルがすごいです。
「わかりやすいアジャイル」
ですよ。。すごい。 ひねくれた色眼鏡で見るとただのミスリー・・まぁそんなことはいいですね。
全体の構成
は、もうこちらで解説されてますね。
Agile News Flash / 【書籍】わかりやすいアジャイル開発の教科書
本書は次の４章から構成されている。 下記ページ数をご覧いただければ判る通り、「第３章」が一番分厚い。
という構成もありますが、五章の「アジャイルの本質」が最後というのもなんとなく興味をひかれました。 あ、最後に来るのね、と。 まぁ基本的な内容はソレまでのところにぎっしり詰まってるので、ホントおさらいがてらかもしれないですが、よくある
本読んで言葉だけ拾って「やったるで〜」だけによる暴走
に最後にちゃんと念を押す、みたいな。「手段？目的？忘れちゃダメよ？」な感じですかね。
あと、各章の頭にちゃんと「この章の目的」が書かれてるあたりもさすがだなーという。 しかもきっちり1ページに纏められてます。 書店なんかでチラ見るときには、各章のこのページだけでも見てみると、何が得られる本なのかはっきりすると思いますね。
他の本と違う所
そんなにいろんなアジャイル本を読んでるわけじゃないですが、「おー、そうくるか！」というのを並べてみると、
- TDDを「具体的なやり方」にまで言及（コード付き！）
- ワークショップについての詳しい解説（やり方まで！）
- 図った様に出てくる「こんなときどうする？」
といったところかなと思います。
詳細なTDDの解説
「おぉ。なんかやたら詳しいなー」が最初の感想ですね。 「TDDとは」から始まってかなりのページを割いて解説されてます。
なんでもそうでしょうけど、ボリュームが多く割かれるってことはやっぱり、 著者が大事に思ってたりとか、強く伝えたかったりするものなんだと思います。
じゃぁ、「アジャイルの教科書を書こう！」という著者がTDDをここまで大事にしている理由は・・・というのを想像してみると、
- 現場のエンジニアがまずとっかかりやすい
- 「動くソフトウェア」を支える最小のピースである
になるのかなー、と。
とっかかりやすいプラクティス
前にも書いた気がしますが、普段コードを触れるプログラマにとって、TDDをやらない理由はないです。 と同時にやれない理由もよっぽどのことがない限り存在しないと思ってます。 OSSに数多あるフレームワークをパッと持ってきたらそれだけで準備が整う。 プロジェクトとして「ユニットテスト作りましょう」になってなくても、自分だけで始められます。
人とのつながりを重視しているアジャイルな開発手法においてもTDDは「ひとりでできるもん」な始めやすいプラクティスであるのは間違いないと思います。
如何に「動かし続ける」か
またTDDの結果として出来上がる自動テスト群は、「動く」事を担保する根幹になるはずです。 もちろんユニットテストだけで！ではないですが、動かし続けて積み上げていくアジャイルなやり方を支える第一歩だと思います。
というあたりで、「やっぱりTDDからでしょ！な思いがある」のかなーー、といった印象でした。
ワークショップあれやこれ
ここまで具体的にワークショップの段取りや、ファシリテーターの振る舞い（重要！）として
「なにを伝えるべきか？」「どうアクションすればよいか」
「そもそもどんなワークショップがあるんだろう？」や、「ワークショップやったりしてみたいけどどうしたらええの？」 な人にとっては、ワークショップの参考書代わりにしてもいいんじゃないでしょうか。ソレくらい詳しく書いてくれてます。
あとはコミュニティ紹介があるのも、著者が日本人ならでは、というところもありますよね。
そんなことだろうと思って
こういう類の本を手にする人って、少なくともアジャイルに興味があったり、実践しようとしてる人だったりすると思うんですね。 で、おそらくそういう人は本を読みながら「現場」を想像すると思うんです。
「お、ペアプロかー。やってみるならあの人とかな〜」
とか、
「んあードキュメントねぇ〜。アレ絶対ムダやけどどうしたらええだろう〜」
とかとか。でもってそうなると途中で絶対出てくるのが
「いやいやキミそう言うけどやね」
ですよ。
そんな時この本には「そうだろうと思って」と言わんばかりに 「こんな時どうする？」が出てきてます。まさしく孔明の（ry
要所要所に出てくるこの「対策」と合わせて、いかに現場に適用するか、を考える様な内容になってますね。
つまるところ
すごく読みやすい「教科書」になっていると思います。 「"どの本から読めば良いですか？"の解にしたかった」という著者の言葉通り、
- 外枠
- その外枠の意味
- 一歩目を踏み出すhowto
とひと通り揃っていると思います。
著者が日本の方ですから、訳書とかにありがちな「微妙なコンテキストの違い」もかなり小さいと思いますし、 この本を出発点にして気になったポイントを他の文献と合わせて深堀りしていく様な流れも感じさせてくれる本だと思います。
しかしアジャイル関連の本は読む度に突き刺さるものがあるな。。。
「お前どれだけできてんだよ？」
というアレ、です。
言語。言語。
なんか言語disが流行ってるみたいですね！
で、乗っかれるほど知識は無いんですが、ちょびーっと思ったこと書いてみましょう。
過度な期待
で、やっぱりc周りって、メモリ管理とか面倒なんです。
int leak_func(){ char* p = (char *)malloc(128); return 0; }
はい。リークですね。ありがとうございます。
で、そこから見るとjavaとかって「gc最高！！」に見えてしまうのです。
は？
もちろん不勉強、ないしは知識不足、はあります、当然。
が、javaで言うと何でしたっけ、FileInputStreamでしたっけ？
あぁいうのって、明示的にcloseせんとイカンのですよね？
たしかデストラクタ(?)とかでcloseされるポイですけど、夢見がちなC言語erからすると「えーーー！？gcいけるんちゃうの？！」になっちゃうんです。
裏切ったなーー
とか思っちゃうんですね。多分。
最初に書きましたけど、不勉強はあるんです。てか私がそれ。
だから非常に安易な先入観で対象の言語を見てしまって、過度な（そしておそらく間違っている）期待をかけて、「なんじゃそら！」になってまう、と。
「いやいや言語仕様読めや」的なdisって、その辺から来てたりせんかなー、とTL見てて思いました。
VCでGoogle Test
なんか最近、イライラしてるんです。
てか新しい情報探そうとしたら英語にぶち当たるのなんかムカつくな。。。
— an Udon (@datsuns) February 13, 2013
ったく。英語嫌いなんだってんだ。
ので、書く。
じゃぁもう少しでも日本語の情報増やせばええんだって
意訳！
こいつじゃーいつものStackOverflow
いくぞーーおりゃーー
あ、ちなみに自分では試してません（汗
Google Testをダウンロード
- 最新版をダウンロード
- これを C:\gtest に解凍したとしましょう
Googlge Testのライブラリをビルドする
- Visual Studioで C:\gtest\msvc\gtest.sln を開く
- プロジェクトの設定を「Debug」に変更
- ソリューションをビルドする
テスト用プロジェクトの作成
- 新しいプロジェクトを作成し、テンプレートを[Visual C++] - [Win32] - [Win32コンソールアプリケーション]と選択
- 生成したプロジェクトで右クリックして「設定」を選択
- プロジェクトの設定を「Debug」に変更
- [設定] - [C/C++] - [一般] - [追加のインクルードディレクトリ]に「c:\gtest\include」を追加
- [設定] - [C/C++] - [コード生成] - [ランタイムライブラリ]にて、マルチスレッドプログラムなら「マルチスレッドデバッグDLL (/MDd)」を、そうでないなら「マルチスレッドでバッグ (/MTd)」を選択
- [設定] - [リンカ] - [一般] - [追加のライブラリディレクトリ]に「c:\gtest\msvc\gtest\Debug」または「c:\gtest\msvc\gtest-md\Debug」を追加（先の項目によって変えましょう）。これは「gtestd.lib」の場所です
- [設定] - [リンカ] - [入力] - [追加のライブラリ]に「gtestd.lib」を追加
設定が効いているかを確認
- main()の含まれるソース(.cpp)を開く
- 以下のコードを貼り付ける
#include "stdafx.h" #include <iostream> #include "gtest/gtest.h" TEST(sample_test_case, sample_test) { EXPECT_EQ(1, 1); } int main(int argc, char** argv) { testing::InitGoogleTest(&argc, argv); RUN_ALL_TESTS(); std::getchar(); // keep console window open until Return keystroke }
設定がうまくいってればこれでいけるはずです！
