2014年に読んだ技術系の論文で良かったもの（大体ソフトウェアテスト） #swtest_jp

概要

2014年に読んだ技術書で良かったもの - うさぎ組にて、「どんな論文読んでいたのですか？」と聞かれたので、今年読んだ良かった論文を紹介します。下記で紹介していないですが、ICSEの論文はオープンなものが多いので出来るだけ読むようにしています。

テストを評価する

• Call Stack Coverage for GUI Test-Suite Reduction

  • 僕が今年読んだ中で最高の論文はこれでした。GUIのテストで無駄なものをどうやって省くかというテーマなのですが、Web GUIはマルチ言語だし、非同期だし難しすぎるゆえにテストツールはクソになった領域の1つであるとしたうえで、コールスタックを基準にしたカバレッジでテストスイートリダクション（無駄なテストケースを減らす）をやってみるという研究です。事例の3つでもいい結果がでていました。自分もこういうのつくりたいなーと思います。

• Checked coverage: an indicator for oracle quality - Publications - Software Engineering Chair (Prof. Zeller)

  • テストオラクル自体のカバー率を計測するというChecked Coverageという基準を新しくつくっていました。ミューテーションテストやデシジョンカバレッジに次ぐ新しいやつってかんじですね。

• Covering and Uncovering Equivalent Mutants - Publications - Software Engineering Chair (Prof. Zeller)

  • ミューテーションテストによって変更された部分がプロダクトの意味を変更しないようなものである場合の影響についての調査です。なるほどなーって思いながら、JavaLanche開発再開してくれないかなって常々思います。。。

• Practical JFSL verification using TACO - Publications - Software Engineering Chair (Prof. Zeller)

  • JFSLというJavaにアノテーションで契約プログラミングっぽいなにかを記述できるツールと、TACOというツールを使うことで、途中にAlloyをかませて、SATソルバを利用し、検査をできるという紹介です。素晴らしいな。素晴らしいな。

テスト戦略

• Strategies for testing client-server interactions in mobile applications
  • モバイルとサーバーで通信するようなアプリケーションのテスト戦略の一例です。キャプチャアンドリプレイ、JSONをうまく使おうっていう感じ。Google+の例らしいです。

テストツール、アルゴリズム

• HTAF: Hybrid Testing Automation Framework to Leverage Local and Global Computing Resources

  • 複雑で分散化されているWebアプリケーションのテストとリリースのタスクを一括で管理するためのフレームワークというかツールを開発しました。という話でした。こういうの大企業になればなるほどほしくなるんですよね。（今の自分がほしいとよく思うので。

• Network bucket testing | Publications | Research at Facebook | Facebook

  • SNSのようなソーシャルネットワークにおけるA/Bテストのアルゴリズムを作ったという感じです。A/Bテストは実践したことがないのですが、SNSだと確かに複雑そうだなーとか思いながら、こういった解決をもってくるのすごいとか思いました。

• The Goals and Challenges of Click Fraud Penetration Testing Systems

  • クリック広告に関するテストシステムの紹介です。Googleらしいなーって思いながら、巨大企業だとこういうのが収益に響くしなぁと思いながら読みました。

設計

• UI 設計のための HTML デザイン パターン

  • HTMLはそろそろVirtual DOMになるのかもしれませんが、こうやって整理していって始めるの大切だよなーとか思いながら、読んでいます。こういうのが集まらないと、初心者が汚いプロダクトを量産し続けることになる。。。

• 表示的意味論に基づくパターンマッチング コンパイル方式の構築と実装

  • パターンマッチって

• Lightweight Linear Types in System F

  • 線形型の勉強のために読みましたが、SystemFがよくわかっていなかったので、SystemFを勉強しなおしてからまた読む系です。ただ、ATSでの線形型の説明しか知らなかったので、こういったものを読めたのはよかったです。

まとめ

Java界隈いいな。

うさみみエンジニアが2012年に買った技術書

追加 2013/01/01 ここから
僕の読書方法Togetter
【うさみみさんの本の読み方 - Togetterまとめ】

(2012年の【僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組】のときに「どのように読書しているか」への質問ツイートへの返答をまとめたもの)
追加 2013/01/01 ここまで

