今更ながらTDDBC Tokyo 2013

メモがあったので乗っけとく

TDDBC TOKYO
twada和田拓人
gihyo.jp
動作する綺麗なコード…
動くー綺麗か？

②つの道がある。
１．汚い・動かない→※②汚い・動く→綺麗・動く
２．汚い・動かない→※①綺麗・動かない→綺麗・動く

※①綺麗さには限界がないので、期限に間に合わなくなる。
　完璧主義沼地。
　ソフトウェア開発手法はまだまだ未熟。
　→動かして初めて分かることのほうが多い。

※②堕落沼に落ちる。
　コードを綺麗にすることを怠ってはいけない。

２．のほうがTDD。

TDDとは？
　目標を考える（TODOリスト。設計リストを作成。)
　作業を選択する。
　RED,GREEN,REFACTORのサイクルを回す。
　　→つまり２．のサイクルを繰り返す。
　　　何をしてるのかを常に意識することがアジャイルでは大事！
　矢印があるということは目的がひとつということ。
　
　GREEN…取りあえず動くコードを書く。【汚くていい】。
　Refactoring…小さいうちに片付ける。
　　リーダブルコード、リファクタリングの有名なやつ
　　2冊本がおすすめ。

大事なこと１．
　大きい問題をそのままテストするのではなく、
　小さい問題に分けて、それを組み合わせて
　大きい問題を解くようにする。
大事なこと２．
　サイクルを素早く、回数を行う。
大事なこと３．
　自分が最初のユーザである
　(自分が作るものをまず初めに自分が使う。)
　　→テストコードで使う。
大事なこと４．
　【不安なこと】をテストする。
　　→不安でないことはテストしない。
　　　getter,setterにはいらんでしょ？

TDDのメリット
　ソフトウェア工学的なメリッドもあるが、最大の理由は
　【心理的なもの】【健康】
　　→即座にフィードバックが得られる
　　→書いたコードに自信をもつため
　　→これから書くコードに自信をもつため

　健康なら毎日REDBULL＋終電ダッシュはしなくていい。

TDD採用(MS,IBMの例)
　管理者見積もりによる増加コード実装時間
　　15%~35%
　テストコードはプロダクトコードの30%〜90%

　コーディング行・時間は増えるが、
　デバッグの時間が減るので全体の時間は減る。
　　デバッグにかかる時間はブレが大きいが、
　　そのブレを抑える働きがある。

TDD応用
　テストのないコードがたくさんある…
　　レガシーコード改善ガイド本
　すでにデータの入ったデータベースがある…
　　データベースリファクタリング本
　SlowTests…
　　メモリに対するテストより、DB、ネットワークに対する
　　テストのほうが時間がかかる。
　　→フィードバックにかかる時間が増えてしまう。
　　xUnitTestPatterns本…英語
　　　ネットのwikiをまとめたもの。
　テストをどこまで行えばよいか・何をテストすればよいか…
　　ソフトウェアテスト技法ドリル本
　実際の複雑なテストをどう行うか？
　　実践テスト駆動開発

TDDはスキル！
　才能ではなく習得可能！
　量は質に変化する！
　写経！！

**********************
実践テスト駆動開発の著者の一人
スティーブフリーマン(Steve Freeman)

　新しい機能を追加するのではなく
　既存の機能をリファクタリングすだけなら
　リファクタリング用のテストコードを書いて、
　リファクタリングを行う？

　●テストダブルを行う理由は？
　オブジェクト間のメッセージが飛びかっていて、
　(オブジェクトが頂点でメッセージが辺のようなグラフ)
　　その中のやり取りが上手くフィットしているか
　　確認するってのが１０年前に言われて、
　　今もそれが目的だと思っている。

　　テストを細かくするため。
　　たくさんエラーが出た時にどれが問題かを判断するため。

　●不可能なテストをどのように対応するか？
　　　→レガシーコード改善ガイド本見て。
　　依存関係を切っていく。
　　大きな塊でやっていく。
　　
　小さく取り出して安全な形で変えていく(リファクタリング？)
　そのうち状況が変わったり、
　解決につながるアイディアが思い浮かぶ。

和田問写経

