JJUC CCC 2017 SpringでJava8移行事例について登壇しました。

5/20に開催されたJJUG CCC 2017 SpringでJava8移行事例について登壇しました。

www.java-users.jp

www.slideshare.net

もうすぐJava SE 9がリリースされようかというのにJava 8の移行の話なのかよ、というのもあるのですが、逆にこの事例の話をするのはここがラストチャンス、ということで突っ込ませてもらいました。テーマ自体はJava SE 8への移行の話ですが、

  • Java SE 9がリリースされたとして、Java SE 8/7/6/5/さらにその前…と、それまでのバージョンの移行パスをスキップして最新のJavaランタイムに移行できるとも思えない
  • こまめにコードベースをメンテナンスすることの重要さ、エンジニアリングの組織にとって、最新の技術に追従することの重要さは、特定のJavaランタイムバージョンに関係ない話である
  • 大体Javaエコシステムの場合、Java SEのリリースサイクルと、ミドルウェアフレームワークの最新のJava SEをサポートしたバージョンのリリースサイクルの間には相当な時差があり、Java SE 9がリリースされても当分の間はJava SE 8を用いることに現実的にはなってくる

というわけで、色々皆様に参考になる事例の話が出来たと思っています。

講演の中で、移行プロセス中で、git-flowでのブランチごとに徐々にビルドに使用するJDKを切り替える話をしていたのですが、これをやるには、プロジェクト内でのブランチ管理の運用がしっかり確立されていること、CI(継続的インテグレーション)での各ビルドとGitのブランチの管理の関連付けが確立されていて、プロジェクト内で共有されていることなどが前提としてあります。この案件はオフショアも含めた複数チームで、同一コードベースを並行開発しているということもあり、どこのチームでも即できることではないことをこのチームではやっている、というのがあります。この開発チーム、コミュニティーの技術セッションで発表の題材になることをしれっとやってのけるので、事例紹介のストーリーの組み立てに苦労するというのが私の密かな悩みです(笑)

最後になりますが、講演の機会をいただいたJJUG幹事のみなさん、スタッフの皆さん、当日JJUG CCCに来場いただいた大勢の皆さん、ありがとうございました!

JJUG CCC 2017 SpringでJava8移行の事例について登壇します

5/20(土)に開催されるJJUG CCC 2017 Springで「Java8移行は怖くない~エンタープライズ案件でのJava8移行事例について~」というテーマで発表します。

jjug.doorkeeper.jp

日時:2017/5/20(土) 16:10~16:30 会場:L会場 概要:JDK9のリリースも間近ですが、Webアプリケーションを中心としたJava言語を用いたシステム開発では、使用するJavaランタイムのバージョンはサービスイン時のバージョンで「塩漬け」になるというのが実態ではないでしょうか。本セッションでは、発表者の関わったエンタープライズ向けWebサービスでのJava8移行の事例を通じて、サービスイン後のJavaランタイムのバージョンアップを行う際のポイントについて紹介します。

20分のセッションですが、Java8移行について、事例の紹介と、SIerの組織にとってJavaの最新バージョンに追従することがどのような意味を持つのかを含めて、目一杯詰め込んだ内容にします。当日は是非会場までお越しください!

JJUG ナイトセミナーでコンシューマー駆動契約とpact-jvmについて発表しました

4/24に開催されたJUG ナイト・セミナー 「テスティング特集」 でコンシューマー駆動契約とそれを使用したテストツールであるpact-jvmについて発表しました。

jjug.doorkeeper.jp

www.slideshare.net

発表に使ったサンプルコードは、以下のGitHubレポジトリーで公開しています。

github.com

本発表ですが、4/9に開催された技術書典で頒布した「すいーとみゅーじっく vol.1 TDDってなんだ?」に掲載した「Pactではじめるコンシューマー駆動契約」の内容を元に、Pactのjvm向け実装*1であるpact-jvmについて検証した結果を取り込んで構成したものになります。

