日々常々

ふつうのプログラマがあたりまえにしたいこと。

SpringBoot2.0がリリースされたのでバージョンアップしてみた

spring.io

待望のSpringBoot2.0がリリースされました。 ので早速バージョンアップだー。

やったことといえば、 build.gradle のビルドスクリプトプラグインのバージョンアップだけ。 Spring Boot Gradle Plugin Reference Guide に書いてる通りですね。

- id 'org.springframework.boot' version '1.5.10.RELEASE'
+ id 'org.springframework.boot' version '2.0.0.RELEASE'

そしたら javaio.spring.dependency-management が外れるので、追加。

+ apply plugin: 'java'
+ apply plugin: 'io.spring.dependency-management'

対象のプロジェクトは spring-boot-starter を使ってるだけのやつで、超シンプルなやつなのでこれだけで完了しました。 application.properties にSpringBootのことは書いてなかったんで、そっちがどう変わったかはみてないです。とりあえず軒並みキーは変えなきゃいけないはず。

SpringFrameworkも4から5に上がるわけだけど、コンパイルエラーとかにもなんない。流石にこう言うところは安定してるなー。

変わってたとこ

なんかあったらメモがてら実装してこーかと思って。

github.com

application.properties の空白文字の扱いが変わってた。

プロパティファイルの空白ってどう言う扱いなんだっけなと軽く探してみてみたけど、 Properties (Java Platform SE 8) くらいしか見つけられず。 そもそも Properties#load で読むのと SpringBoot1.5で application.properties を読むのとでも違うので、まあ、うん。

とりあえず application.properties で値に空白文字(スペースやタブ)を使用してたら、 String#trim されるんで消えちゃいます。 これは新しいプロパティを読むクラスで実装されてるので、 PropertyPlaceholderConfigurer. setTrimValues(false) とかしてみても意味ないです。

ちなみにapplication.properties ではなく、コマンドライン引数とか application.yml とか、他の手段で設定すれば特に関係ない話です。 どうしても application.properties でないとダメなんだーとかでもなければそちらで対応できるやつです。

もともとが正しいとも言いづらい(IDEが警告だすような記述なわけだし)ものなんで、仕様外の話かなーと。

ベタープログラマの第一部を読んだ

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

ベタープログラマを読もう - 日々常々で5,6,8,11,13章を読むと書きました。 実際2,4,5,6,8,11,13章を読みました。2つほど増えてますね。

雑感

部タイトル

you.write(code) って codeyou に書かせてる? you は渡された code をそのまま書くのだろうか。仮にそうだとしたら you の型って何なんだ・・・プログラマではなさそう。もし渡した code がそのまま書かれないとしたら write メソッドって名前はどうなのってなっちゃうし。ところで code は誰が生成するんだろう。 you かしら?だとしたら code 生成と codewrite で分かれてる? 流石に code って変数名で型がコード的な何かじゃないってことはないと思うし・・・

2章

vimが最善です。それがすべてです。

のっけからこれ。こう言うことを書いてる本ってのがわかりやすくていいと思います。客観的な正しいっぽいことが書いているのではなく、著者が好きに書いている感じがします。

グッドリフの法則

「コードのレイアウトに関するすべての議論は、白熱すればするほど、ほぼ実りのない議論になる」

そのとおりでございます。

さて2章は「見かけのよい状態」ってのがどう言うものかを書いてます。 前に書いた 見やすいコードのために出来るたった一つのこと - 日々常々 とか、 "ふつうのJavaコーディング"を話しました - 日々常々 で話したことのいくつかとか、普段話してることと被っているものも多くありました。「そーそー、そう。これが前提、このあたりは議論の対象じゃなく、話したいのはこの先なんだー。」と言う感じ。

4章

まだやりすぎてるところ多いなーと思ったり。「結論を出さなくてもいいように、どうとでもなるように実装しておく」ってのは確かにYAGNIではあるなーと。小さいものでも不要な作り込みは不要なわけだし。