Githubリポジトリ
TDD伝道師の和田さんが出された問題が話題になったのでやってみた。
というか、黒魔法リフレクトを唱えるのもめんどくさくて、
解説見てから良さそうなやつを実践した。

解説で問題を解くパターンがたくさん紹介されているので、
それぞれメリット・デメリットがわかりやすくてとてもタメになります。

私が今回実践したのはSelf Shunt。
わかりやすく実践しやすい上に強力。

脆いテストにならないように注意して多用しようと思う。

〜追記〜
Junit4でテストクラスで継承を行った場合に下記例外が発生した。

java.lang.Exception: Test class should hava exactly one public zero-argument constructor

どうもテストフレームワーク側で引数なしのコンストラクタを使用しているため、
引数ありのコンストラクタのみしかない場合に例外になるようだ。

プロダクトコードに引数ありのコンストラクタしかない場合はSelf Shuntは使用不可なのか？

2013年に読んだ本(技術系)

• Java・スタイル

Javaの基本がわかりやすく解説されていると思う。読むだけで「ふむふむなるほど」と納得するような書き方になっている。 基本構文よりもう少し上の内容について学びたい人向け。



どちらも難しい＋古いのでほとんど読んでいない…
でもどっちかって言うとCODE COMPLETEの方が古いコードは出てこないので、概念的に活かしやすい内容になっている。


東京に就職してから初めて参加した勉強会で扱ってた書籍。社会人2年目になってやっと…。
Mac Book Airを所持してやっと勉強会への参加資格が得られた時だったので。
内容としては簡単でわかりやすい。半日もあればひと通り読める(勉強会前日夕方に買って読んだ)。
コードを綺麗に書くための入門としてはとっつきやすいです。
コメントを書く代わりに関数名や変数名で意味を表示できるようにすることや、 ある程度パターンとしてこういう名前が使われているってことを学びました。
勉強会の資料の一つ(2013/07) →資料
勉強会では@terahide27さんの黄色い髪の毛が気になって仕方がなかった…。


これまたあまり読んでない。 でも今なら読める気がする。


これは大学時代にひと通り目は通して、こういうものがあることは知っていた。 今では「たしかこれのパターンあったなー」って時に辞書として使うようにしている。


大学時代には手を伸ばさなかったマルチスレッド編。 そもそもマルチスレッドを殆ど書いたことがなかったので避けて通っていたが、 趣味で使うことがあって書いてみたけどどうにも動かなくて、この本見たらばっちりパターンがあったとかそういう感じ。ひと通り写経は済ませてある。1回だけだけど。やる人って本当に何回も写経してるんすかね？
この本の内容の内容を理解している人でないと怖くてマルチスレッド部分は任せられないですね。 結構この分野の書籍はあんまりないので古いですけど今でも必読かと思う。
RubyとかScala使うなら別だけどね。


本屋でパッと「リファクタリング」の文字が目に入って買ってみた本。
この本は私の中でのプログラムに対する間違ったイメージ「凄い機械的で机に向かい続けて作り上げるもの」を「もっと創造的で、人間の感性を活かして概念レベルで構築していくもの」に変えてくれたもの。
設計に困って行き詰まったら机に向かっているより散歩に行くと簡単に解決したりする場合があることや、いいアイディアなんかは酒飲んでる時が一番出てくる、といった効率よく開発を進めるテクニックが色々書かれていた。
ちなみにこの本にはコードのリファクタリングは全く出てきませんｗ

• TDD・CI

Jenkinsで出来るひと通りの機能が載っているので、 本書でツールのイメージができたら後は導入してどんどんJob作ってみるのが大事なのかなと思う。 「Jenkinsさんって何でもやっておいてくれて最高!!!」って言葉をよく聞くけど、自分は結構ハマることが多くて生意気な執事だなーと思っています…ｗ


JUnitを使う上では絶対に読んでおきたい。某名古屋怖いの人なんかは100回写経してるとか？ ひと通り学べる系なので「モックの部分詳しく」とかなった場合は他で調べる必要は出てくる。


まぁ意識高い系のエンジニアさんはすべて毎日使ってるんでしょうね。


ちょっと固い感じ。 デシジョンテーブルとか昔大学でやったな～とかあるけど、 6割以上のテスト技法は初めて聞いたもので現場でも見たことがない。 きちんと理解すれば生かせそうなんだけど理解度ががが…。