なんかTwitterでつぶやいたら気になるとの事だったのでのっけてみます。
（個人的には他人のが気になるので、これを見た人が自分のを公開してくれるとうれしい

とりあえず、新しく買ったり、借りたりして読んだ技術書は全部のっけます。
2011年に既に買っているものは省いています。

その中でもいいなって思ったのは前半で括りだしてみました。
「いいな」っていうのは「今の自分にぴったりだったな」っていう意味で良書かどうかはまた別かもね。

うさみみ的によかった新しく読んだ書籍たち

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

2012年最高の邦訳書と言っても過言ではないでしょう。素晴らしい。
内容的にはモックを使いながらTDDをすることで、モジュール|コンポーネントの成長を促しましょうという話です。
これは正直テストエンジニアに読んでほしいです。
せめて、コードレベルでTDDを理解できる人にテストエンジニアになってほしい。普段から実践するほどであれとは思いませんが。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

こちらも素晴らしい書籍です。個人的には今後数年のバイブル的なものですね。
GOOSとどちらを推すか迷ってしまいます。むぅ。
そしてどちらも和智さん訳だ！

実践プログラミングDSL ドメイン特化言語の設計と実装のノウハウ (Programmer’s SELECTION)

この書籍はGroovy, Scala, Rubyと紹介しています。内容的には結局Scala押しかよ！っていう感じなんですけど。
あくまで個人的な感想だとファウラーのDSL本よりよいです。

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

これは本当にわかりやすくてすばらしかったです。どれくらいわかりやすいかと言うと、高校の教材でも大丈夫なくらい。
配色とか、位置とかこういう視点で考えるっていうやり方があるんだなっていう発見。
ある視点を知ると、その書籍にはない視点を想像しやすくなったりするわけですが、そういう意味でとてもよかったです。

Griffon in Action

みなさん大好きGroovyのデスクトップアプリフレームワークGriffonです。Grailsに強く影響されています。
この書籍自体は現行の1.0リリース直前に出されたのですが、ほとんど1.0と差がないので書かれている無いようであればほとんど問題なかったはずです。
ステップバイステップで非常にわかりやすかったですね。

アジャイルソフトウェアエンジニアリング (マイクロソフト関連書)

素晴らしい事例だと思いました。自社でも社内ツールをつくることがあるので、こういった感じで進めたいなぁとよく読み返します。

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

個人的には、Java、Androidアプリをつくる人には必ず読んでおいてほしいです。
xUTPを読む前にこれを読むとわかりやすいはず。

Specification by Example: How Successful Teams Deliver the Right Software

これ、まだ途中なんですけど、久しぶりのスマッシュヒットな気がしています。素晴らしいです。
来年読書会やりたい程度には。

サービスデザインパターン SOAP/WSDLとRESTful Webサービスの基本的な設計ソリューション

Webアプリのことあんまり知らなかったのですが、これでだいたい世の中のWebサービスの基本の一部にとっかかりをもてたような気がします。
HTTP使っているのはわかっているけど、どんな形式で、どういったことを、どんな風に扱う選択肢があるんだろうっていうのがわかってよいです。

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

最近パターンが好きで、PLoP系に手をだしました。内容も素晴らしいですがこのような活動をしているということが書籍になっていて読めるという事に感動しました。

プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集

こちらもPLoP本です。面白い！

プログラミング in OCaml ~関数型プログラミングの基礎からGUI構築まで~

五十嵐先生のOCaml本です。とても素晴らしいです。OCamlのことについて細かく書かれています。
プログラミングの基礎でしかやったことがなかったのでこれでだいぶ勉強になりましたね。
いまだと出版社のほうで電子版がでていたような気がします。

すごいHaskellたのしく学ぼう!

Haskellのことはすっかり忘れていたのですが、これで再度学習しました。非常にわかりやすいですね。内容が簡単というわけではなく、非常に順序がよくつまづきにくい気がしました。
これはたしかid:bleis-tiftさんがよいレビューを書いていた気がします。

ソフトウェア品質保証の考え方と実際―オープン化時代に向けての体系的アプローチ (実践ソフトウェア開発工学シリーズ)

