(WIP) Seasar Conference 2015に参加してきた

f:id:tenten0213:20150928032045j:plain

Seasar2との出会いは4年半くらい前だった気がする。既に枯れてはいたが、それまでCOBOLや自社フレームワークを利用してきた自分には驚きと新鮮な刺激の連続でのキャリアに大きな影響を与えた、とても思い入れのあるフレームワークだ。

とはいえ、もう3年くらい使ってはいないわけなんだけど。そんなSeasar2の作者やコミッタ、ヘビーユーザだったエンジニアの、過去や現在、未来の話しが聞けそうだぞ!ってことで参加した。

参加したセッションは以下。

基調講演

当初ひがさんの「俺は守りに入らない、これが今の俺だ – DJ Yasuo」だった枠だったが基調講演に変わり、Seasar2の今後についてや、コミュニティ、ひがさん自身の考え方などの話しを聞くことができた。

初めにひがさんから、

明日はより成長していたい。Seasar2を使っている人にとっても同じことが言える。
使い始めは気付きや学びがあるが、1, 2年使うと大体分かってしまう。得られるものがなくなってくる。
やり遂げたという満足感があったら次のフェーズにいったほうが良い。
なのでSeasar2を使っている人には次の環境に行ってほしい。卒業してほしい。
Seasar2のサポートを1年後の2016/09/26で打ち切る

といった内容の衝撃的な発表があった。 発表の後、メインでメンテナンスをしてくれていた小林さん(@koichik)に対して会場全体から拍手が送られ、良いコミュニティだったんだなということが肌で感じられた。

その後はコミュニティと関わりの深かった人たちからの質問に対して、ひがさんが応える形式で進んだ。

内容がぱらぱらと飛ぶので、面白かった内容をいくつか。

なぜいまさらSeasar Conferenceなのか?

小林さんから「なぜいまさらSeasar Conferenceなのか」という質問が飛んだ。 自分自身も気になっていたのだけど、「飲み会で盛り上がったから」ってライトな答えが返ってきて笑った。 軽いノリではあるけれど、500人以上が集まるカンファレンスを企画し、実行した運営の方々は本当に凄いと思うし感謝だ。 その流れで、「そもそもSeasar Conferenceとはなんだったのか?」という話に。

元々は盛り上げるために企画したが、そこで力を発揮できる会社を見つけて活躍したり、優秀な人材を欲している会社が人を捕まえたりという場としても良かった。(当然それだけじゃないが)という話だった。

コミッタやコミュニティに深く関わっていた人たちの現在を知ると納得の内容だったし、素直に最盛期に参加してみたかったと思った。

世界で使われるプロダクトを生み出すプログラマに憧れる人へのメッセージを

佐藤さんから「世界で使われるプロダクトを生み出すプログラマに憧れる人はいると思うが、そんな人へのメッセージを」という質問?が。

大体以下の様な回答だったと思う。

一般の人は自分のアイデアを世の中に使ってもらって確かめたいと考えるが、自分は違った。
世の中の人がなにを望んでいるのかを考えた。
例えば、XML書くのが面倒で、極力書かないで開発をやるにはどうしたらいいかを考えて作ったのがSeasar2の最初。
Railsが流行ってScript言語良いよねって流れがあったが、Javaもいいよねとする為にHot Deploy機能を作った。
根本は他人が欲しているものを優先して考える。自分も欲しければ開発に着手する。
これをやると差別化に繋がると考えている。
素晴らしいと思っているアイデアが本当に素晴らしいかはわからない。

昨今のスタートアップに通じる考えを当時から行っていたのが伺えた。ここらへんの話しは別の時間に移った「俺は守りに入らない、これが今の俺だ – DJ Yasuo」でも繰り返し話をしていたので、かなり意識しているのがわかった。

Seasar ユーザだったプログラマが目指す OSS の世界展開

このコマは結構悩んだんだけど、OSSの世界展開って点を聞いてみたいと思って選択した。 時系列でどのフレームワークを利用していたか整理されていて面白かった。

2011年以降は新規の案件ではSeasar2を採用していないが、一部のサービスは現役で動いているとのこと。 サービスなので、投資してに作りなおすかどうかはシビアな模様。