レガシーコード(テストのないコード)を改善していく場合に使えるテクニックが満載。 おそらく日本の先進的な企業以外で働いている人はほとんどがレガシーコード相手に仕事をしているはず。 これから作る場合はレガシーコードを書かないようにすればよいが(多分これも殆どの企業でできないが)、 今あるコードにテストを追加し、保守しやすくしていく上でどのようにアプローチしていけばよいのか、 コードレベルで書かれている。 レガシーコードに挑む全ての戦士にお薦めしたい。


これは思い出深い一冊。
2013年7月TDDBC Tokyoでの特別ゲストSteveFreemanさんが書かれた本です。 それをじゃんけん大会で獲得し、サイン+手渡しで頂きました。ありがとうございます。
GUI+マルチスレッド+非同期通信と言ったTDDを行う人にとっては泣きたくなるアプリに対しての アプローチ方法が書かれている。
ストーリーに沿って開発を進めアプリが完成していく様子を体験できる。
この開発部分の内容は少々難しくなっており、本書に載っているソースだけではコンパイルが通らないようになっている。 あとがき部分にGithubのリポジトリが記されているので、そこを参考にしていくと良い。
第Ⅲ部からの実践部分も大変ためになるが、第Ⅰ・Ⅱ部で彼らがどういった考えで テストを書き、設計を行いTDD・プロジェクトを回しているかといった部分が 書かれているところがとても良いと感じた。 TDDはアジャイル開発の原動力になると感じているが、なぜそのように出来るかといった点の理解がこの部分で深った。

• プロジェクト

取り敢えずアジャイル開発に関わる人なら読んでおいてもらわないと困る。 アジャイル開発はただ工程が変わるだけじゃなくて、現場レベルでは色々なプラクティスを使って、 関係者間のコミュニケーションを図っていたりするわけで。 それがあってこそのアジャイルなはずなのに、言葉しか知らない人はそこを全くわかっていないと思う。 アジャイル開発で用いられているプラクティスはアジャイル開発に限らず、 WFでも他の分野でも使えるものが多いので、 プロジェクトの運用方法を改善したいと思っている方には参考になる本だと思う。


@papandaさんが翻訳をされた本。 リーン開発はトヨタ生産方式を参考にした非ウォーターフォール開発手法の一つで、 そのなかのカンバンをベースにプロジェクトを回した経験が記されている。 リーン開発の書籍は読んだことがないのでリーンにおけるカンバンの重要度がわからないのですが、 カンバン以外の周りの部分が見えづらいのが気になったところ。 終始カンバン・カンバン・カンバンであり、カンバンを極めるなら良いのかも？ 2013年11月に行われたDevLove甲子園で@papandaさんが熱心に宣伝されてましたW

WFをずっとやってきた会社でアジャイルを取り入れてプロジェクトを回してみた成果報告が書かれている。 各プラクティスの実践方法に関しては他の書籍で学べばよいが、 それを現場で広げていくために「上と掛け合うための材料」をどのように集めるかといった知識が書かれている点が優れていると思う。 アジャイル開発の効果を示すために定量的データの取得方法を模索されている方にお薦めしたい。

• Git

Gitって直感的でなくって難しいのですが、これはストーリー立てて簡単に書かれているので、 入門として最適だと思います。 このストーリーを完璧にこなせるようになってから「他にもこんなことできないの？」って部分を 学んで行けばよいかと。


こっちも入門ですが難しいです。上の知識を蓄えてから掘り下げたい部分を本書でのスタンス。 写経しつつGitでコミット練習しながら使ってます。

• その他

統計が流行った時期があったので。ビックデータとか言われている時代に利用方法がわかってないとなにも価値を見いだせないので。 統計がわかっている人は実践の使い方が学べるのかな。 あんまりわかっている人間ではないので勉強し直さないと役に立たないですね。



大学時代に読んだ本の一つでかなり影響は受けている。 一生懸命働くことがいいことではなく、きちんと稼ぐように働かないと一生お金持ちになんてなれないよって話。 小中高大で勉強してきたけどお金の儲け方については一切教えてくれないわけで、 この本なんかがその方法の突破口になっている。

