IntelliJ IDEAハンズオンに参加しました #ideahandson #jbugj
サムライズムさん開催の、IntelliJ IDEAハンズオンに参加してきました。
今月はあと一回、3月24日にも開催されるようです。
開催予定イベント一覧 - 株式会社サムライズム | Doorkeeper
まとめも兼ねて、特に「へー！」と思ったものをご紹介させていただきます。（使ってる人には常識なことなのかも…）
Shift2回押しの検索が強力
今までClass検索くらいにしか使っていなかったのですが、もっと「なんでも検索できる」機能です。
例えば、エディタの行番号表示はどこでONにすれば… というとき。
"line number"などで検索すると…
その場でON/OFFの切り替えまでできちゃうよ！
また、キーワードの一致もとても柔軟。
「Get"なんとか”Timelineクラス」を探したいんだけど…という時は
さらに『ght』でもGetHomeTimelineクラスが探せる！
Live Templates と Postfix Completionが楽しい！
psvm と打って tab で public static void main(String[] args) メソッドが。
sout と打って tab で System.out.println() が自動的に入力されます。
さらに、
あー 左に戻って返り値用の変数宣言しないと… というとき。
末尾に.varとつけてtabで…
↓
宣言を自動補完！
同様に、
コレクションに .for と打てば for文が、
booleanに .if と打てばif文が自動的に生成されます。
Live Template, Postfix Completion ともに、非常に多くのものがデフォルトで登録されている上、独自のカスタマイズも可能です。
「巻き戻せるデバッガ」Chronon
デバッガを使ったデバッグをしている時に、「あー 行き過ぎたー！！」という経験、ありますよね。
そこでStep overどころかStep backwardを提供してくれるプラグイン、Chrononです。
IntelliJ IDEA 13.1 EAPのChronon Debuggerをお試しください！ | JetBrains ブログ
本来は有償ツールですが、IntelliJ IDEAのUltimateを使っている場合は無償で利用可能とのこと。
普通のデバッガも強力
標準で付属しているデバッガも強力です。
ぱっと見わかりづらいのですがこの「電卓」ボタンを押すと起動できるEvaluater.
単に変数の現在値を確認するだけでなく、例えば.toString()をつけてみるなどの評価「式」が記述可能。
さらに、= で代入文を書けば、変数値を任意の値に変更することも可能です。
おまけ：「保存」がない
IntelliJ IDEAは常にオートセーブのため、ほかのテキストエディタにあるような「保存」機能がないそう。
今までなんとなくCtrl+Sを打っていたのですが意味がなかったのですね…。
jshellを使ってみた
ちょっとしたプログラミングに、jshellを使ってみました。
jshellとは、Java9から導入される、簡易実行環境。REPLっていうらしい。Rubyでいうirbに相当します。
使ってみた感想。
良いところ
・ワンラインサクッと書いて動かせるのは便利。自分は未だにJava8のStreamAPIとかLocalDateとかうまく書けないので、一行単位でいろいろ試せるのはよかった
・/openコマンドで、ファイルに書き出してあるスクリプトが読み込めるので、スクリプト言語のような実行の仕方ができる。
使いにくいと思ったところ
・importが大変。IDEじゃなくて適当なテキストエディタで書いていたのだけど、いちいちパッケージを調べないといけない。
・/openコマンドで100行くらいのものを読むと、エラーがどこで起こっているのかわかりにくい。エラーの行番号が出ない。クラスを作り始めるともうわけわからん。
・jshellに限らず他のREPLもそうみたいなんだけど、メソッドチェーンを書きたければ改行前にドットを打たないとシンタックスエラーになる
などなどありまして、1-2行を試すのはいいけれど、100行くらいのものを動かしたかったら、おとなしくIDE使って書いて、junitでキックするなり、普通にmainメソッド作るなりして動かしたほうがいいのかなぁと思いました。
全然いいコードじゃないけどこんな感じ
https://github.com/taichiw/baseball/blob/master/201603pitcher/makecalendar.java
XP祭りに参加してきました 2 LTした／LT聞いた #xpjug
俺も！LT
昨年に続いて今年も発表させていただきました。
自分の中では痛恨の失敗作…
言いたいことを一つにまとめられていないのがずっと不安だったのですが、案の定、伝えたい事がうまく伝えられなかったのかな という感触です。
言いたかったこと
- E2Eテストを作りこんで、リグレッション0にした （自動テストの話）
- E2Eテストを作るのをフローにしたら、メンバーの意識が変わってきた （チームビルディングの話）
- GUI作るチームに移って困ってる。誰か助けて （ヘルプがほしい話）
自分の中で本当に話したかったところはチームビルディングの話、しかも自分の中では、「エンジニアである自分」と「管理職である自分」が融合した瞬間だった という話なのですが、XP祭だしあんまりチームビルディングよりな話するのも微妙かなぁ… ということで、先ほどの「～融合した」みたいな話には触れず、自動テスト寄りにしてしまった結果、中途半端な話で終わってしまった感がありました。
そして！ この後の方々のLTを聞いて、「LTとはこうであろう」というものをまざまざと突きつけられたのです。
ネタに走る必要はなかったけど言いたいことだけ詰め込んでもしょうがないなぁ… っていう、去年も思ったことをまたやってしまった。
修行不足ですね。
みんなのLT
まさかの一番バッターだったので、自分のが終わったあとは存分に皆さんの発表を楽しませていただきました！
ぐっと来たものを紹介させていただきます！
スクラムマスター2ヶ月生がチームの自己組織化に挑戦して：川鯉 光起さん
奮闘記。「お試し期間」って話が出てきて、すげえわかるなー！って思いました。
私も新しいことをチームでやりたい時、「2週間だけやらせてください！ ふりかえりの時にどうだった？って聞くから気に入らなかったらその時言って欲しい」 って何度かやったことがある。
俺も！「老害」 公開版 from ESM SEC
タイトルからぶっ放しすぎだし、「これぞLT」を見せつけられたLTでした。
すごく良い発表でした。まさかの「総務」話。
KPTを使ったふりかえりで、どんどん良くなっていったっていう話。アジャイルプラクティスは開発以外にも使える。
発表者の方が、「細かいことは覚えていない → これってカイゼンが日常化しきたってこと」って言われていたのも印象的でした。
今は当たり前のようにやってることが、ふと振り返るとカイゼンの中で生まれてきたことで、ちょっと前までは全然やってなかったこと… って言うの、私も経験あります。
正のループと負のループが8の字になって… という話。
テストのコストが増えて云々の、負のループが表面化してくるところとか、そこからどうするのか！？ とかすげー気になる…！ のだけど懇親会いけなかったので話せず。
是非続き聞きたい。
てらひでさん
デイリースクラムで、
昨日◯◯やりました → 今日も◯◯やります → 特に困っていることはないです
みたいな流れになって困るので（すげーわかる！）
昨日やってること → その中で困っていること → 今日やること
の順番で話してください！ って言った話。
カイゼンネタのストックとしていただきました。ここぞというタイミングでこれ使ってみたい。
…ということで。
自分のLTの失敗も含めて、学ばなければいけないことが大量にあることに気付かされた一日でした。
前夜、緊急の深夜メンテで、果たして行けるのか！？という状況だったのですが、会社で3時間仮眠してから（会議室はなかなか快適でした）の強行参加、してよかった！
XP祭り2015 に参加してきました 1 （講演・ワークショップ） #xpjug
今年もXP祭りに参加させていただきました！
7月まで仕事もプライベートもバタバタだったのもあって、久しぶりにまともな勉強会に参加した感じ。
たくさん刺激を頂きました。
基調講演
角さんの基調講演。
一番ググっときたのはこれ。
TDD - ときめき駆動開発！
語呂が良かったからか、このあと一日バズワードみたいになっていましたが、ここにこんまり先生のトキメキという言葉を持ってきたのすごい。
このスライドで上がっている、「プラクティスの選定」にしても、ときめくかどうかって非常に重要だと思うんですよね。何かしらの課題を抱えていて、それを解決してくれるかもしれないものに出会った瞬間にときめく！はずなので。
ときめきっていう言葉の選定にときめきました。
ところで、「エクストリームプログラミング」。昨年のXP祭りで これも読まずに何を俺はXP祭りに参加してるのだ… と思って購入したのに（第2版が出る前だったのでAmazonで売ってた古本を購入した）、未だに浅くしか読めてない… 読まないとなぁ…。
ワークショップ ”共感”でつながるアジャイルチーム
ゴゴイチはワークショップに参加。裏も気になるものばかりだったのですが、こういうの選ぶあたり、現状で自分の興味が強いところは、チームビルディングとか人と話すとかそういうところなのかなぁ…。
【楽天ブックスならいつでも送料無料】NVC人と人との関係にいのちを吹き込む法 [ マーシャル・B... |
共感コミュニケーション とは、マーシャル・ローゼンバーグ博士によって提案された、相互理解を深め、自分や相手とより繋がるためのコミュニケーション「プロセス」 で、次の4段階のプロセスからなるそうです。
４つのプロセス
1．観察
ビデオカメラのように事実のみを観察する
2．感情
自分／相手が感じていること
3．ニーズ
何を必要としているか
例えば、イラッとしていたら何か満たされないものがあるのではないか
4.リクエスト
具体的なお願い。かなわなくてもいいのでしてほしいことをクチに出して言う。
今回のワークショップでは、2の感情 と 3のニーズ の部分について行われました。
左側の「感情」と右側の「ニーズ」を結びつける練習。
例えば
- 私は基調講演を聞いて「ワクワクした」。なぜなら、「刺激がほしい」というニーズが「満たされた」からだ
- 私は基調講演を聞いて「ショックを受けた」。なぜなら一部理解できない話があり、「情報や知識がほしい」というニーズが「満たされなかった」からだ
というように、どのように感じているか、という感情から、その感情の元となるニーズを探ることで、自身／相手が欲しているものは何か ということを探っていくことをしました。
一般的に、ポジティブな感情の裏には、なにかニーズが満たされた という事実があり、逆にネガティブな感情の裏には、なにかニーズが満たされなかった という事実があるそうです。
初めは自分自身の感情に対してこれを行い、次に、他の人の話を聞いて、その裏にある感情とニーズを探る という訓練を行いました。
さらに、ふりかえりも、「◯◯と感じた。なぜならば◯◯だからだ。」の形式で行われました。
こういったことは、普段からある程度無意識にやっていると思うのですが、プロセスとして体系立てて学ぶことで、改めて自分の中で手法が整理されると感じました。
NVCの本、アマゾンの書評を見るとなかなか骨のある本のようなのですが、読んでみたいなぁ…
ユーザーストーリーマッピング入門
弊社アジャイルコーチ、川口さんのセッション。
【楽天ブックスならいつでも送料無料】【高額商品】【3倍】ユーザーストーリーマッピング [ ジ... |
川口さんが監訳された『ユーザーストーリーマッピング』について。
スクラムのプロダクトバックログには、
・今どこにいるかがわかりにくくなる
・チケット間の関連性が見えづらい
・長めマイルストーンが見えづらい
などの弱点があり、それを解決する方法としてJeff Patton氏がユーザーストーリーマッピングを考案したという話。
この弱点、私も感じる所あるのですが、何より、ここ数年一緒に仕事をさせていただいている、自分よりベテランな方数名が、こういうことを言われている気がする… というところでググッと惹かれました。
周りの皆さんが読んでいる中、取り掛かれていなかったのですが、読まないとなぁ…
モデリングもしないでXPとは何事だ
モデリングというものをちゃんと勉強したこと無いながら、ここ数年間、ちゃんと勉強したほうがいいんだろうなぁ… と思っている昨今。
「モデリングとは？」のような話はなかったので、自分にはちょいハードル高めだったのですが、最近会社でよく先輩から教えられている、「issue driven」な考え方にとても通ずるものがあると感じました。
なにか新しい機能を考える際に、いきなり「方法」にいくのではなく、そもそもの問題から考える流れです。
普段なかなかできていないので、もっとこういう考え方を身に着けていかなくてはと感じました。
そしてモデルそのものも、知識としてもっと知りたい…
ということで あの本ちゃんと読まないと とか ここちゃんと勉強しないと とか 自分の不勉強さばかり気になった一日でした。
ちょっと辛くなりかけましたが、ちょっと寝ぼけていたところにたくさん刺激を頂いたということで、早速エクストリーム・プログラミングを読み返すところから始めました！
今日は、チーム9人全員で「プライベートメソッドのユニットテストは書くべきなのか？ ディスカッションができた」記念日
今日はとても素敵な一日になりました。
私を含めたチームメンバー9人が、一つの技術的な話題に対して30分話し合う会を開けた日。
何より嬉しかったのは、この会そのものが、メンバー間でのやり取りからほぼ自然に出てきたことなんです。
回想：本当に「スモール」だった時期
私の今のチームは総勢9名のチームなのですが、大まかに分けても4種類くらいののサービス（検索から予約、管理画面も。）を担当している、プロダクト的にはかなりマッチョなチームです。
これらのサービスはどれも「似ている」のですが、歴史的にバラバラに作られてきたため、アーキテクチャやフレームワーク、コードの思想は全部バラバラです。
以前は、このバラバラなプロダクトを、チーム内でもバラバラに担当がついていて、2～3人の少人数チームが3つ、という状態でした。
「似ている」ものをバラバラに作っているので、同じようなものをお互い作っていたり、同じようなことでお互い困っていたり。
しかも1つ1つに対して、到底足りない人数で必死にサービスを回している。
なんとかこの状況を変えたい、という思いで、少しずつ少しずつ、バラバラだった組織を混ぜ始めました。
初めはデイリースクラムも、振り返りも、3回ばらばらでやっていたのを、ちょっとずつくっつけてみたり、隣のを覗いてもらったり。
お仕事も、少しずつ隣のプロダクトを触ってもらったり、コードレビューしてもらったりしていました。
いい感じで衝突し始める
さて、気づけばすっかり一緒にやるのが当たり前になった我がチームのふりかえりミーティング。一昨日のミーティングでこんな意見が出ました。
「ユニットテストで使うライブラリや、書き方を統一したい。人によって違いがあることで、問題が起きた」
ｷﾀｰｰｰｰｰｰｰ!!
以前は2～3人でキレイに分担されていたのが、どんどん混ぜこぜににされている昨今。当然こういう衝突は起こりますよね。
解決すべき問題なので、Tryとして、改めてみんなで話し合う場を後日持ちましょう！ ということにしていたのですが…
コードレビューでもぶつかる！
その翌日、さらなる『事件』は起こりました。ある案件のコードレビューで、「プライベートメソッドのユニットテストは書くべきではない」というレビューがつけられ、これに対してレビューイから「自分は書くべきだと思う」という『反撃』がありました。
おそらく自分がこのチームに来てから、コードレビューで『反撃』を見たのは初めてだったと思います。
これ以外は
「◯◯に直してください」→「直しました」
しか本当に見てこなかったような。
ユニットテストについて話し合う場を持ちましょう といっている矢先に こんなホットなトピックが起こったのですから放っておく手はありません。
第一回ユニットテストについて議論する会 という会議依頼を勝手にメンバーに送信。
議題は、「プライベートメソッドのユニットテストは書くべきなのか？」です。
みんな意見は持っている
きっと落とし所は見つからないだろうな と思っていたので、今日の私の目標は、とにかくみんなに意見を出してもらって、お互いの考えを知ってもらうことでした。
はじめに、皆さんどっち派ですか？と聞いたところ、ちょうど半々くらいに。いい具合に、コの字型の素敵なソファーのオープンスペースでミーティングしていたので、左と右で別れて座ってもらいました。
とっさの思いつきでしたが、各自の立ち位置が可視化されて（そしてちょっとテレビのバラエティ的なおもしろさもあって）、これは良かったと思います。
はじめは言い出しっぺの彼に「なぜプライベートメソッドにユニットテストを書くべきではないと思うのか」を話してもらいました。
それに対して、「賛成でも反対でもいいけど、彼の言っていることの意味はわかりましたか？」と確認したうえで（＋私からちょっと補足したうえで）、意見がある人に、自由に発言してもらいました。
そこからは、賛成も反対もどんどん意見が出る出る。
どうしても声の大きい人と物静かな人がいるので、さり気なく全員一回は話してもらえるようにちょっと振りつつ、皆さんに意見を出してもらうと…
・あれ、賛成派も反対派も同じ事言ってない？
・そもそもPrivateメソッドって何よ？
・俺のPrivateメソッドとお前のPrivateメソッドと、サイズが違う…？
・実はPublicとかPrivateとかが問題では無いのでは！？
という感じになってきたところで30分終了。もっとまとまらないと思っていたのですが、いい感じで次に繋がるトピックが出たところで終了したのでした。
なるべく自分の意見は入れずにファシリテータに徹してたつもりなんですが…
すげー楽しかったなぁ！
チーム異動があって、「ふりかえり」が自分の中では一番大事だと気づいた話
2月の半ばに組織改編があり、新しいチームにリーダーとして異動しました。新しい環境で試行錯誤する中で、自分がチームビルディングにおいて大切に思っているものが見えてきたので、それを書き残しておきたいと思います。
数回に分けて書く予定ですが、そう宣言しておいて続いた試しがこのブログでは無い…
ふりかえりのためにタイムボックスをセットした
異動してチームメンバーに初めにさせてもらったことは、二週間のスプリント切りでした。
今日から2週間で一旦区切らせてください、というお願いです。
「アジャイルな開発」をするため？ 多分違います。
計画を立てて実施しきるため？ それも違います。
理由は一つ。「ふりかえりをするため」です。
私は、チームが自分たちのやり方やスキル、チーム力を高めていくために、短いサイクルでの定期的なふりかえりが、最も大切と考えています。
ですので、私の新しいチームのメンバーには、定期的な間隔でふりかえりがあること、そしてその場では、自分たちの問題を自分たちで発見し、自分たちで解決までのプロセスを考えてよいことを知って欲しかったのです。
そのためのスプリント切りでした。
一方で、最初のスプリントの”計画は”、ややゆるめに、「今までの流れで、もともと、むこう2週間でやろうと思っていたことを、この2週間でやってください」と伝えるに止めました。
今回の異動では、もともと存在していたチーム・案件に、私一人が新参として入った状況です。一番プロダクトのことも案件のことも分かっていない私があーだこーだ言うよりも、基本的にはもともとみなさんがやられていたやり方を継続してもらう方がいいと考えました。
たくさんKeepやProblemが出てきたふりかえり
ふりかえりミーティングでは、「全員に参加」してもらうために、Keepと Problemのパートでは順番に一人一人思っていることをあげてもらう手法を取りました。また、私が強めのファシリテーションをし、あげてもらったものに対して深掘りすることもしました。
「○○ができてよかった」→「それができた要因ってなんでしょう？」
「○○で困った」→「本質的には何に困ってたんだろ？」「そういうことが起こった要因はなんだろう？」
という具合です。
嬉しかったのが、みなさん、たくさんのKeepやTryを上げてくれたことでした。初回は一人当たり、2つ以上のKeepとProblemが上がったような気がします。
私が異動してから5回ほどふりかえりを行いましたが、今でもこの傾向は続いていて、嬉しい限りです。
また、ProblemからTryに落とし込む際も、真剣に考えてアイディアを出してくださっている印象があります。
このチームはこれからどんどん、自分たちを自分たちで良くしていって、強いチームになっていくと思います。
テストを整備するよりもアーキテクチャを変更するほうが効果が高そうと思った話
2月の半ばに、これまで3年弱携わらせてもらったプロダクト／チームを離れて、新しいプロダクトを担当することになりました。
プロダクト面での一番大きな違いは、これまでは主にデータ更新／参照系のAPI（HTTPでコールして、JSONとかXMLとか返す）ばかりを担当してきたのですが、今回担当させていただくことになったプロダクトはいわゆる普通のWebアプリケーションで、「画面」があります。
これまでは担当プロダクトがAPIだったので、EndToEndテストの整備もある程度いい感じにできてきていて、リグレッション系の不具合はほぼ0！という素晴らしいプロダクトとチームを作ってくることができました。
しかし今回、テストすることが難しい「画面」をサービスとして受け持つことになり、どうやって品質を保っていこうかなぁ… と思っていた矢先、早速、リグレッションにあたってしまいました。
ちょっと前の案件で、直さなくていいところまでJSPを直してしまっていたそうです。
ロジック周りがどれだけちゃんとしていても、最後の最後にViewでバグられたら回避方法無いじゃん… と悩みました。
エンドツーエンドテストで細かくテストできるか
ここで一旦、Seleniumなどのツールでで細か目のエンドツーエンドテスト（＝イメージ的には画面レベルのユニットテスト）と思いました。
ちょうど一ヶ月ほど前にGebというものを覚えたこともあり、GebというかSpockのデータテーブル機能が、いろんな組み合わせのテストケースを並べるにはイケそうじゃん！と思ったのですが…
ダメだこれ、遅すぎる。
メンテナンス性がー とか HTMLが古くてタグにIDすら振られてねー
とか言う以前に、自分のやろうとしているテストをやろうとしたら、どれだけハイスペックなマシンを使っても埒が明かねーなこれ、という結論に至ってしまいました。
そんなのよりアーキテクチャ変更なんだろうな
結局Viewに近いところのバグを減らすためには、Viewにロジックを持たせないことなのだろう
という結論に至りました。