当時を振り返り、SAStrutsS2JDBCのだけでも後継が育ったらよかったのでは、たらればだがGitHubが当時あればまた違った展開だったかもしれないという話しもあり、OSSを取り巻く環境の変化も感じた。

現在はScalaをメインに利用しているので、Scala周りのフレームワークの歴史を追いつつ、自身で作成しているOSSの話しに移った。

フレームワークの歴史の話しは会場が大学ということもあり、

という感想を持った。(ネガティブな意味ではなく、時系列でまとまっていて凄かった)

瀬良さんが作成しているOSSは、Seasar2(S2JDBC)やRailsから影響を受けているものも多い模様。

  • ScalikeJDBC
    • S2JDBCからの影響
    • Scala2.9時代に2Way-SQL簡易版を提供
    • scalikejdbc-gen: ソースコードの自動生成
    • 流れるようなインタフェース、QueryDSLに影響を受けたQueryDSL API
    • ScalaなのでJPAとは決別、JDBCだけ
    • sbtがあれば少ない設定で試せる
    • Railsにも影響うけている
  • Skinny Framework
    • GitHubスター数で世界4位
    • 2014年3月 1.0.0リリース
    • Scala On Rails
    • scaffold
    • DBマイグレーション
    • バリデーション生成済
    • ページネーション生成済
    • REPLっぽいことも
    • 既存DBからのコード自動生成
      • Reverse Scaffold
      • 管理画面面倒だなって時に便利

OSSを開発する際は、以下の点を気をつけていると言っていた。

  • コメントを絶対に日本語で書かない
  • ドキュメントは英語を優先
    • 日本語で情報を出したら英語でも出す
  • 開発者に直接会える国内で誰にも使ってもらえないのは話にならないが、かといって「日本でしかはやっていない」と思われたら負け

ScalikeJDBCSkinny Frameworkも英語のドキュメントが豊富で本気度合いが伺える。 良いプロダクトであっても、知ってもらう努力の大切さを感じた。

現在は、コードの改善や定期的なリリース、Gitterなどでのサポートはできているが、知名度を高めて国際的な場で個人として認知される必要性を感じているとのこと。

スライド

俺は守りに入らない、これが今の俺だ

誰もが気になっていたであろう、Seasar2作者のひがさんの現在について。 DBfluteの話しも気になるし、Play, Scalaも気になるし、羽生さんは要件定義の本とか楽々ERDレッスンにお世話になったし…で悩んだんだけど、今後直接聞けることも無いだろうから選択した。

ひがさんは現在、3つの学校に通いながら、宿題に追われつつダンスを作るためのハードウェアとかソフトウェアの仕様を決めているとのことだった。

そもそもの事の発端は、会社から「人が憧れるような、ダンスを作るハードウェア作ってよ!」と言われたことから。 プロダクトオーナーが「ダンスのハードウェアはKickstartarに出したい」と言ってきたのが面白いなと感じたようだ。 作ってみるまでわからないって世界だと博打だが、Kickstartarだと世の中でのニーズを知ることが出来る。 ここらへんは基調講演の内容にも通じる。

ひがさんの話しで特に面白かったのが、普通ならDJにインタビューをしてプロダクトの仕様を考えていくと思うが、それだと感覚的に一歩引いている。人にインタビューしているようじゃダメじゃないかなと根本的に思っていた、というところ。

自分が当事者になって感じるものをプロダクトに反映させないと、本当にいいものにならないんじゃないかって思いからDJ Yasuoになったようだ。

DJの勉強のために通っている学校の授業からフロアリーディングが重要だと学び、そこからプロダクトに反映させているようなので効果はあるのだろうし、そこまでプロダクトに熱中できるのは凄いことだと思う。

プロダクトとしては、現在はプロトタイプを作っている状態で、ハードウェアは得意な会社にお願いし、自分たちはダンスのCGや曲をつくっているとのこと。 12/6にアメリカのテキサス州で開催される、サウス・バイ・サウスウエストにPVを提出して賞を取ることを目標にしているらしい。

