docker inpsect の結果を絞る方法

docker inspect をそのまま探すと、探したい情報にたどり着くまでに時間がかかる。

そんなときの対策。

 

docker inspect | find /I "key"

これだと該当行だけしか取得できず、NG。

 

docker inspect --help

Usage: docker inspect [OPTIONS] NAME|ID [NAME|ID...]

Return low-level information on Docker objects

Options:
-f, --format string Format the output using the given Go template
-s, --size Display total file sizes if the type is container
--type string Return JSON for specified type

 -f を使うと良いみたい。

 

でも"Format the output using the given Go template"の意味が分からずググる。

blog.shibayu36.org

Golangのtemplateというものを使うということが分かりました。

こんなところでGolangとかかわることになるとは思わなかった。

Docker for begginers の所感

github.com

 

・ドキュメント内で使用する用語一つ一つに解説がある

　→Dockerの仕組みに対する理解が深まる。

・DockerfileのRUNとCMDの違いの説明が丁寧

　→Dockerfileのコマンドの意味が理解できた。 

・DockerfileのbuildのLayerという概念を使って解説されている

　→docker buildの各stepの意味が分かった。

 

「dockerコマンドを使えば個々の環境は立てられるけど、必要な個々の環境を自動で、かつ複数の環境をまとめて用意するにはどう実装すればいいのかが分からない」人が、同実装すればいいのかが分かるようになる解説でした。

 

下記書籍を読んでいて、 「Dockerについて（daemon, client, image ,container）は何となく知っている」人には理解を深める手助けになると思います。 

プログラマのためのDocker教科書 第2版 インフラの基礎知識&コードによる環境構築の自動化

プログラマのためのDocker教科書 第2版 インフラの基礎知識&コードによる環境構築の自動化

 

Webアプリケーションを作っている人が、動作環境を楽に用意したいという人におすすめです。

レゴスクラムに参加してきました

良い体験をしてきたので、まとめます。

waicrew.doorkeeper.jp

 

経緯

スクラムを初めて実践することになった私は、実践事例を聞いてみたり、本を読んでみたりして計画を立てようとしたのですが、具体的な作業イメージが出来ず不安な状態にありました。

そんなときに偶然DoorKeeperのレコメンドに表示されたこのイベントの内容や参加者のブログを見て、具体的な作業をイメージできるようになれそうだと思い参加することにしました。

参加した感想

プロダクトが出来るにつれて、チームの成長も感じられて、複雑な問題が単純な問題に近づく感じを体験できました。スプリントを繰り返す度に担当タスクに各自のアプローチ、複数人なら分業して取り組んでいてとても楽しかったです。

何回かスプリントを繰り返すとプロダクトの形が見えてくるので、ユーザーストーリーの優先順位が変わって新しいプロダクトバックログアイテムが現れても、どう実現すればいいのかイメージができるようになりました。

スクラムの楽しい体験を通して、アジャイル実践手法をどう活用していくべきか、今後の指針を得ました。

フレームワークに「はめる」のではなく、「活用する」という考え方に変えられたのはよかったです。