実装する前に話すのがいいってのはわかるのだけど、でも机上の空論するなら実装しちゃったもので話したほうがいいよなってのもよくみるので、この辺は意図しての使い分けかなー。

5章

自分の古いコードを読んで、そこから学ぼう、といった趣旨。

思い返してみると、自分の過去書いたコードをみる機会って案外少なかったです。長期プロジェクトは多かったけれど、プロジェクトの間にコードが変わることは少なかったかもしれない。プロジェクトが変わるタイミングでコードも変わってた感じがする。なので以前携わってたプロジェクトのコードを見たときに、ここで書いているような経験になってたかな。git以降は普段のコードを見返す機会も増えた気がする。ここ最近はプロジェクトの切れ目とかは関係なく自分のコードがころころ変わるので、昔よりも実践できてるかもしれない。

そいや昔から言ってるよなーとログ漁ってみたら

それっぽいのがツイッターはじめた年にあったので、もっと前から言ってそう。

あと「過去の自分は遠慮なく叩ける」とかもしょっちゅう言ってる。コードに限らず過去のブログもいい教材になります。

6章

章タイトルが謎だから読もうと思った章ですね。プロジェクトに途中参画するときにどのようにしてコードにたどり着くかって話を「航路の航行」と名付けている。なるほど。

私は途中参画もそうだけど、新規プロジェクトでも地図を描くことが多いです。地図と呼んでいる何か、ではなくて結構それっぽい地図でプロジェクトをあらわしてみる。システムの境界を海岸線であらわしたり、港や崖を描いたり、わかんないところは雲や霧で隠してみたり。傍目は遊んでるように見えたかもしれない。最近はコンテキストマップを描こうとしてる。他の人との会話に使えそうだから。

ソフトウェア考古学

たまに耳にする、具体的にはどういうものか知らない言葉が出てきた。 Wikipediaだと Software archaeology - Wikipedia とかある。まあ考古学って言うのだから、事実から文化とか状況を読み取るって感じなのだろう。メンテナンスの時によくやってるアレのことだと思う。

8章

「エラーへの言い訳」に反論するの、表面的にはできるだろうけど、反論しきろうとすると難しいなと。章タイトルの「そのエラーを無視するな!」から想像していた内容よりも具体的で強い論調だと感じました。この章は読んでみてほしい。

11章

章はじめはテスト駆動開発から入りますが、話は一応テスト全般をスコープにしてる感じです。考える機会になることがいっぱい詰め込まれてます。やはり話題としては自動テストの比重がほとんどですが。

よくある誤りは、五つのメソッドを持つクラスを見て、(略)個別のテストを五つ必要だと考えること

これを明確に「誤り」と言ってるのは初めて見たので印象深かった。理由も添えられていますが、SUTがオブジェクトとしてあまり役に立たないスメルなのかなーというのが感想。

そういえばIDEでテストクラスを生成すると、メソッドに対するテストメソッドが生成されたりしますね。あれでメソッド作ったことないですけど、ああ言う選択肢がでるのがこの辺を助長してるのかもしれない。

てことで

次は二部。そのうち。。

「現場で役立つシステム設計の原則」の感想

目次流しは以前書きましたが、読み終わってるので改めて。

一緒に開発する人には読んでおいてほしい。可能なら手元に置きながら開発してほしい本です。手頃なサイズ、重量、厚さ、価格ですし。鈍器本系に比べれば持ち運びやすい。実際レビューやペアプロの際、「あの本に書いてるんだけど・・・」という感じで何度か参照しています。

読書会をしてみて

4つのイベントに参加しました。うち2つは輪読形式の読書会で、最初から最後まで読み上げです。有用なのと同時に危険でもある、というのが読書会での感想です。

平易な文章で理解しやすいように思えるのですが、表面だけで理解した気になっていると間違いなく実践で役立たない 、そんな感じです。現場での実践をシミュレーションするだけでも多くの問題にぶち当たるでしょう。そういうのがあっさりした言葉でさっくり片付けられています。このようなことを通じて「ただの理想論」と片付けるのは簡単ですが、残念ながら本書の内容は殆どが実践されているものです。特殊な一つのプロジェクトではなく、複数の会社の複数のプロジェクトで。