fieldnotes.booth.pm

講演の中でも取り上げましたが、Arquillianやpact-jvmをはじめとするJavaでのマイクロサービスを対象としたテスト手法についてまとめたTesting Java Microservicesという書籍がこの夏に出版予定で、電子書籍フォーマットのEarly Access(MEAP)版は既に入手可能です(Manning | Testing Java Microservices)。この発表では技術検証が間に合わなかったので割愛しましたが、Arquillianとpact-jvmとの統合についても記述されています。

技術書典2の準備にパワーを注いだ後の技術検証ならびに発表の準備と言うことでタイトなスケジュールでしたが、旬なテーマに対して知識がフレッシュな状態で公に出すことが出来て良かったと思います。発表の機会をいただいたJJUGのみなさん、当日参加いただいたみなさん、ありがとうございました!

*1:Pactは当初ruby 向けの実装のみでしたが、現在はJavaScala、.NET、JavaScript、Go、Swtift/Objective-C に移植されています。

技術書典2 振り返り

4月9日にアキバ・スクエアで開催された「技術書典2」にサークル「ふぃーるどのーつ」で参加してきました。

techbookfest.org

techbookfest.org

電子書籍(PDF)版は、booth.pmで販売しています。

fieldnotes.booth.pm

当日は雨天で足下の悪い中、3100人以上の一般来場の方にお越し頂き、当サークルも、印刷所への発注数の殆どを売り切るという、望外の結果に恵まれました。ブースにお越しいただいた皆様、厚く御礼申し上げます。

時系列別振り返り

2016-12~2017-1
  • 2016-12 知識のアウトプットの形式として同人誌を考え出す。コミケを見に行く。
  • 2017-正月 技術書典2の開催を知り、参加を考え出す。主催のtechbooster (以下てくぶ)の中の人に威嚇(?)いいねされる。

twitter.com

  • 2017-1-4意を決して申し込む。

twitter.com

  • 2017-1-7(正月休みの後の三連休) 原稿のgitレポジトリーをBitbucketに作成する
  • 2017-1-9 markdownからpandoc+lualatexでPDFを作成してDropboxにデプロイする仕組みをBitbucket Pipelinesに作成して悦に入る。
  • 2017-1-16 参加当選が決まる。コミケで噂に聞く壁サークルの配置と言うことを知りビビる
  • 2017-1 中旬~下旬 このブログの記事をブラッシュアップしてコンテンツにすることを決め、執筆を進める。
2017-2
  • 2017-2 上旬 他のプライベートのことを考えると2月中には執筆の大枠を固める必要があるとの見込みの元、ひいひい言いながら執筆する

twitter.com

  • 2017-2-5 「技術書典2 技術書の作り方勉強会 ~執筆環境をワイワイはなそう~ 」に参加する。てくぶの「技術書をかこう! ~はじめてのRe:VIEW~」を購入する。

techbookfest.connpass.com

techbooster.booth.pm

  • 2017-2-5 ノリと勢いでコミケ92(夏コミ)に申し込む。
  • 2017-2 中旬 この頃から意に反して仕事が忙しくなり始める。
  • 2017-2 下旬 「Pactではじめるコンシューマー駆動契約」の技術検証がうまく進まずに行き詰まる。1マス戻る。

twitter.com

  • 2017-2-26 「技術書典2 もくもく執筆レビュー会 ~進捗はそこにあるか~ 」に参加する。レビュー会と帰宅してから技術検証を続けた結果、技術検証が終わる。2マス進む。

techbookfest.connpass.com

twitter.com

2017-3
  • 2017-3-上旬 いよいよ仕事が忙しくなり、職場で暗黒オーラをまき始める
  • 2017-3-9 「まべ☆てっく vol.3」で宣伝LTをする。ちなみにこの段階で「テストと『品質』」はまだ書き上がっていない。