プログラマとしてのひがさんについては以下の様なことを話していた。

  • プログラマをやめるわけではない
  • プログラミングは得意だし、上手につかっていきたい
  • 今回はプログラミングの能力をすごい発揮してもあまり意味がない
  • 自分なりに一番効果的なものを選択している
  • 今後必要なタイミングになってきたらプログラマとして入るという選択肢もでてくる
  • 自分のプログラミング能力を過信するのではなく、プロダクトにとって一番いい関わり方を考えていく

今回の発表の中で曲やPVなどが聞けたり見れたりすることを期待していたが、見ることはできなかった。 2ヶ月以内にSoundCloudに曲を公開するとのことなので、プロダクトの動向も合わせて期待して待っていたい。

Seasarからクラウドへ、振り返って知る技術的に重要だった観点のある個人的観測について

ブログ書く力が尽きてきた…

聴講メモを貼っておく。

  • Seasarカンファレンスで現クックパッド社の高井さんとかが発表していたのを聞いてOSSの世界へ
  • AOP, DIが画期的だった
  • T2って作ったフレームワークの話しも
    • 現在では一般的になってきているが、4年以上前にアノテーションでパスを指定して動かすようなものを作っていた

振り返ってみると

  • 有用性は変わらない
  • 依存関係の管理
  • 本質的な部分をできるだけシンプルに記述する

2011年クラウドの世界へ

  • ひがさんの話しと似ている
  • 非連続的な成長
    • 階段的な成長しかない
    • 等価交換
      • コーディングすることは差し出した
    • スタートアップ、メディア、アダルトな...

知りたかったのは小売から見たITとITのそもそもの考え方の違い

  • デザイン有りき、エンドユーザの要望ありき

クラウドという境界線(使う|提供する)

  • 全体最適
  • 全体を滞り無くすすめるにはって考え方を学べる
  • お客様がいて、そこからどうやって積み上げていくか

IaaSかどうかより、Programmable Infrastructureかどうか

クラウドサービスで重要な点

  • ダイナミックなインフラ
  • コンピュートとストレージの明確な分離
  • 大企業でもバイトでも同品質のインフラが使える
  • よりスケールに主眼

ユートピアはこない

クラウドサービスで重要な点

  • 運用面
    • 落ちないシステムより、即座に復旧するシステム
  • サービスなので提供者が一元的に管理
  • 分散システム技術とデータベースがコア
  • システムが桁違いに大規模
    • 細かいところはアプリケーションで工夫したほうがベター
    • JRの電車と一緒で全体最適が中心
    • 個別最適ではない

DI, AOP, lightweight frameworkは役に立ったのか

  • 大きくなると役に立つ

クラウドまたはモダンなソフトウェアにおけるDI, AOP

S3MPER

  • Netflix製
  • S3とそれを扱うEMRでのデータ一貫性を保つためのライブラリ
  • 外からAOPで一貫性をチェック
  • DynamoとS3の間で

Netflix

  • 各マイクロサービスで再現が難しいとされる事象を各コンポーネントにインジェクト
  • 部分障害
  • レイテンシをあげる
  • 特定リクエストのシミュレーション
  • 障害をインジェクトし、どう振る舞うかを各マイクロサービスでテストできる
  • Netflixがやっているのをマネして?サービスを利用して?NIKEとかやり始めている
  • microservicesの課題
    • それを解決する

モノリシックからの展開

  • それぞれでスケールできる
  • それぞれでオーナーシップをもって開発できる
  • それぞれでSLAを守ってチャレンジできる

DIとの違い

  • モノリシックアプリケーションの依存関係を解決するのがDI
  • マイクロサービスは依存関係をアーキテクチャのレベルで出来るだけ解決
  • AOPの横断的関心事はマイクロサービスとして切り出して使われるかは難しいところ

Microservicesの今後

  • サービスが提供の最小粒度になる日
    • jar - war - AMI - Dockerfile/docker-compose.yml
  • 運用面などは直近でまだまだ課題
  • 促進するのはDocker/Container
    • AWSのAMIでも
  • 徐々に標準的なMicroservicesはオープンソースで提供されるようになりそう