実践しないとわからないことが膨大にあり、それを乗り越えてようやくさらっと書かれている1文に届く感じです。読み流せば「ふんふん、まあそうだよなー」で片付いてしまい、簡単に誤解できるし、ややもすれば実践不可な理想論にしか映らないのでタチが悪い。これを危険と言わずなんと言うか。。。

読む際に外すと誤解するポイント

この本は徹頭徹尾「変更を楽で安全にする」ことを書いています。

変更しないものには興味がなく、「どう作るか」ではなく「変更のためにどう作るか」が書かれています。書いていること全てが変更ありきなので、変更しないものや変更できないものに適用しようとしても無理があり、解釈が歪みます。(しかも歪んだまま解釈できてしまう。)

どんな本もそうなんですが、書かれていることはたいていそのまま適用できません。現場のコンテキストに応じて調整する必要があり、実践で学べば方針も変える必要が出てきます。その際に変更できるかは重要で、少なくとも変更できるように作っていなければ変更はできません。得た学びを反映するためにも「変更を楽で安全にする」必要があるわけです。

読み終えて

実は書かれている内容をあーだこーだと議論してもあまり意味がない本なのではないかと思いました。議論すべきは、書かれていることを実践した結果の経験に対してです。なのでコンテキストの共有できない状態で会話すると全く実になりません。話すのならば実践経験を語れる場で、できるならば同じ経験を共有した人たちがいいでしょう。そう言う場で実際のコードと本を突き合わせて話すと、短い言葉の随所に詰め込まれた情報がようやく読み取れます。

噛んでたら味が変わる系の本ですね。

おまけ(半年前のLTスライド)

ddd-alliance.connpass.com

このイベントでのスライドです。新幹線の終電に乗ろうとしたら、山手線を逆方向に乗ってしまって帰れませんでした。ドンマイ。

ベタープログラマを読もう

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

読みながらブログを書いてみようと思いたちました。去年ポチって届いたまま積んでた。とりあえず今回は目次流しして、部ごとにブログ書いていこうかなーとか思ってます。思ってるだけかも。

どんな本かというと

コードを気にかける人の姿勢みたいなものかしらね。著者はCodeCraftと同じPeteGoodliffeなので、読んだことがある人は想像できるのかもしれない。

対象はたぶん「この本が気になる人」と幅広い感じ。それだけに専門的ではない(「はじめに」にもそう書いてる)、エモい方の内容なんでしょうね。では目次を読みましょか。

目次流し

5部、38章で構成されています。全章を書きだすのはだるいので、部単位でざっと書いていきます。

第I部 you.write(code)

部タイトルが you.write(code) とコードっぽく書かれてて素敵ですね。最後まで部のタイトルはこれで行って欲しい感がありましたが、残念ながら最初だけです。そういえばサインをお願いするとこのスタイルでメッセージを書いてくれる方がいて、格好いいなーと思ってます。

各章のタイトルはそれ一言で内容がわかり、「そうそう」と言いたくなるもの。4章の「取り除くことでコードを改善する」とかをドヤ顔で言うといいかもしれません。5章の「コードベースの過去の幽霊」なんかは、削除していないコードに悩まされる話*1かと思ったら、サブタイトルに「過去に書いたコードから学ぶ」なのでどうも口寄せとかそんな感じのようです。8章の「そのエラーを無視するな!」などから思うのは、エラーを主体に取り扱うのは解決策を扱う本や記事では取り扱いにくいのか、あまり見ない少ない印象なので特徴と言えるのかもしれない。ここは読もう。

内容が予想しづらいのは6章の「航路を航行する」と11章の「テストの時代」、13章の「二つのシステムの物語」あたり。ということで、5,6,8,11,13章を読もうと思います。