僕の今年のソフトウェアテストに関する活動の多くはこの書籍に支えられている気がしますね。はい。
ソフトウェアテストに興味がある方はぜひご一読ください。僕としてはこれはぜひすすめたい。

データベースシステム概論

RDBの歴史だったり、RDBの基礎的なところが語られています。これを読むとSQLは意外とふわっとしているのではないだろうかという気がしてくる不思議ですね。
Dやろうよ！とか言いたくなる気がします。業務的にSQLに使えるわけじゃないのですが、非常に勉強になります。

コンパイラ―原理・技法・ツール (Information & Computing)

パース処理について丁寧に書かれていました。とても長いので苦労しましたが、体系的に学べるのでやはりよいですね。

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-

これも今年のスマッシュヒットですね。著者のプレスマンはかなり先見性がある人だとよくわかります。
基本的には手法のカタログ的な感じなのですが、それぞれに対する考察や関連する引用が非常にすばらしいものを使っています。引用元がオープンになっているものとかもあるのでそれらを見てよく勉強しています。

【Groovy in Action 2nd edition(MEAP)】
まだ正式発行されていませんが、Manning.comでMEAP版(オープンβみたいなもの)で読む事が出来ます。
1stにはなかった章がすでに公開されているので勉強になります。

Jenkins

Jenkinsに関しては個人的にはこの書籍以上のものが思いつきません。
これに足りないものはアドホックな対応が必要なものなので、ブログになるかなぁという意味です。
いや、本当に網羅的で素晴らしい。

Clean Coder プロフェッショナルプログラマへの道

これはエンジニアとして必読だと思います。新人が入って来たら必ず読ませたい。

アプリケーションをつくる英語 ―エンジニアよ、世界市場を狙え! ―

とりあえずざっと読んで、あとはリファレンス的につかうものですかね。
でも、これがないとたぶん新人プログラマーさんはどんな英単語つかっていいかわからないと思う。
必携です。

IA100 ?ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計

これもまだ途中なんですけど、なんとなくいい雰囲気を醸し出しています。もうちょっと読むとなんとなく掴めそうです。

その他に新しく読んだもの

ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点

ソフトウェア品質会計―NECの高品質ソフトウェア開発を支える品質保証技術

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

インフラ管理者のためのRun Book Automation実践ガイド オープンソースを使ったシステム構築/管理自動化入門

データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践

リーン・スタートアップ

チケット駆動開発

アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

アート・オブ・アプリケーション パフォーマンステスト (Theory in practice)

アントレプレナーの教科書

演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法

ソフトウェア見積り

ソフトウェア開発で見積もりのための定量化はできないんじゃない？

素人がそう思ったよ。間違っていると思うよ？入門しようと片足つっこんでいるときの独り言だよ？的な。でも、こう思っているよ？的な。

メトリクスとかをふくむ定量的なデータは傾向を測るものであって、特定チームの特定期間にしか使えないというもとに活用出来ると思った。

根底にあるのは「僕は1年前と同じようなコードは今では書かない。」のような「以前よりもっと綺麗な設計/実装ができる」というのがあります。
だから、例えば行数でも相対値でも違うものになる。

行数：コードの行数。コピペがないコードだとしても設計方針でまるで違ってくる。
ストーリーポイント：実現するための相対的なコスト見積もり。

他にもいろいろあると思うんですけど、きっとどれもが他人(成長する前の自分含む)と比較しにくいものだと思うのです。常に変化していく。
例としては(経験による感覚)、5,6人以下固定チームで2ヶ月目から9ヶ月以内くらいのチームでのみある程度の一定値を使えるんじゃないかなぁと思っています。
9ヶ月過ぎたらさすがに基準を見直さないとやばい気がしています。
（アジャイルではそもそも基準のベロシティが流動的かもしれないけれど。

「長期間使い続けられる一定値の定量化できています！」っていうチームは次の2パターンくらいはありそうだと思っています。
「(技術革新や個人のスキル上達が激しい世界なのに、メンバーや組織が成長を諦めたり、阻害しているので)長期間定量化できてしまう」
「長期間定量化できるプロジェクトしかやっていない(例として規模が小さいとか)」