具体的に良かった・学んだ事

  1. アジャイル（概念）とスクラム（実践）の違いを理解できた。（アジャイルとは傘である）
  2. 単純（Simple）な問題が次々に投入されるチームにはカンバンを利用が効果的である、ということを知った。
  3. カンバン / タスクボード をスクラムで利用すると効果的であるが、もともとは独立したタスク整理手法である、ということを知った。
  4. 日常の仕事は分解すれば事前にゴールを計画できる Complicated な問題が実は多い、ということを知った。
  5. Complex な問題はどこから取り組めば良いか分からず、ゴールを事前に計画できないので進捗率が意味をなさない問題を指す、という意味が分かった。（The Stacey Graph）
  6. スクラムを適用すると効果が上がる条件を明確に出来た。（Complicated と Complex）
  7. スクラムに限らずアジャイルで使われる実践手法は 、プロジェクトに一貫して適用するというよりも構成する仕事に適用するものだと、考え方を見直せたこと。（スクラムに当てはめるのではなく、スクラムを仕事の一部に組み込む）
  8. 野菜を切って、そばと炒めて、盛り付ける－といった直線的に計画を立てる癖が身に付いているため、食べたら感想をフィードバックして次の焼きそばを作る－というループする癖をつけることが大切。（Inspect and Adapt で「最高に美味しい焼きそばの作り方」を考える）
  9. 複雑なソフトウェアは小さいモノから作る。（焼きそばとソフトウェアは違う）
  10. 技術的な役割は当然のように全うしながら、チームの知恵や経験も少しずつ作り込んでいく。（Management の役割）
  11. 不安定な状態を作り、自律、成長、交流といった自己組織化を促す。（指示をせずにチームをどう作るか）
  12. 作る対象が Complex ならば、作る人もそれに応じて変わる。（コンウェイの法則）
  13. スクラムマスターはどのように作るかの責任者。テックリードのロールだが、指示は避ける。
  14. プロダクトオーナーは何を作るかの責任者。スクラムチームとステークホルダーの両者に目を向ける。プロダクトバックログでチームに意向を示す。
  15. 価値は顧客が決める。頑張って良いものを作っても仕方ない。だからフィードバックを早く貰うことが大事。（Customer Definition Value）
  16. 自動車業界のチーフエンジニアのように What と How 両方を出来る人は少ない。だからプロダクトオーナーとスクラムマスターがいる（プロダクトとプロセスの境界）
  17. 見える化（Transparency 作って貰うが指示をしない秘訣）
  18. スクラムマスターがメンバーの成長を願い意図的に指示するなどマネジメントをすることも時には（状況によっては）必要。（最終的にチームが自律すればいい）
  19. プロダクトオーナーには圧倒的当事者意識が必要。
  20. 収支にも責任を持つ。（ただし一つの受託開発型で組むスクラムは少し違うと思う）
  21. パートナーとスクラムを組むときはそれぞれの想いのすりあわせが大切。
  22. 大規模で計画が難しいからアジャイルをするのは違うのでは？（本当は Complecated なだけかもしれない）
  23. 新製品開発など反復的に開発が出来、もし上手くいかなければ中断する判断も出来るプロジェクトには、アジャイルが良く合う。
  24. プロダクトバックログの表現にはユーザーストーリーが多いが、実はユースケースシナリオ、仕様書、何でも良い。
  25. ユーザーストーリーは、3行で書くといい。（1行目：属性、ペルソナ、2行目：欲しいもの、3行目：理由）
  26. 必要なことを理由にしないこと。開発者のやる気が下がる。（ユーザーストーリー）
  27. ユーザーストーリーの見積は相対値で並べる。（プランニングポーカー）
  28. 1スプリントで対応可能な見積予測値を立てて、優先順位の高いプロダクトバックログアイテムを取り出す。（スプリント計画／スプリントレビュー）
  29. 初めてのスクラムでは、1スプリント目は代替失敗することが分かった。（予測値通りには行かないからレビューとレトロで見直す）
  30. プロダクトバックログをタスク化したらカンバンに張り出す。（スプリント計画）
  31. 見積もりできない、困ったときはプロダクトオーナーを呼びつける。大抵のプロダクトオーナーは他のタスクで忙しいので。
  32. 自分が何をやるかは自分で決める。（サインアップ）
  33. スプリントバックログの作り方は、プロダクトのタスクを分解すること。
  34. 見える化、流れの管理、WIP制限（カンバン3原則）
  35. Development のタスクが Test に移れないのなら、早くタスクを流す為に みんなで Test のタスクを手伝う等、どうすべきか考えることが大事。（流れの管理）
  36. 一度に取りかかれる数は決まっている。その中でタスクをこなす方法を考えることが大事。（WIP制限）
  37. テストコードの量は開発者が自信を持って納品できる量。
  38. メンバー評価をチーム評価にすると、手を抜く人が出るかも知れないので注意。
  39. 納期が決まっている（ゴールまでのやるべき事が決まっている）場合に、スクラムを取り入れるのは、やるべき事が終わらない可能性があるので注意する。
  40. スクラムの基本はスコープを分けること。
  41. 「こんな出来のモノを見せて良いのかな？」と思っても大抵は問題ないので、見せてフィードバックを得ること。
  42. スクラムは、プロセス（人）の成長とプロダクトの成長の相互作用で成り立つ。（スクラムを体験して、なるほどなと思った）
  43. DB設計など後回しにしたことで惨事に至るタスクは先に済ませるべき。（Railsを進められた。何でだろう？）
  44. 共通ライブラリなど、必要になったときに作ればいい。
  45. アジャイルをやったからといって納期は早まらない。早まるときはスコープを絞ったときだ。（そりゃそうだ）
  46. ウォーターフォールだからといって品質があがるとは限らない。品質の上げ方は取り組み方に依存する。アジャイルに開発しても同じ。アジャイルだからといって設計書を作らない訳でもないのだ。フレームワークにはめようとせず、その利用目的を考えよう。
  47. スプリントレビューではプロダクトオーナーがプロダクトバックログアイテムを読み上げる。作った人はそのデモを通してプロダクトオーナーからフィードバックしてもらう。受け入れなら実績にその見積値を記録し、継続なら実績は０とする。
  48. こなれた付箋の千切り方を学べたこと。（笑）