第II部 練習することで完璧になる

練習と言われるとアプレンティスシップパターンの「練習、練習、練習」はいい名付けだなと思い出します。

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

練習の方法が書かれているのかなと章タイトルを見て見ると、そうでもなさそう。どうも実戦の中で練習するスタイルのよう?「本番でなければ練習にならない」みたいなことを言ってる方もいらっしゃいますし、それはそれでわかります。隔離されたクリーンな環境での練習は、それはそれで役に立ちますが、予期しないことに極端に弱いものですので。さて、この部は14章の「ソフトウェア開発とは」から始まるので、第I部よりは少し俯瞰した感じ。16章に「単純に保つ」などもありますが、3章にあった「少ないコードを書く」や4章「取り除くことでコードを改善する」を受けて実際どうしていくかとかを書いてそう。19章の「コードを再利用するケース」、再利用はいっとき喧伝されていましたが、悪影響も大きいので取り扱いは慎重になるべきところだと考えています。共通化も同じで、前に書いたエントリ*2とかもその一端ですね。再利用について考察されているものはあまり記憶にないので、ケースが書かれていそうなのは期待。あと気になるのは22章の「凍結されたコードの数奇な人生」かな。コード凍結ってよくあるのだけど、バージョン管理システムを前提としてリリースブランチをもつブランチ戦略をとっていれば不要のはずだし、フィーチャートグルなどの抽象ブランチを活用したアクティブメインラインだと凍結したら開発止まるよなーとか思ってて、そう言う点を整理してくれてるのかなーと。あ、20章に「効果的なバージョンコントロール」があるので、バージョン管理システムの活用は前提、のはず。

17章の「頭を使いなさい」は、うん、まあそう言うことなんだろう。この手の本を読む人に改めて言う必要はあるんだろうか。あれかな、本の内容を真に受けて従えばいいみたいなところへの警鐘?ということで、16,17,19,22章を読みましょかね。

第Ⅲ部 個人的なこと

ふわっとした部タイトルが来た。さて各章は・・・あーうん、エモい。読み物として全体をさらっと読むところな気がする。25章「試験に基づく開発者」は別にテスト駆動開発者のことではなさそう。サブタイトルに自動車運転とか書いてるけど、なにを試験と言ってるのかは気になる。あとは26章「チャレンジを楽しむ」や27章「停滞を避ける」などはテーマとしてはよく言われることで、それに対してどう考えてるかって事が書いてるんだろう。プログラミング言語に対する姿勢についてかかれた29章の「言語への愛」あたりは面白そう。複数言語を学びつつ得意言語があるって人は多いと思うけど、そう言う所も書いてるのかな。得意言語とかを考えると、先にもあげたアプレンティスシップパターンの「得意領域へ撤退」が思い出されます。これもいいネーミング。

ちょっと面白いのが30章の「プログラマの姿勢」で、サブタイトルが「プログラマの健康の改善:姿勢、目の疲労、元気の維持」です。心構え的な姿勢じゃなく、物理的な姿勢のようですね。テスト駆動開発でKentBeckが「Cheap Desk, Nice Chair(いい椅子を買え)」と書いていたのを思い出します。

テスト駆動開発

テスト駆動開発

第Ⅳ部 成し遂げる

この部は31章「一生懸命ではなく、賢く」、32章「完了したときが完了」、33章「今度こそ分かった……」の3章だけです。だけどよく似たような事を人に言ってる気がする(自分できてないくせに)。そんなタイトルが並んでるので、全部読むかな。

第Ⅴ部 人々の営み

チームワークについて、この部も少なくて5章だけです。いずれも気にはなるけれど、特に挙げるなら説明責任について書かれている35章「原因は思考」と、36章の「遠慮なく話す」ですかね。遠慮はチームワークを阻害する害悪で、チームメンバーには「遠慮するのがあなたの仕事ですか?」みたいなことをうっかり言ったりしてました。そのまま言うとどう考えてもパワハラなので、いい方はもう少し考えたほうがいい。ってところで35,36章は読もう。