marv-tech.connpass.com

  • 2017-3-20 一通り書き上がる。校正・レイアウト等の作業に入る。計画からは一週間遅れ。
  • 2017-3-21 POP立て等の必要な資材を買いそろえる。
  • 2017-3-27 他の私用のため有給を取っていたがその予定がキャンセルになったので、終日レイアウト作業に費やす。
  • 2017-3-28 入稿する。
  • 2017-3-31 「来月もプレミアムに過ごすためのインフラ構成管理ツール入門編」でLTをする。その中で技術書典2の宣伝もする。

techcircle.connpass.com

2017-4~当日
  • 2017-4-1 ブースに必要な資材の買い出し、キンコーズでダウンロードシリアルを印刷したペーパーの用意など。 告知エントリーを作成する。
  • 2017-4-2 電子書籍版(PDF)の用意。結局この後前日まで細部の調整でPDF版の再作成を繰り返すことになる。
  • 2017-4-4 ダウンロードシリアルのペーパーにURLのQRコードを掲載した方が便利なことに気づき、キンコーズで再度作成
  • 2017-4-7 一応出社していたのですが、心ここにあらず
  • 2017-4-8 サポートページのエントリーを作成して予約投稿をかける。
  • 2017-4-9 当日を迎える

雑感

スケジュールについて

印刷所の期限のだいぶ前に入稿していますが、これは自分のスケジュールが

  • 開催の前日(土曜)はプライベートの都合で準備に時間を割けない
  • なので、その前の週の土日をブースの準備に使う必要がある
  • ということは、その前に入稿しておく必要がある

ということで、このようなスケジュールになっています。もう数日少し遅らせておけば細部のクオリティーをあげられたのではないかというのはあるのですが、その時期は業務の方の稼働もいっぱいいっぱいだったので、これはこれでよかったと思います。炎上案件良くない。

入稿

てくぶ様の方でRe:VIEWでPDF入稿のテンプレートを作っていただきましたが、今回は作業環境がWindowsだったとか、その当時だと、PDF/Xのフォーマットとかフォントの埋め込みのところがちんぷんかんぷんだったとかあり

  • markdownで書いた原稿を Pandoc - About pandoc でLuaLatexでtexに変換し、そこからPDFを生成
  • 生成したPDFをプリンターで漫画用原稿用紙に出力し、版下を入稿

というプロセスでやっています。この手順だと、極端な話原稿用紙のコーナートンボの内側に文字が出力されていれば入稿できるのと、入稿時に印刷所の店員さんに版下をチェックして貰えるので、データをアップロードしてから差し戻し→修正の手間を踏まずに済んだのはよかったと思います。ただ、仕上がりのきれいさはやはりPDF入稿のほうが優るので、次回からPDF入稿を検討したいです。

markdownをBitbucketにpushするとBitbucket PipelinesでCIが実行され、作際されたPDFがDropboxにデプロイされるということをやっていたのですが、主にフォントの埋め込みの関係で、最終工程はWindows上で作成しています。LuaLatexの仕様上はコマンド実行時のカレントディレクトリーにフォントのttfファイルを置けば認識できるのですが、リモートのCI環境でそれをやるのはライセンス上アレでソレなもので。ちょうど開催直前にAdobeオープンソースの「源ノ明朝」フォントをリリースしたというニュースが出たので、次回はそちらを使ってCIでの入稿PDF作成にチャレンジしたいです。

forest.watch.impress.co.jp

あと表紙作成時にテンパっていて表紙のフォントはメイリオなのですが、クリアPPの明るさとマッチして意外と悪くないです。とはいえ、このようなイベントではどれだけ目立つかが勝負なところがあるので、表紙にはもっと力をいれるべきだと思いました。

釣り銭

当日、他のサークルさんでこんな話がありました。

実は当サークルでも釣り銭が足りなくなり、早々に売り切れて店じまいした隣のサークルに両替してもらって窮地を脱したという一幕がありました。(docker-machineさんありがとうございました)。釣り銭は500円玉を10枚用意していましたが、訓練されたコミケ参加者のように500円玉を束で持ってくるのかと思ったら思いの外札での支払いが多く、足りなくなったという…。当日の売り上げ実績だと500円玉が20枚は必要のようです。ただこれで1万円になるので、個人が用意する額としてはこれが限界ですね。