半年の間で64,000円か…。
収入の1割には届かないけど昔に比べたら大分投資してますね。

MySQLでの識別子は大文字小文字を区別する事がある

公式参考
DBでのクエリは一般的に大文字小文字区別しない認識だったが…。
MySQLの場合テーブル名をOS上のディレクトリ構造で表現した時に
区別される場合はそれがクエリにも反映される。

通りでWindowsからCentOSに移行した後で下記エラーが出るわけだ。
「Table 'XXXX.YYYYYYY' doesn't exist」

Linuxで思ったように動かない時

・実行しているのは誰？実行しようとしているファイルは誰の？権限は？
・ファイアウォールに穴は開けた？
・パスは通っている？
・今どこにいる？

iptablesの場所

CentOS6.4の場合

/etc/sysconfig/iptables


再起動は
/etc/rc.d/init.d/iptables restart

httpclient 4.2.1でのマルチスレッドによるアクセス

最新の4.3.1だとやり方が違います。

4.2.1の場合。
クローズする前に他のアクセスをする場合は必須。

公式参考ファイル

オンラインドキュメント各種

Apache HttpComponents
http://hc.apache.org/httpcomponents-client-4.2.x/index.html

CalendarからDateに変換して文字列整形

参考

gitのコミットメッセージで#を使いたい

gitでコミットの際にviなどから先頭に#をつけて記述を行うとコメントとして認識されるわけだが、
Issueと結びつけるために先頭で#を使いたい場合、どうすればコメンと扱いにされなくなるのか…？

git commit -m "#1 メッセージ"
とやれば回避できるが…。

複数行のコメントをちゃんと書けということでしょうかね。

Linux間のファイル送信

scpコマンドを使う。
CUIの最小構成でも入っているのでどこでも使える。
ファイルの送信中は状況が表示される。

scp 送信ファイル 送信先アカウント@送信先IP:送信先ファイル名

ディレクトリを送るときは-r指定で。

MySQLでCSVファイルからのデータインポート

参考

LOAD DATA INFILE 'ファイル名'
    INTO TABLE テーブル名
    FIELDS TERMINATED BY ','
    (@CSVの1行目, @CSVの2行目, ...)
    SET DBのカラム1=@CSVの1行目, DBのカラム2=@CSVの2行目,  ...;

SETでデータの並び順を変えたり、日付＋時間を結合してDateTimeを作成したり可能。

その時の文字列結合にはCONCATを使う。
CONCAT(文字列1, 文字列2, ...)

SPACE(n)でn個分のスペースを表せる。

Junit実践入門のまとめ

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)



・assert that actual is expected(実測値が期待値であると表明する)

・例外
    テストメソッドの前に以下を記述してから、例外が起きるメソッドを実行する。
    @Test(expected = 例外.class)
・カスタムMatcher
    ・BaseMatcherクラスのサブクラスとして定義
    ・matchesメソッド
        値の比較検証
            actual(実測値)を受け取るようにする。
            期待通りの動きをしている場合はtrue、そうでない場合はfalseを返す。
    ・describeメソッド
        比較が失敗した場合に通知する情報
        Descriptionオブジェクトを受け取り、
        この中に検証失敗の情報を入れる。
            java.lang.AssertionError:
                Expected: is Descriptionオブジェクト中身
                     got: 実測値のtoString
            appendValueメソッド
                出力にダブルクォーテーションがつく
            appendTextメソッド
                出力にダブルクォーテーションがつかない
    ・コンストラクタ
        expected(期待値)を受け取るようにする。
・テストのコンテキスト(テストの構造化)
        ・共通の初期化処
        ・共通の状態
       
        ●例
            @RunWith(Enclosed.class)
            public class クラス名Test{
                public static class ○○○○{
                    ～ テスト処理 ～
                }
                public static class □□□□{
                    ～ テスト処理 ～
                }
            }