さー読むぞー

この手の本は前から順番に読むのもいいのだけど、つまみ食いして飛び回る(どうせ各章から他の章への言及があるんでしょ?)のも一つの読み方だと思います。ってことで気になる所をピックアップしてみたけど、どうも半分くらい挙がってますね……。これは上で挙げたのを読み終わったら結局全部読み終えてたりするよーな。まあいいか。

てことでぼちぼち読んでいきます。

「現場で役立つシステム設計の原則」の目次流し

本日発売された @masuda220 さんの「現場で役立つシステム設計の原則」が気になってる方へ。

紙の本。

こっちはkindle

まだ全部読めてないけれど、精読するといつ読み終わるかわからない・・・。 なので、まったく読んでない気分になって目次ベースで紹介してみます。 どう言うことが書いてそうかの参考にはなるかなと。

しかしこの内容、よくこのサイズの本で、それほど小さくない字なのに入りましたね。要約力のなせる技なんでしょうか。

目次流し: 期待とつまみ食い

目次をさらっと読んで、こんなこと書いてるのかなーって妄想を交えて書き連ねます。たまに実際開いて。 なお、 「太文字のカギカッコ」 は目次からの引用です。

Chapter1 小さくまとめてわかりやすくする

ソフトウェアはソフトなのに変更が大変になるのはなぜだろう。 これには大きくしてしまった時点で負けと言う原則がある。 大きくせざるをえないものがないとは言わないけれど、小さくする、小さく保つ努力を怠っていい理由にはならない。

このChapterでは小さくあるためにどのようにするかが書かれていそうな雰囲気。 難しい言葉で言えば高凝集で疎結合なのだが、抽象的な話に逸れがちなテーマ。 これに対してメソッドやクラスを作成する上での一般指針や、ファーストクラスコレクションをあげているので、抽象ではなく具象で語っているのだろう。

Chapter2 場合分けのロジックを整理する

組み合わせられるように作成できるのはソフトウェアの強みではある。 一方で簡単に組み合わせ爆発を起こしてしまい、気づいたら制御できなくなっているものである。 C2カバレッジが現実的でないと言われたりする話もある。

このChapterでは、組み合わせを発生させないためにできることを詰め込んでいるようだ。 そんな何でもかんでも組み合わせる必要はない、こうすれば余計な複雑性を放置せず済む、と区分や種別の引力に対峙している。 また、本書はJavaを使っているため、強力な機能であるenumの実践も記述されている。 私自身、増田さんと仕事をさせていただいた時に「enumをそう使えばいいのか!」とショックを受けた。 その内容はわずか2ページにエッセンスが詰め込まれているのだが、このChapterだけでなく前Chapterも理解して身についていなければ、単に「ふーん」で読み流してしまう。

Chapter3 業務ロジックをわかりやすく整理する

神クラスが生まれるのはなぜだろう。 他言語にあるプロパティ構文やLombokが欲しくなるような、getter/setterだけを持っているクラスに何の価値があるだろう。 余計な複雑性を持ち込んでいるんじゃないか。 データとロジックが同じ場所にあることがカプセル化だったんじゃないか。 あれはただの教科書的なもので、実務では使えない机上の空論なんだろうか。

・・・なんて話に真っ向勝負を挑んでいるのが、このChapterの見出しを眺めた印象である。 重要なのは、ここで記載されていることが全て実際のシステムからの知見であること。 また、海の向こうの関わりが少ないものではなく、日本のシステム開発で実践されたことであることかもしれない。 文化が違うから実現できるんだ、ウチではそういうのはできないんだ、なんて言い訳をいつまでも続けるのは難しい気がする。

Chapter4 ドメインモデルの考え方で設計する

増田亨と言えばDDDの人と認識されている方も結構いるはず。 DDDは「エリック・エヴァンスドメイン駆動設計」が有名で、本書が登場してからよく聞くようになった言葉である。

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

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