解消できた悩み

  • スプリント計画のやり方は？
  • プロダクトバックログアイテムの書き方は？
  • 見積ってどうやるの？（見積ってプロダクトバックログに対してするんだ）
  • DBを設計するタイミングはいつ？
  • 共通ライブラリを準備するタイミングは？
  • プロジェクト収支を管理する人は誰？
  • アジャイル＝早いって本当なのかな？
  • プロダクトオーナーって誰がなるといいの？
  • アジャイルの本質は、チームビルディングって本当？
  • スクラムをやる目的って何だっけ？

 

PageObject について調べて、考えを改めた話

こちらの発表資料を拝見して、僕も PageObject って頑張らないといけない印象を持っていたけど、本当に頑張らないといけないんだっけかな？－と思い、 PageObject について考えたこと、調べたことのまとめです。

 

 

speakerdeck.com

 

僕が過去に苦労していたこと

ページ要素の収集。IdやName属性がHTMLタグになく、必要な要素のXPathを取得していたこと

アプリケーションの操作で画面要素を隠蔽していなかったこと。Getterで隠蔽はしていたけど、それを隠蔽というかは疑問。

 

僕がやっていたこと

PageObject という名で、ページ上のWebElementを集めたクラスを作っていたこと

 

PageObject について調べたこと

そもそも誰が考えたのかなーって調べたら、Martin Fowlerさんの記事が見つかりました。

martinfowler.com

 

気付いたこと

PageObject が提供するAPIは、アプリケーションの操作でありページ要素を隠蔽するということ

PageObject を利用する必要があるテストの目的が、例えばユースケーステストだとすると、そのユースケースにおいて利用される画面操作をAPIとして提供すれば良いということ。つまり、APIが必要とするページ要素だけを取得すれば良いということ

ただし、これは PageObject が提供するAPIがユースケーステストで利用されることを前提とした話なので、 PageObject の設計については都度考える必要はある

 

そういえば、 PageObject ってどう設計すれば良いの？っていう疑問は、息子が生まれる前だから、 1 年前くらいから持ってました。今回の記事をきっかけに、理解が出来て良かったです。

 

アプリケーションの操作 ＝ ユースケースの 1 課程と捉えると、ICONIXのモデル（シーケンス図）は PageObject 設計に利用出来るかなと思うので、今度実験してみたいと思います。

 

気付かせてくれた snowhiro さんには感謝です。

JJUG CCC 2017 Spring で話そうと思ったけど話さなかった JPA の話

実は準備が簡単だったので、JPA の話も用意してたり。

自分の振り返りにはちょうど良かった。

www.slideshare.net

JJUG CCC 2017 Spring の懇親会でLTさせて貰った話

今日はベテランのJavaユーザの方々がいる中、LTをさせて貰いありがとうございました。

一番大事なのは、懇親相手を見つけることでしたがLTやって終わってしまいました。

 

次は事前に準備してリベンジしたいな～(^_^;)

 

www.slideshare.net

Spring Framework はじめました

久しぶりにチームで開発をできることになったので、フレームワークの選定をしました。

 

フレームワークを使って実現したかったこと

  • お願いする人と作る人が互いに共通のコンテキストに基づいてイメージしながら会話が出来ること（作るときに間違いを少なくすること）

 

例えば…

僕（お願いする人）：

