InsideFrontEnd 参加レポート2(JsonSchema編)
InsideFrontEnd 参加レポート2(JsonSchema編)
はじめに。
2017/02/25に開催されたInsideFrontEndの参加レポートになります。
本当投稿で2つ目となります。
前回の投稿はこちらの記事を参照下さい。
http://takahiro-fujii.hatenablog.com/entry/2017/02/28/222958
レポート : JSON Schema in Web Frontend
www.slideshare.net
今回はYahooの穴井さんのセッションのレポートをさせていただきます。
お題はJson Schemaの話です。今回、Json Schemaのケーススタディが聞けたのは非常に収穫でした。
Json Schemaの話はあちこちで出ていますが、
実は"実際にこういう風に使っている"というケーススタディの共有は、まだあまりないように感じます。
今回のセッションでは、リッチラボというyahooからスピンアウトした
リッチ広告を提供する企業(リッチラボ)におけるJson Schemaの活用法についてです。
主なトピックについて
・Json Schema / Json Hyper Schemaの活用
・FrontEndとBackEnd APIの意思疎通
・入力フォームについて
(他にもシステム構成についての説明などもありました。)
Json Schema / Json Hyper Schemaの活用について
FroneEnd App <-> BackEnd App 間で、Json Hyper Schemaを活用しているということでした。
Json Hyper Schemaって??
こちらをみて頂くと記載がありますが、
http://json-schema.org/documentation.html
The latest Internet-Draft at the IETF is v5, published 2016-10-13. (Due to a change in authorship the I-D numbering has been reset). The specification is split into three parts, Core, Validation, and Hyper-Schema
Json Schemaの3つある仕様のうちの1つ。Hyperはhyper-mediaのhyperです。
{ "id" : "b94318c0-cc7f-11e3-9c1a-094jkd00c9a66" "name" : "Takahiro Fujii", "email" : "hogehoge@***.com" }
Json Schema Core
{ "$schema": "http://json-schema.org/draft-04/hyper-schema", "type" : "object", "difinitions" : { "id" : { "type" : "string", "format": "uuid" }, "name" : { "type" : "string" }, "email" : { "type" : "string", "format" : "email" } }, "properties" : { "name" : { "$ref" : "#/definitions/name" }, "age" : { "$ref" : "#/definitions/age" }, "email" : { "$ref" : "#/definitions/email" } } }
Json Hyper-SchemaはURIの紐付けの部分の定義が記載されています。
英語で、ぱっと見読むのめんどくさそうな感じですが、そもそもそんなに難しい話ではないので、
一度腰を据えて読んでみるのがいいと思います。
http://json-schema.org/latest/json-schema-hypermedia.html#rfc.section.5
Json Schema Core + Hyper-Schema
{ "$schema": "http://json-schema.org/draft-04/hyper-schema", "type" : "object", "difinitions" : { ... }, "properties" : { ... }, "links": [{ "title": "Get User infomation", "description": "Get users resource information by id", "href": "/users/:id", "method": "GET", "rel": "self" },{ "title": "Create User infomation", "description": "Create users resource", "href": "/users", "method": "POST", "rel": "create", "schema": { "type": "object", "properties": { ... } } }] }
linksの中の各要素については、公式ドキュメントを読んでみてください。
24スライド目を見たらわかると思いますが、
1つ目のオブジェクトがRest apiのgetの仕様にあたる部分、
2つ目がcreateの仕様にあたる部分になります。
このセッションでは、あるアプリのFrontEndとBackEndを作成する際に、
Json Hyper-Schemaを定義し、それを元に、
- APIドキュメントの自動生成
- HTTPクライアントの自動生成
- モックの自動生成
を行い、お互いが(FrontEndとBackEnd)がお違いを気にせずに(疎な関係で)開発を進めることができる。
という実例を紹介されていました。
APIドキュメントの自動生成
APIドキュメントの自動生成(+多分json schemaの作成)
GitHub - interagent/prmd: JSON Schema tools and doc generation for HTTP APIsを使っているそうです。
有名ですね。が、使っていないので、使って見ました笑
mkdir -p schemata prmd init user > schemata/user.json
これで、user resourceのrestful apiのサンプルjson schemaが生成されます。
最初からこれを例にして話をしてもよかったかもしれません。笑
あとはgithubのusageにそって進めていくと、、
markdownを生成
prmd doc schema.json > schema.md
schema.mdが簡単に作れます。
開いてみると、こんな感じでapiドキュメントが生成されます。
非常に簡単です。
モックの自動生成
モックの生成は、自作のライブラリを使っているようです。
https://github.com/richlab-corp/schema-to-db-json
さっそく、先ほど作ったschema.jsonを食わせてみます。
# Generate db.json from JSON Hyper-Schema schema-to-db-json schema.json > db.json
次のようなdb.jsonが作られました。
tf:tmp fujiitakahiro$ cat db.json { "apps": [ { "created_at": "2017-01-01T00:00:00+09:00", "id": "01234567-0123-0123-0123-0123456789ab", "name": "ABCDEFGHIJ", "updated_at": "2017-01-01T00:00:00+09:00" } ], "users": [ { "created_at": "2017-01-01T00:00:00+09:00", "id": "01234567-0123-0123-0123-0123456789ab", "name": "ABCDEFGHIJ", "updated_at": "2017-01-01T00:00:00+09:00" } ] }
次にjson-serverを立ち上げます。
tf:tmp fujiitakahiro$ json-server --watch db.json \{^_^}/ hi! Loading db.json Done Resources http://localhost:3000/apps http://localhost:3000/users Home http://localhost:3000 Type s + enter at any time to create a snapshot of the database Watching...
mockを返してくれるAPIが立ち上がりました!
簡単。
これでFrontEndはこのmock apiを使って開発が進められますね。
HTTPクライアントの自動生成
golangはherokuが作っているやつを使っているみたいです。
github.com
jsは自作中とのこと。
個人的にはクライアントライブラリはあったら便利かなぁ位なので、いいかなと。
クライアントライブラリの管理はbackend側がやるんでしょうか。
それか、一緒にメンテしていく感じなのかな。小さい規模なら特に問題なさそう。
ということで、簡単にmock apiを立ち上げて開発を進めていることがわかります。
さらに、仕様のドキュメントを作る過程が開発の過程の一部になることで、
プレゼンでもおっしゃってましたが、
仕様と実装がシンクする
というメリットがでてきますね…!いけてる。
FrontEndとBackEnd APIの意思疎通
プレゼンの中で、"合意"という言葉を使われていたのが気になりました。
おそらく、CDCのようなことなのかな、と思いました。
実際にはどのように合意をするのか結構気になります。
(自分に時間がなくあまりここらへんは聞けませんでした、、
(Pull requestのapproveが合意ってことなのかな
CDC
https://martinfowler.com/articles/consumerDrivenContracts.html
pull requestのapproveが合意だとすると、規模が大きくなってきたときに、
修正の妥当性をどのように担保していくのか、というのが気になりました。
お互いがjson schemaを元にテストを書く感じなのかな。
それか、pactやspring cloud contractのような仕組みを使うのか。
pact
techlife.cookpad.com
spring cloud contract
Spring Cloud Contract
入力フォームについて
リッチ広告は設定項目が非常に多く、複雑なフォームが多いらしい。
設定値が複雑だったり、入力値の検証だったり、動的に入力項目が変わったり、、
大変そう・・
react-jsonschema-form
というmozillaが作っているReact Componentを利用しているとのこと
知らなかった。。。
- validationをjson schemaベースでやってくれる
- カスタマイズが柔軟
というメリットがあげられていました。
バリデーションがjson schemaでやってくれるのいいし、
あとはreact componentはカスタマイズが本当に大事だと思う。
どんなにバリデーションの所がいけてても、出したいUIに変えられなかったら使えないですし。
react-jsonschema-formはここで試せます。
validationはかなりいけているので、どれくらい柔軟にカスタマイズできるのか、
近いうちに試してみようと思います。
まとめ
まずは、Json Schemaを使われている事例を聞けたのが何よりも参考になりました。
早く、課題をクリアして、Json SchemaをFrontEndとBackEndをつなぐのに使いたいなと思いました。
また、質問したところ、Json Schemaを直接BackEnd側のバリデーションで使っていないということでしたが、
ここは是非実現したいところです。
特に、自分が今携わっている環境だと、APIのConsumerが複数いることが多かったり、フロントエンド意外にAPIを直接呼ぶような(Gateway API経由とかで)が割とあります。
そうすると、validationを複数の箇所でそれぞれ実装してしまうと、何かのタイミングでvalidationがずれて、後で問題になる、、
みたいなことが起きやすいイメージがあります。
Json Schemaは少なくともFrontEnd / BackEndを疎にして開発を高速化するのに役立ちますが、
それだけではなく、1ResourceのValidationの定義を一箇所にまとめることができれば、特に中規模、大規模の開発においては大きな威力を発揮する、、と思います。(実現するにあたっての課題はあると思いますが
あとは、更新する場合は穴井さんもおっしゃってましたが、versioningするのが開発のスピード落とさない為にはいい、、と思いますが、
これも同じくおっしゃっていたように、あまり多段でversion管理しまくるのも厳しいので、そういうのを防ぐ仕組みの元でしか出来ない方法なのかな、、とも思います。
schema-to-db-jsonは便利だった!個人的な開発でまずは使ってみたい。
課題があるけど使って見たい、、と思わせるJson Schema。
事例が聴けてよかった。次は自分達の事例が話せるといいな。
InsideFrontEnd 参加レポート1(コンポーネント化って?)
InsideFrontEnd 参加レポート(コンポーネント化って?)
はじめに。
2017/02/25に開催されたInsideFrontEndの参加レポートになります。
今回、このイベントに参加するにあたり、ブロク書く枠、という形で参加してみました。
イベントの参加レポートを書くことは今までもありましたが、
「ブログ書く枠」として参加したのは初めてなので、
ちょっとドキドキしています。
僕はどんな人か
実務でいうと、割とバックエンドないし、
フロントエンドとバックエンドの間に入るような仕事をすることが多いです。
フロントエンドばりばり!な感じでは全くないです。
ただ、フロントエンドの実装をやることもありますし、
シングルページアプリケーション(SPA)を実務で実装したこともありますし、、、
ただ、実務経験としてはバックエンドが多いかなぁ、という感じです
フロントエンド好きなので、個人でwebsiteを作ったり、
仲間内のプロジェクトではフロントエンドやったりします。
比較的個人でしかやっていない分、技術的はまだしも、
実際のフロントエンドエンジニアの皆さんがどのように開発されているか、
という知見に疎いです笑
なので、今回の勉強会は非常に新鮮で、楽しませていただきました。
InsideFrontEndとは?
InsideFrontEnd
http://inside-frontend.com/
Opening Talkにて、InsideFrontEndというイベントがどのように開催される運びになったのか?という簡単な説明がありました。
本イベントは、
Yahoo Japan/Cyber Agent/日本経済新聞社
の三社で合同開催されていますが、
元々、各社それぞれフロントエンド系の勉強会を主催されていたそうです。(もしかして、知ってしかるべきだったのかもしれませんが、、w)
会社 | イベント |
---|---|
Yahoo Japan | SCRIPTY - イベント一覧 - connpass |
CyberAgent | Frontrend powered by CyberAgent, Inc. |
日本経済新聞社 | Frontend Meetup Tokyo - connpass |
どのイベントも結構人がたくさん入っています。
個人的にはFrontEnd Meetup Tokyoで昨年開催された"W3C TAG デベロッパー・サミット"がすごく面白そうだなと、、(今更ながら)
今後、これらのイベント開催もきちんと見ておこう、と思いました。
また、個人的には今まで参加してきたカンファレンスで、
あまり日経さんがこういったスポンサーをされている会に参加したことがなく(知らなかっただけ?)、新鮮でした。
ただ、UIやフロントエンドと日経っていう結びつきは、たしかにすごく強いなって。新聞ってフロントエンドそのものだし。(もちろん新聞だけじゃなく、web版はvisual dataなど今では様々なものがありますが)
参加したセッション
結構聴きたいセッションが被っていて悩んだのですが、ひたすらセミナーBのセッションを聞きました。
B1 : Web over ServiceWorker
https://speakerdeck.com/jxck/web-over-serviceworker
B2 : Web フロントエンドにおけるコンポーネント化のアプローチ
https://speakerdeck.com/1000ch/component-of-web-frontend
B3 : Refactoring CSS: 管理されたカオスへの道のり
B4 : データビジュアライゼーションの作り方
http://shimz.me/slide/inside-frontend_1/#/
B5 : JSON Schema in Web Frontend
アメブロ2016: 実録、アメブロフロントリニューアル275日
がかなり面白そうなので、後で資料を読みこもうと思います。
今回、ちゃんと全セッションのレポートを最初からできれば良いのですが、自分の知見の無さや、コードをまず書いてからレポート書きたいものもあり、順次レポートとして公開する形にできれば幸いです。
レポート : Web フロントエンドにおけるコンポーネント化のアプローチ
今回はこちらのセッションのレポートをさせていただきます。
本セッションでは、
・コンポーネント化に関連した問題
・コンポーネント化をどのように実現・管理するか
・協業実践に向けた方針
などについて述べられていました。
個人的には、SPAの開発を経験してから、
コンポーネント化について考えることが多くなりました。
とはいえ、あまりセッションでこういった話を聞きに行ったこともなく、
そういった意味でもこのセッションを非常に楽しみにしていました。
コンポーネント化に関連した問題
スタイルガイドについて
少し前まではスタイルガイドが全てを解決してくれる、、というところから始まりました。
実は、恥ずかしながら(HTML+CSSで管理する)スタイルガイドを運用する形で
開発をそもそもやったことが無く、どんな感じなんだろう・・・??というレベルでした笑
スライドの背景になっていた下記のサイトを見てみました。
The Buffer Style Guide
https://buffer.com/style-guide
とっても綺麗にまとまってます。。。
僕はこれがある状態で(僕自身が)フロントエンドの実装ができたら嬉しいです。
発表者の方は、スタイルガイドを利用した開発でまそもそも開発が上手くいったことがないそうです。
「スタイルガイドを利用した開発フローで上手く行っている所ありますか?」
ということを会場内でアンケートした所、若干名の手があがっていました。上手く行っている所もありそうです。
そこで、なぜスタイルガイドを利用した開発が上手くいかなかったのか、という話になります。
The Buffer Style Guideを見たときにも感じたのですが、
組織構成によっては、"このドキュメントが何のためか"というのがぶれるなと思いました。
セッション/スライドでも話がありましたが
デザイナーがHTML+CSSを修正不能なら悪手
というのはその通りだと思います。
このパターンのコンポーネント化をしたいと思うのは、
大体の場合が
エンジニア側が再利用を促進したい
が発端な気がします。しかし、この流れだと、
デザイナーが一緒にコンポーネント化のビジョンを共有する
ことが難しいと感じました。
デザイナーの手の届かない所でスタイルガイドが管理されてしまうというのが
問題です。
- 開発が修正したスタイルガイドがデザイナーにキャッチアップされない。
- デザインしたものが全てきちんとスタイルガイドに反映されない
ということが発生すると、メンテナンスされなくなっていき、機能しなくなるなと。
そこで、デザインファイルで管理するという話があがっていました。
そうすると、デザイナーが継続してメンテナンスできると。
デザインファイルをコンポーネントの用に管理して(Photoshopの外部ファイル参照?)デザインファイルをコンポーネント管理できたら非常に素敵だな、とは思いました。
綺麗にデザインファイルを管理してもらうメリット、
それがコンポーネント化に繋がっていくというビジョンをデザイナーの方と共有できるといいなと感じました。
コンポーネント化をどのように実現・管理するか
プラットフォーム毎のコンポーネントを成す技術
ここでは、具体的にHTML+CSSでコンポーネント化を行う際の話がありました。
これは誰もが感じたであろうHTML+CSSの辛さですね。。
ここでは、その対策として最近スタンダードになってきている(?)
CSS Modules, CSS in JS,ShadowDOMが紹介されていました。
CSS Modulesは使ったことがありますが、CSS in JSは使ったことがないので、試してみようと思います。
CSS ModulesとCSS in JSの比較は結構いろんなところでされているようです。
e.g)
http://morishitter.hatenablog.com/entry/2015/09/28/103334
http://postd.cc/modular-css-with-react/
http://blog.kubosho.com/entry/css-in-js
CSS Modules
https://github.com/css-modules/css-modules
import styles from "./style.css"; // import { className } from "./style.css"; element.innerHTML = '<div class="' + styles.className + '">';
webpackでコンパイルする際に、一意で衝突しないクラス名が生成され、styleも当たります。
実装上はそれを意識する必要がありません。
sample site
https://css-modules.github.io/webpack-demo/
CSS in JS
https://github.com/MicheleBertoli/css-in-js
var style = { sample: { backgroundColor: "#fff" } } var Sample = React.createClass({ render() { return <div style={style.sample}>HOGE</div>; } });
こちらは、よりcssをjavascriptの一部の属性として扱っている感じがあります。
ただし、CSS in JS自体はアプローチであり、特にSPAを作る上で使えるライブラリはめちゃくちゃ沢山あるので、それにもよるかも、、。
Shadow DOM
@tonkotsuboy_comさんが共有されていたこちらの記事が分かり易かったです。(が2回以降が見たくなってしまいました。。笑)
Shadow DOMについてはCodeGridさんの記事がわかりやすいです。
— 鹿野壮(かのたけし) (@tonkotsuboy_com) 2017年2月25日
→ 先取り、Shadow DOM - Shadow DOMが生まれた理由 | CodeGrid : https://t.co/DNslzi5IiF#insidefe #insidefe_B
実装例に関しては、@kei_n_n_iekさんが共有されていた記事が大変わかりやすかったです。
shadow DOM めもhttps://t.co/bQkqMQ2yr8https://t.co/HcgaHX0uku#insideFE
— kei (@kei_n_n_iek) 2017年2月25日
こういった技術の登場により、スコープが無く苦労していた
HTML,CSSにも概ね、コンポーネントを意識した実装方法が可能になってきました。
協業実践に向けた方針
あまりこういった話も直接セッションで来たことがなかったので新鮮でした。
(よく議論されていることだとは思うのですが、、)
ここで記載されていた内容で、自分が一番共感できた部分は、
- 一方通行な開発にならないこと
これにつきます。
コンポーネント化にしても、スタイルガイドにしても課題解決の一つの手段であるはずなので、課題がきちんと共有できていないと、
小さいサイト規模からのコンポーネントや、デザインファイルのコンポーネント型の管理は非常に難しいのではないでしょうか。
まず大切になってくるのは
- パーツを再利用することのメリット(一貫性や、開発速度の向上)の共有
- コンポーネント化をしたいと思う人が、裏で思っている課題の共有
- 毎回似通ったボタンをいちいち実装しないといけない
- 一貫性がなく、文言変更や、特定のデザイン変更があった場合の修正がすごく大変
- パーツの使い回しができないことによって、開発速度が落ちていると感じる
- デザインをする際に細かいパーツの設計に毎回時間をとられ、全体のディレクションやUX設計に時間がとれない
- デザイナー毎にデザインのばらつきが出すぎて、一貫性が弱い
個人的にはメリットの共有よりも、課題の共有の方が共通認識を持ちやすいと思います。
セッションを受けて
自分ならコンポーネント化したい?/どういう風にコンポーネントの管理をしたい?
- 継続的な開発/運用が求められるサイト・システムにおいてコンポーネント化は必要
- スタイルガイドは、デザイナーはデザインガイドで管理し、開発側が開発側の管理の為にスタイルガイドを用意※
これはシングルページでアプリを実装する場合がイメージしやすく、
Pivotal Styleguide
http://styleguide.cfapps.io/
のような、UI componentを開発側で管理するようなイメージ
- デザインガイドと、スタイルガイドの一貫性を保つために、どのような仕組みやフローでコミュニケーションするかは考えないといけないと思います。。
という疑問。
zenhack 2016 fallで僕らはどのように開発を進めたかその2
こういうのは続きを早く書くのが大切ということで、第二回目の記事を書かせていただきます。
2回目は、振り返りを書かせて頂きます。
良かったこと・良くなかったこと・次はこうしたいの3部構成でお届けします。
良かったこと
機能の役割分担できたよ
前回のarchitectureにある通り、
FrontEnd/API/Engine(写真集めと解析)という3つのアプリに分けたことと、
最初にAPIが何をどこまでやるかということを明確しました。
具体的にやったことは、
- likeを付けた写真の(登録、参照、更新)
- 現在地の近くにある写真のリストの取得
とそれぞれのインタフェースを定義だけではありますが。
これは、短時間の開発でもやはり有効だということを再認識しました。
このおかげで、FrontEndをやっていた僕らがそんなにAPIがやってることに口を出さずに(笑)、
- それぞれの間でどういったデータのやりとりをするか
ということだけを気にして、黙々と開発出来ました。
「ここ、どうする?」みたいな数が極力減ったことは
今回のhackathonのような短時間の開発でもスピードアップに繋がるとおもいました。
人の役割分担できたよ
元々は、僕の役割はそこまではブレてないんですが、こんな感じのイメージで、
そうとう野望ある役割分担をしようとしていました笑
ありとあらゆるデバイスで何か作ろうと、、笑
でも始まってすぐ時間が足りないってことに気づかされ、あっさり諦めて役割を考え直したことは良かったと思います。
今回のhackathonでどうであったかはさておき、
- taka66(僕) / Design,HTML,CSS,JS(モックアップ) + プレゼン資料作成
- sideroad / FrontEnd(SinglePageApplication(React.js)) + interaction animation(js) + Infra(Heroku)
- nab / API
- kojiro / API + Infra(AWS)
- okame / Photo search Engine
短い時間の中でプロダクトをどのように完成こと
ということはものすごく大切だと思っていて。
時間の中で動くものを作る為にこの役割分担に行き着いたのは良かったと思っています。
Done is better than perfect..
機能を削ること
実装を初めて比較的早期に、いくつかの機能を最初の実装から外すことを決めました。
例えば、現在地の近く意外の場所から検索する機能と、カテゴリに分けてそこから検索する機能などです。
最小限でコンセプトを伝えられる機能を実装して、残り時間があれば拡張しよう。
というポリシーでいきました。分かってはいるものの、考えているとあれやりたくない?
みたいなことによくなるので、hackathonではお互いにいい案配で指摘しあえることも大切だと思います。
ただ、削っている間にコンセプトを見失って、実装しやすい機能だけ実装する
ということはもちろん望ましいことではありません。
ので、機能を削る時は、自分たちが作るもののコンセプトに必要最小限であるかどうかで
優先度を考えるのがいいと思います。
自分たちが作ったものを気に入ること
これは結果論も半分です。
感覚的な話ですが、これはおよそ上手く行っているバロメーターとしては比較的正確だと考えています。
時間が無い中で、作るプロダクトは不完全なところもあります。
それでも、作っているサービスを好きでいられることは、みんながそのアプリに可能性を感じて入れていて、
コンセプトにある程度納得がいってるということにもなると思います。
個人的にはロゴとかアプリ名とかがあると愛着がますので、合間の時間を使ってなんとかロゴを作りました笑
良くなかったこと・考えること
目的・テーマへの理解と先入観
こちらは特に個人的な振り返りになりますが、
正直、
お題:「観光」
ここだけ見てたなーってのはあると思います。禅ハックのサイトをみて、申し込んでた時に考えたことは、
観光に役立つアプリを作るってこと。
そこだけ見ていて、
・協賛の鎌倉市さんの観光に関連した資料のデータの使い方、理解が不十分だった。
・後は、禅をより深く絡める、禅の考えを活かすこと。
やっぱりhackathonにはテーマがあって、そこには主催者が解決したい課題があります。
そこへの解決の道筋を見せられることは、大切なことだったなと。
誰の為のものか
ここもお題に付随するところなんですが、
- > 観光に役立つアプリを作ること。
を考えると、まず最初に浮かぶのは観光客にとって役に立つもの
っていう発想になると思うんです。これ自体は間違っていないと思います。
ただし、もちろん観光を受け入れている側の方々もいて。
今回のhackathonは、受け入れることに携わっている方も多くいました。
基本的にはユーザはやっぱり観光客ですし(もちろん作るアプリによりますが)、
その場合、彼らに使ってもらえないことには、何もないというのはあります。
ただ、彼らに使ってもらうことで、受け入れる側の課題がどのように解決されていくか。
そこはもっとしっかりプレゼンなどで伝えるべきでした。
申請が必要なAPI
ってまぁまぁあるじゃないですか。事前に申請しとけって話でうね。
使う可能性を感じるものは。
次はこうしたい
- テーマの理解と、その上で何を作るかっていうのを先入観なしで、考えられているかどうか見つめ直す時間をブレストの完了前に作る・自分がその視点を持つ
- 事前に関連するAPIは使えるようにしておく(特に申請が必要なもの)
- もっと、オレオレテンプレートを作り込んで、デザインでも、アプリでもwebでも、最初の一歩を踏み出せる時間を早くする。
- SPAの為のマークアップを勉強する(次も同じ役割やるかどうかは分からないけど
- このhackathonはチームで参加してるところは結構少なくて、1人で参加してその場でチーム作ってる方がかなり多かったので、そういう参加の仕方をすると、また違った感想を持つ気もしますし、そういう参加の仕方をしてみたいなって。
って感じかなー。時間かけて振り返ればもっと出てくることはありそうだけど。
おまけ(オリジナルシャツ作り)
今回、hackathonの開催にあたって、
チームの気合をいれる為にTシャツ、ポロシャツ、シャツを突貫で作ってきました。
急にオリジナルグッズを小ロットで作りたい時は、毎回渋谷の
ARTON.CO.LTD
さんにで作ってきました。
ロフトの隣です。プロントの上です。
個人的には何度もお世話になっています。
Illustratorでデザイン作って持って行って、artonでdesignちょっと調整して印刷。
っていうことをちょこちょこやっています。
その場で出来るってのがなんとも素敵ですし、1枚1枚違うデザインで作れたりもしますし。
小ロットで作るには安いし、その場で素材色々選べるし。
印刷の位置スタッフさんと相談できるし。
シャツ1枚、ポロシャツ2枚、tシャツ3枚+みんなそれぞれアイコン入りなんて、ここでやらなかったらかなり面倒
大変おすすめです!
zenhack 2016 fallで僕らはどのように開発を進めたかその1
先日、鎌倉は建長寺で開催された、
禅ハック2016 Fallにメンバーを集めて参加してきました。
www.zenhack.jp
チームkoiki
結果優勝することは出来ませんでした。
しかし、技術的にはかなり様々なブレイクスルーを短時間の内に経験し、
チームとして、アウトプットしたプロダクトに満足することが出来ましたし、達成感もありました。
また、一緒に参加していた別のチームの多くの方々から良い評価を頂けたのも嬉しい点です。
この記事では、
・どのように僕らが作業を分担して開発を進めたのか
・プレゼンではお話出来なかったより具体的なarchitecture
・課題と解決、反省点(これは次回の記事で)
など、まとめていきたいと思います。
※今回はほぼ備忘録的な記事になっています。すみません。
前置き
まず、建長寺でやれるってことを知らなくて汗
お寺でプログラミングだー!って感じなだけだったんですが、
いざ行ってみたら、まずお寺すげー!ってなりました。
歴史、由緒あるお寺の中で、開発に集中できたこの経験は、
禅ハックでしか味わうことが出来ないものだと思います。
僕らがつくったもの
最初に、僕らが作成したプロダクトのデモを紹介します。
今回、「SPOT4U」というWebアプリを作成しました。
このアプリは、今自分の近くにあるスポットの写真が紹介され、
・興味がある、行ってみたい所を右にスワイプ(興味がないものは左)
・一定数見た所で、自分の興味がある場所のリストを表示できる
このリストには、
・自分の現在地からの距離
・スポットの名前(とれる場合)
・現在地からのルートへのリンク
といった情報が表示されます。
(youtubeにあげたものでは、スポットの名前が取れてないんですが、
これはnabがコード直せば再びでるようになるはずです笑)
簡単にいうと、現地で「次どうする…??」みたいなことになった時に使って、
身近にあるいけてるスポットを見つけられるっていうアプリです。
発表時のスライドは、speaker deckにあげていますので、
こちらも興味があればみてみてください。
speakerdeck.com
Zenhackのタイムスケジュール
今回のzenhackのタイムスケジュールは、
Schedule 2016 - ZenHack
にも書かれていますが、このようになっています。
1日目
09:30 建長寺の門の前に集合(北鎌倉駅から徒歩15分) まとまって入場&受付スタート
10:00 オリエンテーション、ルール説明、インプット
11:30 チームビルディングワークショップ
13:00 ランチ
13:45 ハック開始
15:00 おやつ
18:00 夕食&企業プレゼン
19:30 入浴
20:45 就寝準備
21:00 就寝
2日目
03:00 起床
03:20 本堂集合
03:30 座禅
04:10 ハック再開
06:00 朝食(お粥・建長寺提供)
07:00 ハック再開
08:30 おやつ
12:00 ランチ
13:15 ハック終了、会場準備
13:30 発表会
15:00 審査、休憩
15:30 表彰、総括
16:00 集合写真撮影
16:30 終了・解散
この中で、プロダクトを作ることができる時間は下記の通りです。
1日目
11:30~13:00 案出し
13:45~18:00 4.25h
2日目
04:10~06:00 1.83h
07:00~12:00 5.00h
12:30~13:15 0.75h
合計 案出し+約11.83h
今回、僕らは5人で参加したので、実作業時間は60hといった所です。
案出し
事前に各々少しアイデアを考えていたんですが、ブレストが始まって、
結局その場で考えたアイデアをベースにして作りました。
考えたアイデアの中から2案を各々がピックアップして、
それを参加者みんなで見て回って、いいと思ったやつに★をつける、といったことをやりました。
その中で、うちのチームで一番票を集めたのは、
kojiroくんの
・写真を見せた時の「心拍数」を測定して、その写真がいいかどうかを判定し、
興味がありそうな場所、おすすめの場所を教えてくれる
というものでした。
ここから、実際に作るプロダクトを考えようとなった時に、
・「心拍数」はかれるデバイスないやん
・これでやりたいことは、余計な情報を見ずに(写真だけみて)
ユーザが純粋に良いと思う感覚をもとにレコメンドできること
みたいな話になって、SPOT4Uの原型が朧げながら出来たという感じです。
フリックするUIを選択したのは、
心拍数を測る、みたいにユーザにアクションなしで自動で判定することはできないまでも、
より多くの情報をユーザが短時間に興味があるかないか判断できるようにしよう
という所から来ました。
また、最初は探したいスポットを入れて、
その場所の近くを検索するという案もありましたが、
・ユースケースを限定して、よりそのアプリを使う目的を明確にしよう
という所と、
・UIのステップ数を可能限り減らす
・ユーザに情報入力させたくない
という所から、
今いる場所の近くを探すという使い方に限定してまずはアプリを作成することに決めました。
メンバー構成・役割分担
メンバー構成
下記のメンバーで参加しました。
今回、全員エンジニアなのと、僕がデザイン周り好きなこともあって、
自分がデザイナーっぽい立ち位置のロールをしました。
受付でエンジニアですか?デザイナーですか?って聞かれて、
「デザイナーです。」って答えた時に新たな自分になった気がしました笑
個人の仕事ではやってたことは一応あるんですが。
役割分担
後ほど詳細を書きますが、今回役割分担はかなり上手くいったと思っていて、
上記の作業時間で、誰かの手があいたり、ブロッカーの作業が発生するといったことがほとんどありませんでした。
これは、作業開始時に各プロダクト(FrontEnd/API/Engine)の役割分担を明確にして、きっちり分けたことが良かったと思っています。
結果としてEngine周りの細かいロジックは分かっていない所もあって、近々お互いの実装について説明しあうことが必要だなと思っています笑
アプリケーション構成
上の役割分担からおおよそ構成もつくかもしれませんが、アプリケーションの構成は下記のようになっています。
SPA(フロントエンド)
・フロントは、React使ってシングルページアプリケーションとして作りました。
最終的なアプリの機能・使い方としてはネイティブアプリで作っていいな、という内容でもありましたが、
・時間内にサイトを公開したかったこと
・各人のスキルセット
を考慮して、このような選択をしました。
API(バックエンド)
・APIはnab,kojiroの2人がrubyがいいっすってことだったので、rubyでやってもらいました。
アプリをきっちり分担したことで、各プロダクトで各々が得意な構成で作ることができました。
kojiroくんが持っている環境(AWS)があったので、そこにAPIをのせることになりました。
写真を集める
・最後に写真を集めるところですが、ここはみんな知識がそんなに無かったんですが、
ここは万能エンジニア、頼れるもと同期のokameさんの力を借りまして(というか任せて)、実現してもらいました。
Hackathon期間中の成果としては、
1)Flickr,Twitterから位置情報つきの画像を集める
2)FacebookのGraph apiで位置情報からスポットの場所を特定する
ということができるようになりました。
・Flickr,Twitter,FacebookのAPIなどをリクエスト時にcallするという方法もあったんですが、
できればレコメンドしたいねって話になった時に、
一回それの解析やるためにデータとって解析するところは別で作ろうって話になり、スクレーピングするスクリプトを作ってもらいました。
実は結果としてレコメンド組み切る所までの実装は出来なかったので、ここの実装、仕組みについては、もう考えようもあったなと今は思っています。
・IBMのWatsonの中にAlchemyVision apiという機能があって、
画像のカテゴリとスコアを返してくれるAPIがありました。
これも使えたなー、、とあとから。
http://qiita.com/knao124/items/60dc430fc31bf85b0e60#2-2-alchemyvision
・InstagramのAPIももちろん使いたかったのですが、申請が間に合わず。
こういうAPIセットはhackathon時は事前に用意しておくべきですよね、、(毎回思うんですが笑
ということで
フロント2名
バックエンド2名
エンジン1名
っていう分担です。
hackathon
さてさて、あとは時系列別にどんな感じでアプリが出来ていったのか
ということをまとめていきたいと思います。
とはいえ、他のロールの進捗を完全に把握しているわけではないので、
近々みんなでもう一度集まってヒアリングしたい気分です笑
コミュニケーションはslackで行っていました。
1st(13:45~18:00 4.25h)
最初の30分〜60分位は
・作るもののイメージを固める話し合い
・アプリの大まかなアーキテクチャ
・役割の確認
をしていました。
その後、各自作業を開始しました。
taka66(僕)
・なんとなくのUIの絵を描いて、話し合い with sideroad
・IllustratorでUIデザインを作成(15:30に一度目のデザイン案が完成)
・最初にTOPページを決めちゃってベースのHTML,CSSを作成(16:16に最初のpush)
・その後他のページのHTML,CSSの実装を始める(途中まで)
sideroad
・SPAのベースのプロジェクト作って、herokuにdeployできるようにする(~14:20)
・API側のインタフェース要件を考える(~14:40)
・TOPページのHTML,CSSをあてる
・ベースの作り込み
nab + kojiro
・APIのベースプロジェクトを作る
・sideroadとAPI要件のすり合わせ
・AWS上にRubyのアプリをdeployできるようにする(~15:40)
・画像LikeするAPIの作成(~16:21)
・画像を登録するAPIの作成(~17:29)
・レコメンドAPIの作成(途中まで)
okame
・写真とるのにいいAPI探してAPI仕様の確認をする
・twitterから位置情報付きの写真を集めるスクリプトの作成
・スクレーピングしたデータの投入(~17:49)
そのあと、お風呂に入る時間の合間の時間が少しあったので、
taka66
・最後のページのUIがいけてないことに気づいて作り直す(~20:55)
から
2nd&3rd(04:10~12:00)
座禅後に始まったハックの時間ですが、禅の効果なのか、、、
04:00-08:00位に、めざましく進捗した感じがありますw
07:00くらいから、mockではなく、実際にデータ使って一通り動かせるようになってきて、
エンジニア勢はみんなテンションが上がってました。
やっぱり、エンジニアにとって、動くものを作り出せたタイミングのこの気持ちは何にも代えがたいです。
taka66(僕)
・バグ修正
・HTML,CSSの改善
・結果表示のHTML,CSSの実装
・Like用のHTML,CSSの実装
・アプリ名とロゴデザインをどうしてもうやりたくて始める笑(~05:15)
・フリックアニメーション用のアイコンの作成
・TOPに表示する為の画像の撮影、動画の撮影+加工
・デモの練習
・プレゼン資料の作成、及びプレゼン内容の作り込み(たしか09:00位からやってました)
結果には結びつかなかったのであれですが笑、
個人的に、これくらいの時間からプレゼン資料の作り込みと、発表内容の整理が出来たのは良かったです。
発表時間が5分と短かったので、その時間の間でデモと発表を終わらせる構成を作っていました。
そのおかげで、最後のプレゼンはデモから初めて、プレゼンの完了まで、時間通りに終わりましたし、
質問対応用のスライドも使えたりして、いろいろ準備が役に立ちました。
sideroad
・フリック用のアニメーションの作成
・結果表示のHTML,CSSの当て込み
・現在地からの距離の表示
・load用アニメーションの作成
・ロゴの反映
・バグ修正
4th
ここは細かい改善をしてました。
最後までコードpushしてdeployしまくった結果、終了10分前くらいまでアプリ動かなかったっていう笑
とりあえず最後に
振り返りとかもあるんですが、ここまでまとめるのに疲れてしまったので、
こちらは後ほど記事を追加したいと思います!
思い返しても楽しかったなー。体力的には疲れたし、畳の上で作業してたら腰が痛くて、、
(姿勢が悪いから
あとは、slackとか使うとある程度のログが残るので、見返すのに最適ですね。
SpringOnePlatform Conference Pre training レポート.
はじめに
昨年のSpringOne2GXに引き続き、
今年もラスベガスで開催されているSpringOnePlatformという
カンファレンスに参加させて頂いています。
今年は、カンファレンスに先立つこと2日間、
Pre-Conference Trainingという形のTraining Programに参加してきました。
本ブログでは、Trainingの所感について記載させて頂きます。
Pre-Conference Trainingについて
https://springoneplatform.io/training
今回のカンファレンスでは、先立つこと2日間をかけて、
spring関連の技術を学ぶことができるPre-trainingが開催されました。
Pre-Trainingでは、いくつかのコースが用意されています。
- 1.Developing Applications with Cloud Foundry
- 2.Building Big Data Solutions
- 3.Spring Cloud Services
- 4.Spring Boot Primer
- 5.Spring Cloud Data Flow
今回,3,4のどちらにするかかなり悩んだ末に4を受講しました。
4は今回用意されているコースの中では最も基礎的なコースになります。(たぶんですが
Spring Bootへの理解を深めることを目的として、
Spring Bootに関連する機能を一通りハンズオン形式で学ぶセッションとなっています。
Spring Boot Primerを選択した経緯
このセッションを選択した理由はいくつかあります。(ほぼ一つ)
- 1.自分自身見逃してそうな知識がありそうだった
- 2.社内のSpring関連の技術のチュートリアルの強化
- これが今回このコースを選択した一番の理由です
最近、部署の人員が急速に増えたり、多くのインターンを受け入れている状況の中で
・チュートリアルレベルの内容をメンターが個々に教えたりするコストを削減する
・実際のタスクに入ってもらうにあたっての最低限の知識を最短時間で学んで貰える
ことが必要だと感じ、
一通り自分の部署で使っている技術を学んでもらう為のチュートリアルのようなものを作成しました。
(公開できないのが残念ですが…)
少しずつ内容を加筆しているのですが、
- まだまだボリュームが足りていない、
- 実践的な演習・学習を行うには少し内容が乏しい
と感じていて、今回のTrainingを通じて、インスピレーション貰えたらな、、
とちょっと変わったモチベーション(?)を持って、このコースを選択することに決めました。
また、少々具体的な話になりますが、
部署・会社でラッパーしてるライブラリとか、親ライブラリとかWEB APIで提供されている機能がある訳ですが、
個人的には可能な限り、
何も分からずに使ってほしくない(わからなくても使えるのがいい所と言えばそうなんですが)
と考えています。
ですので、チュートリアルを通じて、ある程度生のライブラリを使ってもらって、
根底にある技術をある程度理解してもらえるような期待をしています。
その上で、現状我々がどのような経緯でラッパーしたのかとか、親ライブラリを作ったりしているのか分かって貰えれば、
その人はそういったところに改善の必要性を見出したりできると思うからです。
一方で、やっぱりそういうことを一人一人に教えられるような時間が割けなくなってきたということもあれば、
同じようなことを何度か新規に参画された方に共有する中で、
ある程度体系的にまとめられるようになった。ということもあります。
Spring Boot Primerについて+所感
有償セッションですので、具体的な内容には踏み込みすぎないことをご了承ください。
今回、事前に環境のセットアップの為のドキュメントが配布され、
必要なツールや環境構築の指示がありました。
JavaとかIDE入れておいてという建前的なものだけではなく、
このCLI入れておいてとかもあって面白かったです。
Pre-trainingの内容ですが、下記のサイトのTopicsに記載されている通り、
https://springoneplatform.io/training
- 1.Spring vs. Spring Boot
- 2.Spring Boot CLI
- 3.Web Development
- 4.Data Access
- 5.Testing
- 6.Security
- 7.Messaging
- 8.Deployment
- 9.Actuator
- 10.Microservices and Cloud
- 11.More Features
これらの内容について、幅広く実習していく感じです。
良かった点は、
- 口頭の説明だけ終わるものはなく、すべての講義についてハンズオン形式の実習がある点
- ハンズオンに加えて演習問題(Challenge)的なのもあるので、暇にならないw
- 上記の内容の3~10は繋がっていて、これらの機能を持ったアプリケーションが実装されるので、
実際のSpringBootアプリを1から実装するのと、比較的似ている流れで進められる
- 多分Slate使って作られたと思われる、専用の研修用サイトがあり(もちろんPCF(Pivotal Cloud Foundary)上で動いているようでしたw)、
付け焼き刃の研修内容では無いことの安心感笑
- いつでもpivotalのエンジニアに質問できる(研修と関係ないことも聞きたくなります)
- Springのコードを2日間書いた後にカンファレンスが始まるので、ウォーミングアップとしてもいい
考慮点は
- 10,11あたりはボリューム的な問題もあるが、本研修ではさすがに全てはカバーされない
- MivroserviceやSpringCloud周りを学びたい方は"Spring Cloud Services"のような研修項目を受けた方がいいですね。
※日本で受けられる研修に同じような項目は2016年8月4日現在ないようです。
https://pivotal.io/jp/academy
感想は
- Spring Boot CLI
これを使ってproject立ち上げる癖はなかったんですが、コマンドラインですらすら行けちゃうのはやっぱり楽しいですね。
本当にさくっとしたコードを試すときはこれがいいかも。。(特にgroovyの場合は簡単すぎる)
あとはチェックアウトしたbootのアプリを起動してみたいだけとかのときはこっちの方が楽ですね。
- Spring Securityまじ便利。使ってなかったの後悔。特にプライベート笑
- Slateをこういう使い方するの面白いな、、と思いました。新鮮。
もしも翌年以降のSpringOnePlatformでも同じような研修が行われるようでしたら、
検討してみてはいかがでしょうか。
僕はこのトレーニングのおかげで気持ち作って、カンファレンスに臨めました!
次回以降はカンファレンスの内容に関する記事になると思います。
プロローグ的な投稿になりますが、以上です!
shadow domを表示してinput type="date"のデザインをcssで変更する
個人的にやり方が分かるまで少し時間を要したのでメモ。
とあるアプリケーション作成中に、mockのhtmlを作成することになりました。
日付を入力する部分をhtml5のinput type="date"で作ったものの、デザインの変更方法が分からず、調べました。
下のqiitaの記事が比較的多くのオプションについて説明があり、助かりました。
ほんとは、-webkit以降の要素名のリスト・内容がまとまっている公式ドキュメントやリファレンスがあれば済む話だと思うのですが、
不覚ながら見つけれれません。。
で、こういった要素をchromeのdevtoolの"Show user agent shadow DOM"にチェックを入れるとdevtoolからこういった擬似要素を表示してくれるので、それを見ることでcss書く際に助けになります。
Show user agent shadow DOMの設定箇所
1.devtoolのsettingを開く
2.Elementsの箇所のある"Show user agent shadow DOM"にチェックを入れる
3.そうするとこんな感じで中身が見えます
SpringOne2015-KeynoteSession(初日)のまとめ
本日より、ワシントンD.Cにて開催されている、SpringOneカンファレンスに参加させて頂いています。
初日は、Keynoteのみの実施でしたが、聴きながら自分が感じたことを整理することも兼ねて、ブログにまとめさせて頂きます。
KeyNoteのテーマ
今年のSpringOneのテーマとして、 "Get Cloud Native" が掲げられていました。
皆さんは、Springのテーマとしてしっくりきましたか?
これを見て、「やばい、これがテーマだとするとうちは結構ビハインドしてる、、」と思いました汗
KeyNoteセッションの中でも、下記のような表現で、
"Cloud Nativeになることの恩恵"についてアピールがされていました。
- Transforming with Spring Cloud.
- Cloud native application(Pivotal Cloud Foundary) wave.
CloudとSpring、Springに関連するOSS(Netflixなど)を利用して
今までにない速度で効率的に開発を進められることが強調されていました。
Springとは何か
みなさんは、
"Spring" という言葉を聞いてどのようなイメージを思い浮かべますか?
"Springって何ですか?" という問いかけに対してどのような答えをお持ちでしょうか?
という答えをお持ちの方もいらっしゃると思います。
自分自身もSpring Bootを理解するまで、その回答でした。
その答え自体が完全に間違っているわけでは無いですが、
この数年のSpringの進歩に伴い、回答として適切では無くなってきています。
あと1,2年後には、その回答自体あまり出てこなくなるのでは、と想像しています。
上で出てきた、Spring Cloud・Pivotal Cloud Foundary共に、
既存のJavaのフレームワークの領域に留まる話しではありません。
Sessionの中で印象にのこっていた表現としてはSpringは今
- Pivotal Cloud foundry(cloud native)
- Spring cloud(coordination) + with(Netflix | OSS)
- Spring boot(configuration)
- Spring framework/io(application)
こういった役割があるといった表現です。
Spring frameworkがJavaのフレームワークとして"application"の実装において、様々な恩恵を授けてくれます。
Spring bootは、framworkの機能に加え、
auto configulation、embedded tomcat、依存性の自動解決など、
今まで開発者が時間を取られていた、"configulation"の部分をサポートしてくれます。
そして、Spring cloudとNetflixのoss(eurekaなど)を連携することで複数のサーバで動作する複数のアプリケーションの"coordination"を
強力にサポートしてくれます。
そして、Pivotal cloud fondary(PaaS)というクラウド基盤を土台にして様々なソフトウェア(例えばDB)と連携して、
より一層素早く、管理しやすいアプリケーションを作ることができます。
この全てをもって、Springです。
Springは単なるフレームワークではなく、
アプリケーションのためのプラットフォームになりつつある(それを目指している)
と改めてこの図をみて実感しました。
必ずしもSpringを使う上でその全てを使わないといけないわけではありません。
しかし、もしも今SpringをJavaのフレームワークの一つという目線で見ているのであれば、
上の図にある機能を公式サイトから是非一度見てみてください。
今までと違ったアプローチで、あなたのアプリケーションの改善の糸口が見つかるかもしれません。
Springの採択について
実際にSpringが採択されて、使われている会社の一例として、中国のAribabaが紹介されていました。
AribabaがJavaのフレームワークとしてSpringに統一することに決めたというようなスライドが出ていました(一瞬でしたのでうる覚えです
フレームワーク単体で動かしていると、無理に全部のフレームワークを統一する必要が無いと感じるかもしれませんが、
Spring Cloud Configなどの恩恵を受けるためには、フレームワークを統一していくことは大きな意味を持っています。
逆に1,2個のアプリ(Springを使っている)しかSpringを使ってい無い状態では、Cloud configの良さも半減してしまいます。
Spring Bootについて
Spring Bootのダウンロード数は順調に推移していて,この1年で5倍程度に推移したそうです。
自分の身の回りをみても、Spring bootが出てから、Springの話が出る頻度は明らかに増したと思います。
Spring4.3/5.0について
カンファレンスのテーマ自体はフレームワークに焦点をあてていませんが、
Keynoteの中ではもちろんSpring Frameworkの最新動向についても触れられていました。
直近で予定されている4.3へのアップデート概要、および翌年の2Qリリースが予定されているSpring5.0についても触れられていました。
ここで注目しておきたいのは、Spring5.0はJava8をBaselineとしている(Java8じゃないと使えないよ)ことです。
アプリケーションをJava8で動かすようにしておかないと、Spring5に移行できないですよ。と。
Java6->Java7への諸般の事情による停滞がありましたが、以降は2年ごとにJavaはメジャーバージョンアップしていきます。
常に安心して最新のJavaへアップデートできるような環境を用意し、最新のフレームワークを試せる環境を用意したいです。
また、今回のカンファレンスでいくつかセッションが取り上げられている、"Reactive Programming"についても触れられていました。
Spring5.0では明確にサポートしていくそうです。
自分自身Reactive Programmingをまだきちんと理解できていませんが、
アプリケーションのクラス構成が変わりそうですね。
Spring Framework 4.3
- refinements in the core deoendency injection model
- a richer set of convenience annotations(pre-composed)
Spring Framework 5.0 (Q2 2016)
Cloud native workshopの開催
pivotalがcloud native applicationのhands on sessionを開催して、
テーマであるget cloud nativeを促進してくれるみたいです。
日本でもやってくれるのかな、、、
http://pivotal.io/cloud-native-workshop
Junitのサポート
PivotalはJunitのサポートを公式に行うそうです。
(エンジニアとお金のサポート)
主にjunit5においてLamnda式に対応することを目的するそうですが、
詳細な情報は下記から確認できます。
また、どなたでも寄付出来るので、junitヘビーユーザーの皆さんは是非。
Live coding
他のカンファレンスと明確に違うのは、Live codingの時間が多く取られていることです。
Springの各機能にできる限りふれつつ、限られた時間で動くものを作り上げていきます。
おそらく、かなり準備してきたのだろうと思われます。
大きなセッションほどKeyNoteは退屈してしまう時間があったりしますが、
SpringOneではLiveCodingを行うことで、大半のエンジニアが非常に関心を持って、
話を聞いていました。
今までの海外カンファレンスの中で、一番身になったKeyNoteでした。
まとめ
KeynoteからLive Codingをしてアプリケーションを動かしたりしていることからも、
Springは簡単にすぐ動くアプリケーションを作ることができる。
ということをKeynoteから全力でアピールしているなと感じて、以降のセッションへのモチベーションが高まりました。
加えて刺激を受けたのが、比較的長いLiveCodingでミスなく(よく本番でライブコーディングしていると、意図していないExceptionが不意に起きちゃったりするのです)
完了していることです。
すぐに動くものを作れるのがSpringの強みで、自分もそこに魅力を感じてるんだなと再認識しました。
追記
2015/09/17 junitのパートを追加