とは言え「DDD=エリック・エヴァンスドメイン駆動設計」でもなく、増田さんは増田さんのDDDを実践していると思っている。 つまるところ、このChapterは「増田亨のドメイン駆動設計」なんだろうなーと。

見出しを眺めると、エヴァンスの言葉はほとんど使われておらず、むしろ「コト」などの聞き慣れた言葉が使われている。 どう解釈するか、などに悩まずに素直に内容と向き合えるのじゃないかなと。

そして教科書的に済まないのが本書の特徴。 前半で一通り説明したのち、最後 「業務の理解がドメインモデルを洗練させる」 では 「形式的な資料はかえって危険」「言葉のあいまいさを具体的にする工夫」 など、現場で向き合ったこともあります。 現在進行形で取っ組み合いしてるところなので重点的に読みたい。

Chapter5 アプリケーションの機能を組み立てる

サービスクラスを作ると、ドメインモデルの責務がサービス側にうっかり漏れ出して、ドメインモデルが空洞化するなんて話はよく聞くところで。 また、業務システムはデータベースありきな文化も強くあります。 これらの慣習的な作り方の引力への抗い方について書かれてそうな感じがします。

「初期のドメインモデルは力不足」 と言うまぎれもない事実を事実として認め、それからどうするか。 決して"最初から完璧なドメインモデルを作ろう"ではないはず。

Chapter6 データベースの設計とドメインオブジェクト

データベースに関わるよくある問題と、テーブル設計の一般則、そして工夫と言う感じで書かれているようだ。 問題点などはSQLアンチパターンとも絡むのかな(参考書籍にもあげられてるし)

SQLアンチパターン

SQLアンチパターン

「参照をわかりやすくする工夫」 のところでは、当然のようにイミュータブルデータモデルや、結果整合性が書かれている感じがする。 そしてChapter5でデータベースに引っ張られないようにと説明していたはずが、ここで 「オブジェクトとテーブルは似てくる」 と言われてしまい、え?となっているところに 「オブジェクトはオブジェクトらしく、テーブルはテーブルらしく」 と続けてくるのは面白い。

Chapter7 画面とドメインオブジェクトの設計を連動させる

DDDで捉えたつもりのドメインモデルと、画面の要件がズレていることは珍しくない。 そこには色々な関心ごとが混じり合っているから。 画面向けのドメインと実際のドメインが別にあり、それらが複雑に絡み合っているんじゃないか、なんて考えたこともあるのだけれど、そんなことをしているとシステムを作るのに莫大なコストがかかることになってしまうので、違うんじゃないかなーとか思ってた。

このChapterでは 「画面とドメインオブジェクトと連動させる」 として、画面都合のロジックをどのようにしてドメインオブジェクトに記述しつつ、ドメインオブジェクトの独立性を維持するのかが書かれてそう。 なおWebアプリケーションの画面なのでHTMLが前提になってます。

Chapter8 アプリケーション間の連携

流行り?のマイクロサービス的な話がはいってるのかなーと眺めてみたけれど、そのような記述はないです。 ここでの連携は素直にアプリケーション間の連携で、対象はファイル転送、データベース共有、Web API、(非同期)メッセージングを指しています。 その中でも特にWeb APIに重点が置かれているようで、7割くらいはWeb APIの話っぽい。

Chapter9 オブジェクト指向の開発のプロセス

ここで開発プロセスの話に飛ぶのか。 開発プロセスのソフトウェアに対する影響などの一般則から、 ソースコードを第一級のドキュメントとして活用する」 の転換。 そして 「更新すべきドキュメント」 として、現実で必要になるソースコード以外のドキュメントの話。 決してドキュメントは全て不要!なんて言ってないのがわかる。

なぜ開発プロセスの話になるんだろうと思ったので少し先読みしたところ、どうやらプロセスを変えないとオブジェクト指向の開発はできないようなことが書いてそう。 初期のドメインモデルが力不足なのだから、当然と言えば当然で、それを通すためにはプロセスも当然あったようにしないとね。