「まず、僕の方で○○画面にボタンを追加しておいたから、それをクリックしたらこのカンプにある画面に遷移してー（コントローラにリクエストハンドラを追加して、追加したテンプレートビューにリダイレクトしてー、イメージできてるかな？分からなかったら説明しよう）」

Aさん（作る人）：

「あぁ、コントローラにリクエストハンドラを追加して、追加したテンプレートビューにリダイレクトすればいいですね。カンプにあるテンプレートビューのベースHTMLはあります？ー」

僕（お願いする人）：

「あるよ。テンプレートにはThymeleafを、スタイルはBootStrapのを使ってね。じゃあ、新しく作る画面の説明をするね。これは■■の情報を入力する画面で、登録ボタンを押したら確認画面を表示するんだけど、遷移前に入力値のチェックをしたいんだー（よかった、バッチリだ。新しい画面については、まずカンプを参考にしてInputタグを配置して、スタイルを適用するところから始めてくれるといいな。入力値チェックはBean Validationを使ってー）」

Aさん（作る人）：

「まずは、カンプを参考にしてInputタグを配置して、スタイルを適用するところから始めますね。出来たら見てください。入力値のチェックは■■入力画面に対応するFormクラスにBean Validationを追加していけばいいですね。項目チェック仕様を見てもいいですか？ー」

 

このように、フレームワークを通して共通のコンテキストに基づいて、ユーザ要件を反映した外部設計の結果を作る人に伝える際に、お互いが同じ内部設計をイメージできると、プロジェクトが整理されるので気持ちがいいなと思います。

 

勿論、プログラム設計書を作って説明する―という手もありますよね。

開発手法に囚われすぎず、脱線しすぎず、状況に応じて仕事の進め方を変えられるように判断する為の知識を持っていられるといいな―と思います。（適切なアドバイスをしてくれるプロマネがそばに居てくれると最高ですね。）

 

  • フレームワークのコンテキストに基づき設計されたパッケージに、意図した通りコードを実装して貰えるようにすることで、後々ジョインする人がそのフレームワークのコンテキストを持っていれば、すぐにコーディング出来るようにすること（保守対象を分かり易くしておくこと）

 

例えば…

僕（お願いする人）：

「今回入った改修の説明をするね。これは■■の情報を入力する画面で、登録ボタンを押したら確認画面を表示するんだけど、遷移前チェックしている入力値のチェック仕様を変更したいんだー（入力値チェックは■■画面のFormクラスにBean Validationを使って実装されているから、そこを修正してー）」

Bさん（作る人）：

「今回の言語はJavaで、使っているフレームワークはSpring MVCですから入力値のチェックは■■入力画面に対応するFormクラスのBean Validationを変更すればいいですね。項目チェック仕様と変更仕様を見てもいいですか？ー」

 

このように、フレームワークを通して共通のコンテキストに基づいて、すぐに改修箇所をイメージしてコーディングに移れると、仕事が早くてお互いにもPOにもハッピーだなと思います。

 

経緯

今回、フレームワークの選定を自分で改めてしようと思ったのは、作る人だけに内部設計を任せっきりになっていたのを止めて、お願いする側（僕も含めて）にも内部設計出来るスキルを養いたかったからです。（少なくとも僕と同じチームになったメンバーには、そうなって欲しいなと思っています。）

 

上記では「作る人＝プログラマ」でしたが、プロジェクトの状況によっては「作る人＝別組織に所属するSE」というケースもあります。

いずれにしても、人がする仕事なので、やることは同じでもその人のコンテキストに基づいて内部設計が行われます。

 

この結果どうなるかというと、項目チェックがリクエストハンドラに実装されたり、サービスに実装されたりします。

これが繰り返されると、もう改修するのも危なくて触りたくないアプリケーションが出来あがってしまいます。

 

アプリケーションは、業務を遂行するために使われたり、サービスにおいては時には稼ぎ頭となって使われたりします。（ECサイトはその最たる例だと思っていて、店舗がオープンしていなければ売り上げは生まれません。極端ですが、僕らの給料の原資となる会社の利益も生まれません。）

 業務の効率や質を良くする為、もっと売上を増やす為に、アプリケーションは改修を繰り返していきます。

 