個人的には「6ヶ月くらいで技術的にしろプロセス的にしろ変化がない」のはよくないかなーって思うし、それが起きているなら「そこまでずっと使えるような定量化っていうのは難しいでしょう」
っていう感じです。

ビジネス価値をいくら生み出したかというのは出来ると思うし、チームの評価には使えても、見積もりには使えないんじゃないかなぁと。
届けられなかったコストにどんなことがあったとか、どういったパスでその価値を届けたとかいろいろ難しいですしね。

個人的には、見積もりのための定量化を頑張るよりは、「いかに早く届けられるか」と「いかに今やっている事が正しいか」を洗練させるほうがいいかなぁとか。
そのために定量化が必要になるのが政治的な要因以外で、定量化がベストなら選択せざるを得ないかもしれませんが。

今春まともなエンジニアになりたい人が読む12冊+α

今春まともなエンジニアになりたい人とはつまり僕のことです。

ちなみに最近まで読んでいたのはこっち

→「ソフトウェアテストを勉強しはじめて10ヵ月でやったこと - うさぎ組」

読み返すのも含めてこれらをしっかりと読もうと思ってる書籍をあげてみます。
最後のほうにOOPの設計系の書籍について補足を書いておきます。

CleanCoder

まだ半分くらいまでしか読んでいませんが、宣伝の通り全てのソフトウェア開発に関わる人に読んでほしいと思わせますね。

Clean Coder プロフェッショナルプログラマへの道

いかにして問題を解くか

数学を題材に扱いながらも一般的にどのように目の前の課題を解決しようとするかについて書かれています。気分的にはある手法の説明のために数学で書かれいているかGroovyで書かれているかの違いくらいに思っています。

いかにして問題をとくか

継続的デリバリー(予約受付中)

どのように自動ビルドを進化させていくかについて語られている非常によい書籍です。これが全てではないですけど、かならず読んでおきましょう。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

SQuBOK

品質について確認し直したいので。読み直します。

ソフトウェア品質知識体系ガイド―SQuBOK Guide

Jenkins

継続的インテグレーション入門買うよりこっちのほうがオススメです。Jenkinsだからではなく、結局「ある目的のためにJenkinsならこうする」って書いてあるに過ぎないので。

Jenkins

インターフェイス指向設計

@bleisさんにオススメされたので買ってみました。楽しみです。

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践

エリックエヴァンスのドメイン駆動設計

ザックリと読んだのですが、もっと実際にモデリングしながらとか読んでみようと思います。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

システムアーキテクチャ構築の原理

最近、テストのアーキテクチャに興味があるので、この原理でも当てはめられるか試してみようと思います。読み直す！

システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践)

エンタープライズ アプリケーションアーキテクチャパターン

だいぶ前に読んだきりでなかなか読み返していなかったので。もう一度読み返して感覚を取り戻したいです。

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)

ソフトウェアテストPRESS 総集編

テストと言えば！今回読み直すときにはそれぞれにコメントを書いてみようかなぁとか思いました。

ソフトウェア・テスト PRESS 総集編

Making Software

社内でも出来そうなことがのっているので、参照しつつ読み直しつつやってみようかと思います。

Making Software ―エビデンスが変えるソフトウェア開発

ビューティフルテスティング

こちらも社内で試せそうな事がいろいろ載っているので参照しつつ読み直しつつ。

ビューティフルテスティング ―ソフトウェアテストの美しい実践 (THEORY/IN/PRACTICE)

OOPの設計でもし悩んでいる方がいたら個人的には次の流れがオススメです。

結城浩のデザインパターン

増補改訂版Java言語で学ぶデザインパターン入門

実装パターン

実装パターン

CleanCode

Clean Code アジャイルソフトウェア達人の技

アジャイルソフトウェア開発の奥義

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

エンタープライズ アプリケーションアーキテクチャパターン

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)

エリックエヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

みなさんがオススメする書籍はなんでしょうか？

Jenkins勉強会、DevLOVEに参加してきました

5/20にJenkins勉強会、5/21にDevLOVEに参加してきました。

Jenkins勉強会