Chapter10 オブジェクト指向設計の学び方と教え方

リファクタリングオブジェクト指向エクササイズなどなどの話。 これだけで一冊書けるところですが、車輪の再発明ではなく、主に本の紹介で構成されてるChapterです。

全体通して

本を受け取った時は、あれ、本小さくね?軽くね??って思いました。 こうしていざ目次を見てみると、思った以上に広い。そして深い。びっくりした。

タイトルの「現場で役立つ」ですが、実際役立てるかは読んだ方ご自身の責務です。 あたりまえですが、読んでも使わないと役に立ちません。装備しないとダメとかそう言うやつです。

あと参考文献のページに書影入ってるのが地味にいいですね。

対象読者層

読みやすい文で、分量は多くなく、コードや図は多め。 そしてそれほど高くなく、このカバー範囲。

「システム設計の原則」と言うと身構えるかもしれないけれど、新人から少し脱したくらいから読んでもいいんじゃないかなと思います。 おそらく、難しくて全く理解できないなんてことにはならない。

一方、書いている内容の理解の仕方は、背景の知識の広さや深さで大きく変わる印象を受けました。 どのChapterをとっても、完全に理解していて何も得るものがない、なんてことはそう無いでしょう。

そのため、システムを開発するあらゆる方に読んで貰いたいと思いました。 現場でもこの本を読んでる前提で、どうしようって話ができると楽しそう。

読書会とかするといいんじゃないかなー

対象読者が幅広くて、コンテキストによって理解の仕方が変わりそうなので、持ち寄って「自分はこう読んだ」なんて話をすると面白いんじゃないかなーと。 と言うのも、平易な文でボリュームが少ないので、さらっと読んでしまおうと思えばそれで終われるんです。 でもそうしちゃうにはちょっともったいない感じもする。

ネタ: タイトルについて

「現場で役立つシステム設計の原則」なんですが、増田さんの会社名って「システム設計」なんですよね。。。 なので、会社名が他のだったら、 現場で役立つXXXの原則 (XXXは任意の会社名)となったのだろうか、とかなんとか。 いや、どうでもいいんですが。

"ふつうのJavaコーディング"を話しました

2017/5/20にあったJJUG CCC 2017 Springで登壇させていただきました。 8回目の参加です。

毎回パワーアップしているなーと言うのは前回のブログでも書きましたが、今回は目に見えて参加人数が増えたんだなーと体感しました。 入れないセッションもありましたし、懇親会も超満員でした。運営の皆様に本当に感謝です。 今後も楽しみにしています。

話したもの

ごくふつうの話、のつもり。ふつうって一体なんだとか思わなくはないですが、ただの枕詞なので意味はないです。

結局のところ九段に集約されるんですが、強い意思を持つには色々必要で、まあそんな感じです。

「coming soon」となっている61スライド目

先日(6/24)発売のWEB+DB PRESS Vol.99 で書いてます。

WEB+DB PRESS Vol.99

WEB+DB PRESS Vol.99

  • 作者: ?橋健一,谷口禎英,井本大登,山崎勝平,大和田純,内村元樹,坂東昌哉,平田敏之,牧大輔,板敷康洋,大?浩崇,穴井宏幸,原口宗悟,久田真寛,ふしはらかん,のざきひろふみ,うらがみ,ひげぽん,池田拓司,はまちや2,竹原,片田雄樹,渋江一晃,WEB+DB PRESS編集部編
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/06/24
  • メディア: 大型本
  • この商品を含むブログを見る

連載のJavaの新定石、第8回となる Optional/Stream適材適所 です。 内容が気になる方は、よろしくおねがいします!

Agile Japan 2017 京都サテライト おいでやす〜のメモ #AgileJapanKyoto

Agile Japan 2017 京都サテライト おいでやす〜 の参加/運営メモです。

「ブログを書く かつ 現場で実践するまでがAgile Japan 2017 京都サテライトです。」 って言われたので。