・パラメータ化
    ・テストケースを少なくし、品質も良い状態に保つには、
      すべて満たしている条件と1つだけ満たしていない条件でテストを行えばよい。
    ●@Theory
        パラメータ化テストでは@Testの代わりにこれを使う。
    ●@DataPoints
        パラメータ化テストのパラメータ定義を行う。
   
    ●複数パラメータ化テスト
        public class クラス名Test{
            @DataPoints
            public static Fixture[] params = {
                new Fixture(1, 2, 3);
                new Fixture(3, 4, 7);
                new Fixture(5, 6, 11);
            };
           
            @Theory
            puvli void add(Fixture p) throws Exception{
                ～ pがパラメータ ～
            }
           
            static class Fixture{
                int x;
                int y;
                int expected;
                Fixture(int x, int y, int expected){
                    this.x = x;
                    this.y = y;
                    this.expected = expected;
                }
            }
        }
        ●外部リソースを使ってパラメータを定義するのが便利！
            ～未記載～
    ●assumeTrue(boolean flag)
        flagがtrueの場合のみその後の検証を行う。
        falseの場合はAssumptionViolatedExceptionが送出され、テストが成功となる。
    ●どのパラメータで失敗したかメッセージが出ないため、
      assertThatの第1引数に失敗時のメッセージを記述すること。
・TDD(テスト駆動開発)
    ●開発工程
      以下を繰り返す
        ・設計する
        ・テストコードを書く
        ・プロダクションコードを書く
        ・リファクタリングする

ビルド+ツール

JenkinsとJUnitと組み合わせるのにビルドツールがあると便利なわけだけど、
AntもMavenもわかりません。

Makeもわからないしビルドツールは好きではないんですよね…。

でも最近見つけたGradleさんがどうも調子よさそうです。
日本語の本はまだ出てない？ようなので、
自分も使えるようになって流行っていってくれたらいいな～。

とりあえずここ読んどきましょう↓
クイックスタート
ユーザーズガイド

Jenkins

ジェンキンスさん。
間違ってもテストを自動でやってくれるやつと思ってはいけない。

テストをやってくれと合図を出して、
受け取った結果なんかを綺麗に表示してくれるだけ。

高性能なGUI版cronです。

テストの中身なんかは自分で実装する必要があるし、そこが一番時間がかかるとこ。

Rubyと一緒に解説されることが多い気がするけど、
本当はJAVAやただのバッチをあるパターンで実行させることなんかにも使える。

テストしてくれるだけって思うととてももったいない。

情報処理試験DB用語まとめ(自分用)

単語の定義ってIPAで出してたりするんですかね？
本によって定義が違って、答えに影響が出てくるんだけど。

●エンティティ
　　テーブルと一緒
●アトリビュート
　　行。タプル。
●カラム
　　列
●候補キー
　　主キーになることができるキー集合。この中から妥当なものを選んで主キーにする。
●関数従属性
　　ある属性の値が決まるとき、別の属性が一意に決まる事。
●部分関数従属性
　　候補キーの一部に非キー属性が関数従属している事。
●推移関数従属性
　　Aが決まるとBが決まり、その結果Cが決まる事。
　　(ただし、A→Cの関係がBを経由しなくても成り立つ場合は除外される。)


2013/04/09追記

●リレーションシップは外部キーとそれに対応するエンティティを結ぶ。
　　(明確に1対1関係を示していなければ大抵外部キー側が矢印)
　　(外部キーでもある主キーを書き忘れない忘れないこと)

●(単一に多い)主キーかつ外部キーである～番号、～コードで紐付けているエンティティは、
　 紐付け先にある項目を余計に定義しないように。

●カラムが1のエンティティも存在する。

●自然結合、内部結合、USING、外部結合はNULLが現れる、自己結合、COALESCE

●コミットではトランザクションのログデータのみ書き込み。チェックポイント(一定のタイミングかメモリーバッファがいっぱいになったら)になったらデータベースファイルに書き込む

●ダーノンリファリード。
RU
RC
RR
SE

●3層スキーマ
外部スキーマ…ビュー。利用者へ見せるデータ。
概念スキーマ…テーブル。管理対象。
内部スキーマ…インデックス。物理的な格納。


●楽観的方法…ロックしない。
●セミジョイン法…分散時の結合処理で効率化。

●ACID特性
原子性…トランザクションが実行されるかされないかのどちらか。
一貫性…トランザクションの前後でデータの不一致は起きない。
独立性…データを隠蔽して余計な手出しはさせない。
耐久性…障害などでもデータの損失は起きない