そんな時に、直す箇所を誰も知らないアプリケーションがあったらどうでしょうか。Aさんのように最初に作ってくれた人がいつまでも居るわけではありません。

 

改修を担当することになったCさんは、まず改修箇所を探す事から始めます。

ようやく見つけた箇所を直したと思ったら、別の箇所がおかしくなったと声が掛かり―なんてやっていると、改修結果が反映されるまでいくら時間があっても足りません。

（危ないから）テストケースを増やそうといった、工数を増やすような判断―この場合や状況に応じては正しいかもしれませんが―に至ってしまいます。

 

一方、すぐに直す事が出来て、改修をリリースできたら、少しでも早くから売上や利益を作る時間を確保できます。

 

カッコつけっぽいですが、一応はこういう意識で仕事をしてます。サービスを運用して稼ぐビジネスでは、運用する人たちは稼ぎ頭ですし。彼らの運用効率が下がれば、時間が掛かり余計なマンパワーが発生して利益は下がります。

僕たちが声を聞くし、それを素早く形にするから、そっちもそれに応えてね―って気持ちです。こう考えて仕事（開発・保守）をした方が楽しいです。

 

だから、正確に品質を保ちつつ開発し、すばやく保守する為に、フレームワーク選定を通して必要なポイントを身に付けようと考えました。

 

選定条件

  1. お願いする人は、何を作ればいいかを明確に説明できること
  2. 作る人は、説明を聞いて何を作ればいいか明確にできること
  3. アプリケーションが完成してなくてもテンプレートビューのデザインを確認できること
  4. コミュニティに参加して、他のユーザと話ができる環境があること
  5. 自分たちが使える言語であること

 

1、2番は共通認識を持てる概念が整っていて、理解しやすければOKです。

 

3番は画面イメージを作ったらすぐにフィードバックを貰いたかったので、JSPは避けたいと思いました。

また、メンバーのスキルを考えたときに、デザインを確認するために、画面の作り方（スタイルの適用）、サーバアプリケーションの仕組み・作り方を一気に説明して混乱させるより、HTMLを書いたら画面をすぐに確認出来た方が、ステップバイステップで教えられるので良いと考えたのもありました。

 

4番は日本 Selenium ユーザコミュニティやテストのコミュニティに参加した経験から、いろいろな方にお世話になったな―と思っていた為です。

社外の方が圧倒的にユーザ数が多いので、情報量も多いだろうと考えました。

 

技術的な条件である3番以外は、フレームワーク自身が備える性質だったり、TwitterやJJUGを通して肌で感じていたことだったので、3番を中心に調べました。

 

その節は、とても助けられました (*^｡^*) 

 

この結果、その条件を満たすThymeleafテンプレートエンジンを組み合わせて使えるフレームワーク Spring（Spring Boot）を選択しようと決めました。

 

フレームワーク決定後に気付いた大事なこと

実際に使い始めてから、いろいろな方に助けてもらいました。

 

外部データの扱いに疑問を持っていたとき

 

リリースを効率化する方法を探してたとき

 

application.ymlの 設定で困ってたとき

 

ThymeleafのValidationで困ってたとき 

 

(´;ω;`)ﾌﾞﾜｯ

僕も誰かにお返ししたいという気持ちになります。

だからコミュニティに人が集まるのでしょうね。

 

参考にしている書籍、ドキュメント

はじめてのSpring Boot―スプリング・フレームワークで簡単Javaアプリ開発 (I・O BOOKS)

はじめてのSpring Boot―スプリング・フレームワークで簡単Javaアプリ開発 (I・O BOOKS)

 

内容が濃いです。

２週目からは、痒いところに手が届いていることに気付いてゾクゾクしてきます。

１月中頃から使っていますが、時々読み返してます。

 

後は、Spring Project Documentation 、stack overflow、Blogに助けて貰ってますが、そろそろSpring Securityについてはアーキテクチャを理解して？、authenticationを独自実装したり応用したいなーと思ってます。

 

使い方を覚えるためにそれなりに時間を要しましたが、１月中頃から使い始めて直ぐにパッケージングから役割分担も出来て、フレームワーク導入は順調にスタートしました。

 

きっと、上記イメージどおりにメンバーと開発しながら、今回の選定目的を果たすことができるでしょう。これからが楽しみです。