サンプルコード

今回、「Pactではじめるコンシューマー駆動契約」内の記述の進行と、GitHubに公開しているサンプルコードのコミットが連動しているという試みをしています。よく頑張った。褒めて欲しい。

github.com

サポートについて

てくぶさんが開催された事前の勉強会に参加しました。サークル出展ははじめてで勝手がわからないところがあったので、情報や雰囲気が色々知れてよかったです。また公式サイトでのサークルリスト関連の機能など細かくサポートしていただき、ありがたかったです。

techbookfest.connpass.com

後、持ち込む冊子数をどれくらいに見込むかですが、「techboosterの見込み数×(自サイトのサークルチェック数/techboosterのサークルチェック数)」というのが、技術書典では一番正確に見積もれるようです。

あと、今回の技術書典2にも参加されていたid:kakkun61の以下のエントリーは大いに参考になりました。

kakkun61.hatenablog.com

kakkun61.hatenablog.com

収支

収支ですが、以下の通りです。

売上
項目 単価 売上数 売上金額
冊子 500 143 71500
出費
項目 金額
印刷費(B5・40ページ×150部) 18140
参加費 7000
備品・文具 7041
コピー代(ダウンロードのペーパー用) 5553
Adobe Creative Cloud(Acrobat) 20476
typekit ポートフォリオプラン※ドル決済のため概算 5850
合計 64060

ということで、差し引き7000円強の黒字ということになります。はじめてのサークル参加で赤字にならなかったので、収支面では望外の結果となりました。

なお手元に、技術書典2の参加が決まった直後に気が大きくなって買ったQHDモニターの領収書があることを申し添えておきます。

最後に

今回このような形で自分の知識をまとめて発表する機会を得ることができ、大いに得るものがありました。また当日も楽しませていただきました。次回技術書典が開催されたらまた参加を検討したいと思います。

主催のtechboosterさん、印刷・製本の日光企画さん、サークル参加者および一般参加者をはじめとして関係者のみなさん、ありがとうございました!

2016年を振り返る

お仕事

前半はBlue-Green Deploymentの導入やっていた。技術的には去年やっていたことの焼き直しだったので、モチベーション的には苦しいものがあったが、何とかかたちになるアウトプットを出せたと思う。

twitter.com

転職してから丸三年になりますが、同じお客様を担当して四年目に突入することになりました。SIの世界では結構異例なことですが、ありがたいことだと思います。

その一方で、春からは社内の他の案件の支援も担当することになった。来年も頑張る。

コミュニティー活動

www.slideshare.net

www.slideshare.net

www.slideshare.net

www.slideshare.net

主催
  • BDD in Action読書会

アウトプットを一段上のレベルに出そうとして、講演では色々チャレンジした。その結果として消化不良気味になったものもあるが、次につなげていきたい。

趣味

  • miwa「miwa “ballad collection” tour 2016 ~graduation~」3公演
  • いきものがかり 「超いきものまつり2016 地元でSHOW!! 〜海老名でしょー!!!〜 / 〜厚木でしょー!」 3公演

まとめ

もう若さまかさでどうこうする年齢でもないですが、一日一日を健康を大事にして、明るく楽しく生きていたい。

Bitbucket PipelinesとBambooのブランチモデルの違いに見るデプロイ戦略の構造

このエントリーは、Atlassian User Group Tokyo Advent Calendar 2016 - Qiitaの23日目エントリーです。

qiita.com

2016年10月に開催されたアトラシアンサミットソースコードホスティングサービスBitbucket Cloud継続的インテグレーション(CI)によるビルド・デプロイを統合した新サービス、Bitbucket pipelinesのサービスインが発表されました。