技術的な課題

  • DevOps的な運用スタイル
  • ファンアウト
  • プログラミングモデル・データモデル
  • 認証認可(スケール)
  • ロットリング
  • サーキットブレーカー

クラウドプラットフォーム

  • 仮想化(EC2, RDS)
  • コンテナベース(ECS)
  • イベントベース(Lambda)

スタートアップの動向

  • No Stack Startup
  • APIの組み合わせでサービスを出す
  • クラウド事業社は水道、電気みたいな感じ

課題

ダイナミックでプログラミング可能なインフラを使うにはスタティックすぎる

  • クラウドネイティブな開発手法、設計手法
  • クラウドを活用するための言語・開発ツール
  • 運用手法、もっと手が抜けないか
    • 自動化を作りこむまでが大変
  • もっと整ってこないとうまく使えないのでは?(普通に使うのはできる)
  • そろそろローカルで開発じゃなくなりそうでは

DI, AOPは非常に重要な概念で、今から知っても遅くはない

  • DIがわからないと困るんじゃないか
  • Injectionできるのは依存関係だけじゃない
  • 依存関係を管理する方向から最初から分割する方向にシフトする
  • 技術動向は大事、バズワードとしてではなく、どう使えるか、複合するかが主流に

Spring Boot for the Seasar Developers –Seasarよ、これがSpringだ

お次は@cero_tさんのセッション。Springはなかなか社内で使う機会が無いのだけど、ライブコーディングが観たかったので選択した。

なぜSeasarが好きだったのかを以下のように振り返り、

なぜSeasarが好きだったのか

Seasar2.4時代(SA)

Spring Bootの概要を紹介してから

Spring Bootとは

ライブコーディングへと移っていった。

ライブコーディング

ライブコーディングはSpring Initializrを利用して雛形を生成し、"hello"と返すControllerを作成するところから始まった。

次にパラメータとして名前を渡して"hello, cero!"と表示するように修正したり、クラス追加、メソッド追加してもサーバの再起動をせずに反映される様子を確認した。Seasar2のHot deployに近く、サクサク開発が進められるのは良い。

ライブコーディングを実際に見ないと伝わらないかもしれないが、Springの以下のブログの動画を見ると分かりやすいかもしれない。


DevTools in Spring Boot 1.3 - YouTube

次に周辺ツール郡の紹介に移っていった。

Actuatorとremote shell

Spring Boot Actuatorの紹介では、実際にデモで使ったアプリの様々な情報(設定値やスレッドダンプ、マッピング情報など)をブラウザで確認した。 Spring Boot Actuatorを入れて追加されるエンドポイントは以下を参照。

続いてremote shellの紹介。remote shellは起動中のアプリケーションにsshで接続し、システムのメトリクス情報など、様々な情報を見ることができる。このremote shellは、CRaSHを利用している。(CRaSHは他にもPlay FrameworkやVert.xでも利用されている模様)

Actuatorやremote shellで取得できる情報のなかには準備なしで取りに行くと面倒なものもあり、問題が起きた時に調査しやすいというメリットは大きそうだ。

Spring Cloud

次はSpring Cloudの紹介。

Spring CloudはMicroservices時代のフレームワーク郡で、Spring Cloud NetflixなどNetflix OSSとの連携を簡単にするプロダクト郡も提供されている。特にNetflixが提供しているAWSサービス登録サービスであるEurekaと組み込みLBであるRibbonの紹介をしていた。EurekaRIbbonを使うと、簡単、柔軟にサーバ構成を変えられるようだった。(実装10行、設定15行とかそんなレベルらしい)

他に

などが紹介された。 凄いスピードで知らない単語が出てきたから合っているかは…。

まとめ

Spring Bootは周辺ツールが充実している。Java EEの開発スピードは遅いが、Spring Bootはオーナーが変わっていっているけどこのスピード感で開発が進んでいるのでSpring Boot良いよ!って感じだったと思う。実際目の当たりにすると凄かった。

SIは本当に終わったのか? – DJ Yasuo、大谷晋平、橋本正徳

あとで書く

LT

あとで書く