Jenkins勉強会は第３回ですが、こちらはなんとか皆勤賞を維持しております。
今回のテーマは「LL」ということで、LLでJenkinsを使っている方々のお話がメインでした。
Jenkinsはどの言語で使えるように拡張されていっているので、いろんな使い方があって面白かったですね。
セッション中にも質問したのですが、Jenkinsのビルド実行をVCSに対してポーリングしている方が多かったので、
「出来ればpush駆動にしましょう！」と思います。
ビルド実行だけであればVCSでフックをしてwgetコマンド使うだけで出来ます。
例えばMercurialだと.hg配下にhgrcファイルを作成して次の２行を書くだけ。

[hooks]
incoming = wget -q -O nul http://localhost:8080/job/Rabbit/build?delay=0sec

※Rabbitはプロジェクト名で置き換えてね！

RemoteAPIを使うまでもないのでぜひやってみてください。Windows環境ならGowとかGnuWin32とかダウンロードすればおkです！

※というかさっさとこの続きを書かないとですね。。。→MercurialのコミットでJenkinsにGradleでビルドさせたりする。構成説明編 - うさぎ組

この勉強会でid:irof さん、@mike_neckさん、とお会い出来て楽しかったです。（mike_neckさんはなんと当日にTwitterでGroovyトークで知り合ったばかりという。。。

TLでid:mzp@mzpさんと「Jenkinsの起動をどうやってフックするのか？」という質問を川口さんにぶつけてみたところ、
「JENKINS_HOMEにinit.groovyを置けば実行されますよー。」と教えてもらえました。あとアノテーションで@intializeほにゃららを指定してもいける！と聞いたのですが、忘れてしまいました。あとで調べますね！
init.groovyはid:kiy0taka@kiy0takaさんが以前に発表していたという。。。すいませんorz
twitter:71550337072381952:tree

懇親会ではたくさんGroovy布教をしました！あと、WindowsユーザーならMercurialでしょ！とか。（あれ？Jenkins。。。

DevLOVE HangarFlight - Spring Bomb -

Jenkins勉強会から帰宅してから申し込んだのですが、行けてよかったですねー。
当日はすっかりDevLoveを忘れていて、１時間半くらい見逃すという事態に。。。

id:t_yano@t_yanoのJava聞きたかった。というかサインもらいたかった。。。
TLを追っていると、Javaらしさ。というt_yano@t_yanoの明確なメッセージがあって、僕も同意ですね。「冗長性を残したままOOするのがJava」だと思います。

会場に到着してぶらぶらしていると、なんと、id:fumokmm@fumokmmさんのフォロワーで僕の事を知っているという@yenjojiさんに話しかけられるという。Groovyに興味があるとのことで。id:fumokmm@fumokmmさんネットワークおそるべし！

id:kanu-orz@kanu_さんのTrac話を聞けてとても勇気が持てましたねー。TracにしろRedmineにしろツールですし、それをうまくやろうとすると自然とスクラムというかタスク粒度について気づかせる部分が出てきます。
チームが小さいと比較的楽なのですが、それを浸透させるって難しいと思います。ですが、id:kanu-orz@kanu_さんの「Tracでも３年」「Tracをここまで社内で浸透させるのに３年かかりました。難しいんですよ。」という言葉が心にしみましたね。
がんばります！

id:shot6@shot6さんのエンジニアリングやキャリアについても大変勉強になりました。
とくに勉強の仕方ですね。勉強の仕方というと、id:Akineko@akinekoという秀才がいるわけで、やはりこの方面の手法というか、アドバイスって非常に参考になるんですね。
shot6@shot6さん曰く「モチベーションを保ち続けるのって難しい。とくにソースコード読もう！とか意気込んだあととか。だから、モチベーションが高いときにモチベーションが低くなったときのための事を考えておくのがいいです。ちょっとした簡単な宿題みたいなのを設定したりとか。」
なるほどなーって思いましたね。今度から実践してみます！

ここまでで、やっと？@kimukou_26さんに話しかけてもらえました。いつも僕の事を褒めてくれるとっても優しい人です。
あと、@leather_soleさんにお会い出来ました。いやいや、すごいビックリですw　普段ほとんどリプライしないのですが、やはり実写アイコンにしておくと覚えてもらえるのですねー。（普段のツイートが変態とかは関係ないはず。