Bitbucket Pipelinesは、Bitbucket上で管理されているソースコードにビルド設定を記述したbitbucket-pipelines.yml()をコミットすると、Bitbucketへのソースコードのpushをトリガーとしてビルド及びデプロイを実行するというサービスで、Travis CIを始めとするGitHubに統合されたCIホスティングサービスと同様のサービス形態になっています。また、本年12月一杯までは無料で使用できます(2017年1月以降は1セント/1分の予定)。

Bitbucket Pipelinesの特徴としては、以下の四点が挙げられます

  • Bitbucket Cloudとの統合
  • DSL(bitbucket-pipelines.yml)でのビルド記述
  • Dockerベースでのビルド環境
  • プルリクエストベースでのビルドフロー

このエントリーでは、同じくアトラシアン社のオンプレミスでのCIパッケージであるBambooと比較した場合に大きな特徴となる、プルリクエストベースでのビルドフローについて、Bambooとの比較をしながら、述べていきます。このエントリーで試用したサンプルはBitbucket上で公開しています

プルリクエストベースでのビルドフロー

Bitbucket Pipelinesでは、bitbucket-pipelines.yml上での記述により、ブランチごとにビルドの設定をカスタマイズすることができます。

Bitbucket Pipelinsでデプロイを行うには、デプロイの対象となるブランチに対して、プルリクエストを作成します。例えばbitbucket-piplelines.yml上で、masterブランチをビルドした際に本番環境へデプロイを行うように記述されている場合、本番環境へのデプロイを行う場合には、masterブランチに対して、プルリクエストを作成します。

f:id:setoazusa:20161223213713p:plain

f:id:setoazusa:20161223220216p:plain

これは、GitHubに統合するかたちでのCIサービスで広く採用されているワークフローと同様なっています。これに対してBambooのデプロイは、それぞれのブランチのビルドを起点としてリリースを作成し、そのリリース内の成果物(artifafct)を各環境にデプロイするワークフローとなっています。

プルリクエストでのデプロイの特徴

プルリクエストを中心としたワークフローベースのデプロイの特徴としては、やはりワークフローが簡潔となることが挙げられます。どのような手順を踏めばデプロイされるかということが、「masterブランチにブランチをマージすれば本番環境にデプロイ」されるというように明快になります。また、ワークフローが単純になることのメリットとして、チャットを運用のワークフローに組み込む、ChatOpsへの親和性も高くなります。

これに対するデメリットは、ブランチのビルド設定とデプロイのワークフローを結びつけたことにより、一つの環境にデプロイされるのは特定のブランチの最新ビルドとなることがあげられます。これに対し、BambooのようにCIのビルドからリリースを作成するデプロイの場合は、任意ブランチの任意ビルドがデプロイ可能です。

今のプロジェクトで、releaseのブランチがリリース準備の作業中の時に、本番環境で緊急に修正を要する障害が発生した場合のデリバリーのワークフローの検討を行ったりもしたのですが、こういう場合はやはりBambooのようなリリースとブランチが疎結合になっているモデルのほうが都合が良い、と考えます。

また、リリース時に問題が発生し、一個前のバージョンに戻す、いわゆる「切り戻し」を行う場合は、プルリクエストベースのデプロイの場合は、

  • リリース内容をrevertするコミットを作成して再度プルリクエストを作成する
  • リリースブランチをリリース前のリビジョンでハードリセットする
  • immutable infrastructureにして一個前のインフラ構成に戻す

のいずれかの手順を踏むことになります。

これに対して、Bambooのようなリリース内の成果物をデプロイする場合は、CIサーバー上で一個前のバージョンのリリースをデプロイすることによって、切り戻しを行う事ができます。

また、複数モジュールからなるシステムを構築する際、モジュールが親モジュール(いわゆる「共通モジュール」)と子モジュールに別れている場合に、Bambooではブランチごとに独立してビルドの依存関係を持たせてビルドチェーンを構築することができますが、Bitbucket Pipelinesではそのような機能を有していません。

