GroovyのAST変換事情
Groovy言語ではAST変換をサポートしているのでその昔からAST変換をつかったライブラリがそこそこあります。 アノテーションでコード生成やボイラープレートなどの短縮、コード検査があります。
今回はAST変換の書き方というよりどういった成果物があったり、参考になる情報をまとめておきます。 本記事はG* Advent Calendarの12日目になります。
G* Advent Calendar 2017 - Qiita
- AST変換の方法
- AST変換の事例となる実装
爆速WebFW(らしい) Light-4JをGroovyから使ってみる
G* Advent Calendar 5日目の記事です。
JVM上で使えるWebAPIを開発するFWなどは多々ありまして、ハイパフォーマンスなものを探していたらどうやら Light-4Jというものがあるらしいと聞きつけました。 彼が言うにはそこそこ速いということで、ベンチマークも出しているんだぜと。
鵜呑みにはできないし、使い方とか知りたいので最小限のプロジェクトテンプレートをつくってみました。
JDK8が入っていれば、 ./gradlew run
で http://localhost:8081/baz で bazというテキストがレスポンスされると思います。
サンプルプロジェクトを移植しただけなので、Groovyらしさとかテストコードもありませんが。(ルーティング部分だけだったので)
Light4Jでは、Swagger 2.0, Open API 3.0, GraphQLに対応していたり、OAuth2.0に対応していたり、マイクロサービストレーサビリティ(X-Traceability-Id)に対応していたりとしていてよい感じです。(それぞれがライブラリで管理されているのもよい)
今回のプロジェクトテンプレートはそういったものは使っておらず、単純なAPIルーティング形式だけです。以下は使っている部分に関する知っていることの紹介です。
- Java向けを考えて開発されている
- 基本的な依存はundertow
- いろんなものがライブラリに切られている
- service.yml
- server.yml
- で、パフォーマンス
フロントエンドのテストツールとか気になっているやつ
テストツールというかサービス中心なんだけど、書籍情報も。
- WebGUIのテストIDE Katalon Studio
- JavaScriptのテスティングフレームワーク
- iOS Appiumで並列テスト
- AIでテストをやるっていう話
- テスト戦略書籍まとめ
Scrumを破る話とその補足。Scrumありがとう、そしてさようなら -Scrum 破- #rsgt2017 で発表してた
2017/1/13 に開催されたScrumのカンファレンスで「Scrumありがとう、そしてさようなら -Scrum 破-」というタイトルで45min話してきました。 スライドを公開するのずっと忘れていて、何度か再演もしているんだけど公開しました。2016年のチームの成果の話です。
カンファレンスのイベントページに書いたセッションの概要はつぎです。
ScrumをScrum Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。私達は2015年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透明性、検査、適応の3本柱を強化してきました。
私達はいまやスクラムに別れを告げつつあります。スプリントは1日以下で、ロール(PO, SM, Member)はスプリント毎にクジで決定し、スプリントレビューはPO以外が全員個別にデモします。テストやメトリクスも更に洗練され、いまや私達は自分達のタスクを最小6分単位でスケジュール、追跡し、改善に役立てています。
このチームが取り組んでいること、そしてどうしてこのようなことをやっているのかをみなさんにご紹介します。
背景とかこのチーム(基盤チーム)でわかったこととか
世界最高の製品開発チームとは何かを追求する実験場が基盤チームと言われればそうなんですが、単純にこのチームで仕事をするのが楽しいし、いろいろやっていることがどうも他の人と違うらしいってことはわかってきているので、事例紹介してフィードバックもらったり、誰かの参考になればいいかなぁと。
まぁ普通に考えて頭悪いとは思うんですけど、このチームを通してわかったのはマイクロマネジメントこそ最高である。っていうところですかね。以前の自分と比較して、プロジェクトマネジメントでマイクロマネジメントできないのは才能が足りないんだろうなって思うようになった。マネジメントはあらゆるリソースの使い方を考えて最高の成果を出すということが目的かなぁと思っていて、解像度が低い状態でしか判断できないって辛いよねっていうかね。高解像度かつ大画面なモニターがいいように、マネジメントもそのほうがよっぽどうまく違和感に気づけるのになーみたいな。
この発表は誰かに強制するものでもないし、ある状況ではこういったやり方や考え方もあるということを話しているだけな感じです。 ので、僕も例えば全く別のチームにいったり転職したりしたら、きっと違うことを考えるんだろうなぁとは思います。
Scrumの破であるという理由は、Scrumの3本柱である透明性、検査、適応は変えていなくって、この3つを重要視することは変えずにそれら以外は瑣末なルールだと解釈してScrum Guideを基盤チームオリジナルにどんどん変えていっているっていう感じです。
あぁ、そういう意味だとScrum GuideもGitHubにあると基盤チームでforkして公開するとかできて楽しそうですね。なによりチーム的にもわかりやすいかもしれない。
今までにいただいたフィードバックとか
- 控えめに言ってクレイジー
- 理想はこれなんですよねー
- ちゃんと聞くと当たり前のことを突き詰めているだけなのがすごい
- Extreme Scrum なんだよな
- もうScrumとかどうでもよくね
- kyon_mmは今後何年たっても「僕たちはまだScrumを忠実にやっているだけなんですよ」とかいいそうだよね。
- タイムトラベラーやな kyon_mmさんはタイムトラベラー
- そろそろ何周かしてしまっていて、勘違いしている人と話があっちゃいそう
今後とか現在とか
現在も形を変えてこのチームとして仕事をしていて、非常にたのしくやっています。できれば2017年の成果もどこかで話せたらいいなぁと考えています。 例えば、 #RSGT2018 (日本最大のScrumのカンファレンス 2018/1/11 - 1/12)とか。ただ、まだ公募に出していないので、ここでVoteしてね!って言えないんですが。 僕の話もいいわけですが、もしScrumとか製品開発に関わっているのであれば、これを読んでくださっている方はきっと #RSGT2018 で発表する素質がある気がするのでみなさんも公募を出してみてはどうでしょうか? 採用されなくても別に恥ずかしいとかはないと思いますし、去年は非採用のセッションをひたすら発表する別イベントがたっていたりしましたし、まず考えをまとめてみるだけでも、とても有意義かと思います。
次のサイトで 画面右側の + Propose Sessionボタンを押せば登録できます。
全体のことが書いてあるページはこっち
Regional Scrum Gathering Tokyo 2018 - Tokyo, Japan | ConfEngine - Conference Management Platform
まぁなんにせよ、ソフトウェア開発組織としての知見共有とか悩み共有して次の一歩を踏み出すという場はとてもよいと思っているので、その1つとして自分も貢献できたらなって思っています。
参考書籍
アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/01/18
- メディア: 単行本(ソフトカバー)
- 購入: 1人 クリック: 12回
- この商品を含むブログ (21件) を見る
- 作者: KentBeck,CynthiaAndres
- 出版社/メーカー: オーム社
- 発売日: 2017/07/14
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: マイケル・アブラショフ
- 出版社/メーカー: 三笠書房
- 発売日: 2015/06/24
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: マイケル A ウェスト,下山晴彦,高橋美保
- 出版社/メーカー: 東京大学出版会
- 発売日: 2014/05/12
- メディア: 単行本
- この商品を含むブログ (1件) を見る