で、id:heroween@heroweenさんと知り合いました。実はJenkins勉強会にもいらっしゃっていたとか。とか。PHPユーザーだったけど、挙手できなかったという話を暴露してくれましたw　（Jenkins勉強会でPHPセッションがあったので、発表者から「PHP使っている人は？」との質問に誰も手をあげない会場というシーンがありました。

多分この日はid:heroween@heroweenさんと一番たくさんお話してた気がします。うさみみにつきあってくださり本当に感謝感謝でございます。

その後、この日のふりかえりーということで５人で１グループになり、お題に対してみんなで答えながら話すということをやりました。
僕のグループはHさん、id:absj31@absj31さん、@papanaaさん、あとAさん（お名前忘れてしまいました。すいません＞＜）でお話しました。
id:absj31@absj31さんから「一部で有名なきょんさんですよね？」とか言われてすごいビックリしましたw　あとで見たらフォローされていたというw　すぐさまフォロー返しましたのぜ！
僕は今なんちゃってスクラムをやっていますよーというお話とか士気の低いメンバーをどうやって引き込むのかについて勉強したいです！というお話をさせていただきました。
皆さんがとても意識が高いので、お互いの話を真剣に聞いていて、楽しかったです！

最後は@jojoAtHanawaさんのセッションでした。見ていて、なんという士気の高さ！！！と驚くばかりでしたね。
うむぅ。。。先人を馬鹿になんてしたことはありませんが、改めて尊敬しました。すごかったです。。。

そしてお待ちかねの懇親会。最初はid:heroween@heroweenと話していましたね。転職とかスクラムとか。そして、ここでid:bleis-tift@bleisでつながるという。さすが天才テライケメン伯爵です。有名人ですね。

その後、デザイナーさんとお話しました。デザイナーが低い位置に見られていて大変とか。昨日、ツイートしたのですが、テストエンジニアとかデザイナーってシステムを動かすために絶対に必要な要件を必ず洗い出す役割があるので、プログラマーはもっと見習うべきだなーと、ソフトウェアテストを勉強していてよく思います。

最後にPF（プロジェクトファシリテーター）の@j_matsumotoさんがお話している輪に合流しました。
とても参考になりました。
僕は「質問の仕方」が重要だと思っていて、質問の仕方によってお互いの気づきが増えると思っています。質問したい内容を考えることで解決できてしまったり、相手により理解を促す質問だったりと。
それで周りに接するときには「自分がこう質問したりするともっと解決につながりやすくなるよ！」っていうのを相手にしているようにしています。
そうすると相手も同じような方法で質問してくれるんですね。
@j_matsumotoさんがおっしゃっていたのは「そうやって返してくれるのは相手がそれで気持ちよくなったからだと思うよ。いい傾向。」と。
つまり、何も変化がないということは相手に不快な思いをさせているかもしれませんね。うん。
PFは一要素であり、それを職業にすべきかどうかは別ですが、心理学的要素の多いロールだなぁと強く感じました。（むしろ当然のことばかりなのかもしれませんが。

荷物とりに行ってたらなんかDevLOVEスタッフとid:heroween@heroweenさんにつかまり、なぜか僕が「Groovyで50分間ライブコーディングやる」という話にw　そんな技術力がほしいです。（切実に。

で、最後に@wknarさんとご挨拶。@mike_neckさんのご紹介？で知り合ったのですが、なんでか遠くから僕の事を発見されてしまい、懇親会でお話したかったのですが、なかなか出来ず後片付け時にご挨拶しました。PHPやっているらしいですが、これからどんどんGroovyで仲良くなりたいですね！（お

まとめ

えっと、とりあえず宣言としては
Jenkins勉強会で発表したい！
GroovyとかソフトウェアテストについてUSTか勉強会したい！
もっとサクッとあつまって軽く勉強するとかいいよね！
の３点です。
皆様にかなり刺激をもらえました。自分が如何に「なんちゃって」なのかっていうのがわかります。
上の３つも「初心者だけどこうやってみてます。なんなら一緒に勉強しませんか？むしろ教えてくださいませんか？」的なノリでございます。
これからもよろしくお願い致します！

Enjoy Your Development!