まとめ

このようにBitbucket PipeliesのようなプルリクエストベースのワークフローとBambooのようなリリースベースのワークフローを比較した場合に、プルリクエストベースでのデプロイの特徴としてあげられるのは、パイプラインがバージョン管理システム(VCS)のブランチと密結合になるかわりに、身軽さを得たワークフローだということです。このようにデプロイのワークフローについての設計思想がBambooと根幹から違うため、Bitbucket PipelinesはBambooの代替にそのままでなるものではなく、実際Bambooにも新機能の追加は活発に行われていますので、ワークフローに対して求められる厳格さに応じて、しばらくはBitbucket PipelinesとBambooの棲み分けが続くと考えられます。

参考

私といきものがかり

このエントリーは、いきものがかり Advent Calendar 2016 - Adventarの20日目エントリーです。

www.adventar.org

さて明日12/21*1は、2016年8月と9月にいきものがかりの地元と海老名と厚木で行われた屋外ライブ「超いきものまつり2016 地元でSHOW!!」のブルーレイ発売日ですね。みなさんこのエントリーを読んだらブルーレイをポチるのですよ?

えっ、DVDプレイヤーしかない?いえいえ、世界で一番可愛い32歳こと吉岡聖恵さんのお姿を堪能するにはブルーレイじゃないと駄目です、プレイヤーも一緒にカートにいれてくださいw

...という振りはさておき、いきものがかりの魅力と言えばライブです。ステージを所狭しと走り回るパフォーマンスに、楽曲だけでなくMCでも観客を魅了する姿。いきものがかりの公演って週末公演や地方公演だと開演から終演まで3時間くらいかかるのが*2通常です。で、そのかなりの時間がMCなのですが、自分も他のアーティストのライブに行くようになって気づいたのですが、アーティストがみんなMCに多くの時間を割くわけではないらしいのですね。後MCでリード役をつとめるリーダー水野良樹さんの自虐ネタのトークも見物です。

さて、このアドベントカレンダーの作成者である (id:noobow34)の私といきものがかりの6年間 - ぬぼろぐにならって、私のいきものがかりライブ参戦歴を振り返ってみたいと思います。ちなみに私のものぐさな性格を反映して参戦歴を洗い出すのに、Twitterの過去つぶやきやらgoogleカレンダーやらmixiのつぶやきやら日記やらカレンダーやら掘り起こして大捜索になりましたが、色々と昔のことも思い出してきますね。

2009年

2010年

このころからチケットの取りやすさ等の関連で地方公演が増えてますね。ちなみに沖縄公演はファイナルの予定だったのですが、チケット二重発券の振り替え公演の影響で幻のファイナルになったことは尾を引き、いきものがかりの公演のファイナルに立ち会うのは2016年まで待つことになります。ローチケ許すまじ

2011年

この年のいきものがかりと言えばハマスタ公演ですが、広島でのファンクラスライブの時に私、仕事の関係で「夜公演終了(広島)→最終の新幹線で大阪→一泊→翌朝の始発新幹線で東京へ→会社のロッカーで背広に着替えて出社」というのをやっているのですが...何をやりたかったのでしょうね、私。

2012年

twitter.com

www.instagram.com

遠征はいいぞ。

2013年

この時期仕事が大炎上している中転職活動もしつつ、miwaもふくめると4ヶ月でライブ6本行っているのですが...我ながらこのパワーはどこから出てくるのでしょうね。

2014年

ライブツアーなし

2015年

この年はこれでしょうね。人生の運を使い切ったと思った。*3

twitter.com

2016年

いきものがかり10周年イヤー。開演前から降り続く本降りの雨のためずぶ濡れ、泥まみれの最悪のコンディションになった海老名初日が思い出深いです。

twitter.com

2017年

まだまだ続くよ!

*1:担当日基準

*2:平日の公演の場合は観客の帰りの便を考えて、若干つめる

*3:この時のライブは座席券が当日発券のため、席が決まるのは当日