●÷
22年午前Ⅱ問12。R÷SはRのうちSの組で抽出される行のSの組と関係しない列が同じものが残るｗ

●外部キー
参照する場合は、参照先が存在する必要。参照される場合は削除や更新の制限がある。

●代理キー
候補キー=主キーU代理キー
主キーA代理キー=空

●2相ロック方式
分散データベース環境にて資源をすべてロック→ロックを解除する方法。

●スループット
大きいほうが良い。

属性が全て単一値をとる。
☆午後2では主キー、外部キーを忘れずに。
☆周りの関係をよく見て(矢印なのか、線なのか)。

Winmerge - リポジトリ取得

WinMergeの機能で追加したいものを思いついたので、探ってみた。

現在公開されてるのはWinMerge2だが、どうもWinMerge3が出るようだ。
→公式
…でも今日は落ちてるみたい。

WinMergeのリポジトリは→ここ
Githubにあるのかと思ったらBitBucketっていうGitとMercurial(Gitに似た分散バージョン管理)
が使える所に挙げられてる。

Githubくらいは私でも知っていたがBitBucket走りませんでしたね。

BitBucketは無料ユーザーでもプライベートリポジトリが持てるので、
こっちの方が使えそうな気がする。
Githubからリポジトリを持ってくるのもWebUIで可能だし。

で、BitBucketからWinMerge3のリポジトリ取得でつまずいた…。
EclipseのEGitを使ってたんですが、これはどうもMercurialには使えないようで。
WinMerge3がMercurialで管理されててGitへの変換もできない。
なのでEclipseにMercurialEclipse(インストール用URI)をインストールをして無事リポジトリの取得が出来ましたとさ。


WinMergeはもともとWindowsのアプリだったんだけど、
3からはマルチプラットフォームになります！

gccでコンパイルできるのかもしれないけど環境無いので諦めて、
MicrosoftのVisualStudioExpress(ここ)でコンパイルできないか試み中…

あれ無理っぽい？



2013/04/07 追記
ソース見てみるとやたら薄い…これって動く以前の問題じゃん。
そういえばどこかのサイトで白画面が一枚でておしまいみたいなこと書いてたな。

多読→理解力向上→頭いいスパイラル

齋藤孝の速読塾 これで頭がグングンよくなる! (ちくま文庫)

●本をたくさん買ってきてそのあと喫茶店で読む。 →頭の良い友人もやっていた、私はカフェに本を持ち込んでも1冊も読み終わらないので不思議に思ってたんだが、 効率のいい人はやっているのねーと。 几帳面な性格なので一言一句読んじゃうタイプ。 逆に要約だけしようとすると1行2行でどんな本も言い表せる気がしてた。 最近はそれに至る理由や背景を付け加えるってことが出来てきたので少しはましになってきたけど、 周りにいるある本について語れる人ってのはもっとすべての事を巻き込んで意見を述べれてますよねーと思う。

●自分がゲットした概念を間違ってもイイから使ってみる。 →これはスノーボードの経験がでかい。 ボードで得られた観点を他の全ての中で使っている。 実力に対してどの程度のアプローチが可能なのか、その時のリスクがどの程度なのか、 それをすることによって今までの自分よりどの程度成長したことをしているのか。 業界の中じゃただのアマチュアでたいしたことをしてないけど、 エクストリームスポーツにかかわった人でないと(　ﾟдﾟ)ﾎﾟｶｰﾝ とされますね。

●本を一冊読んだら経験と絡めてA4一枚にまとめる。 →これ

●本は背表紙が見えている状態が重要。 →確かに今の状況だと目に入らなくてなかなか「読もう！」って思った時にしか昔の本を読んでいない。 必須なジャンルは少しずつ蓄えられてきたから、同じ本を何度も自然と読み返す環境がほしいね。

●自分でも抽象語を使ってみる。 →ロハスな生活とは何ぞ。

●英語の本は音読を1時間続ける。 →英語の勉強のためにOSSの翻訳始めたけど、わざわざ訳さなくても翻訳サイトに投げて細かいところは自分で補えばいいじゃん。 て感じなので、もっとたくさんの英文を読みましょうね。