ちなみに元々は「ブログを書く または 現場で実践する」ってなってました。 「または」の場合、言語によっては前を評価すれば後ろは評価されないので、それはないでしょーって言ったら「かつ」になりました。 めんどくさい奴ですみません。あ、実践はしたのでブログ書いてます。

聞いたやつ

雑に書きます。

基調講演(動画)

前週の大阪サテライトと同じなので、内容については割愛。(ブログ書いてないけど)

大阪サテライトではスライドのズームとか開原さんが頑張ってらっしゃったなーと。 設備とかの関係でできなかったので、うん。 動画サテライトはスライドだけの動画がいいなと思いました。

メトリクスによる「見える化」のススメ: No 見える化、No 改善

タイムテーブルの都合で、前半1時間だけサポート?的に観戦。 チームで課題を出し合って、一つ課題を選択し、メトリクスを設定してみようってところまで。

想定課題だと難しいなと思うのがワークショップとしてのところ。 で、主眼であるメトリクスを出しているフェーズを見ていて思ったのは、メトリクスを挙げずに解決を考えちゃってたのが印象深かった。 みんなエンジニアだなーと。 メトリクスを設定する意義がぼやけていたような気が。

分析と創造は思考のスイッチが違う(後述の「みんなではじめるデザイン批評」より)ので、何をメトリクスとするかを分析しているフェーズで解決策を考えるのはあまりよろしくないよーな。 実際の打ち合わせでもあるあるで、おそらくファシリテーターが口出しする展開な気がします。

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

何を計測すればわかりそうかって想定してウォークスルーとかする感じかな。 思いつきの対応ではなくまず計測から入れってのはパフォーマンスチューニングでは鉄則の話。プロセスでもそうってことだろうか。面白い。 タイムテーブルの都合で、後半1時間は見れなかった。残念。。

リモートチームの道具箱

チームにおいて何を重視し、どの様なトレードオフを受け入れて試行錯誤しているかが印象深かった。 最低ラインに合わせているように見えるかもしれない、けれどチームにとってどうあるとよいのかに向き合って選択していってるのだろうなー。 話にあがってた道具をそのまま同じ様に使っても思う様に効果は出ないでしょうね。

アジャイルで缶詰? 〜ソフトウェア開発以外でのアジャイル活用事例〜

非常に魅力的で、缶詰が食べたくなりました。会場で即売会されたら多少高くても買ってた・・・。 ソフトウェア開発の文脈で得た「アジャイル」を非ソフトウェア開発への適用。 似た様な話はリーンスタートアップなどでもありますが、対象が缶詰という身近なもので具体例を挙げられるとイメージしやすいですね。

芯を通す開発を目指して ー アジャイル"ファン"が本気でアジャイル開発に取り組んだ2年間 ー

芯ってなんだよ、俺はこれを芯と捉えるよ、という話。 京アジャに参加し始め当時の私からすればエキスパートに見えていた彼。 まさかの「アジャイル"ファン"」カミングアウトですよ。まじかー、と。でも言われて見ればぴったりのネーミングですね。

他諸々気になるところはあったので今度話しましょーって声をかけた。どうなるかは知らない。

LT

酔っ払いのLT大会とはかくあるべしって感じでした。

永田さんのLTが強烈で、会場からの延長要請により2セット行われました。 色々と考えさせられる、というか終わった後少しお話させていただいて、思考整理してたらブレイクスルーがきたのでとても得した気分です。

運営的なのを含めた感想

色々と反省点が多かったです。 色々ってのは、打ち合わせにいけなかったり、当日集合時間に遅れたり、自分の役割把握してなかったり、ほんと色々。まあいいや。 ふりかえりしたけど、次改善するかは知らない。次ってなんだよだし。

参加された方々はもちろんですが、それ以上に日新システムズさんの方々が強力にバックアップしていただいたおかげで成立したと思います。 この場に書いても届かないでしょうが(届かなくていい)、ありがとうございます。