みんなのウェディングさんと共同で勉強会を開催しました #fr_mw_lt

f:id:joe-re:20160410174359p:plain

connpass.com

大学の先輩の @azipon_zzz と一緒に、フロントエンドの知見交換を目的に勉強会を開催しました。

来場者、登壇者の皆さんありがとうございました!

全体的な進行

前半はLT大会で、後半はそれぞれの会社からの代表者に前に出てもらって、座談会形式で意見交換する会を設けた。

LT

Introduction to flux-util by @joe_re

speakerdeck.com

flux-utilsをざっくりと紹介。
Reduxとの共通点が多くあるので、その比較とか。

社内CSSフレームワークを作ったった by @azipon_zzz

speakerdeck.com

チーム開発において、cssの書き方を統一させ、似たような定義の氾濫を抑えていきたい。
そのための社内cssフレームワークを整備した話。
統一的な定義をしていくことで、デザイナーの工数の削減にもつながり、この画面とあの画面似た色使ってるけど微妙に違うような??みたいな事故が起きなくなる。

Vue.js New Team by @kazu_pon

speakerdeck.com

Vue.js の開発体制や、contributionのrule、これからのRoadMapのお話し。
また、大きなOSSにおける開発方法や、悩みなど。

ネイティブアプリでもFluxしたい by @yonekawa

speakerdeck.com

SwiftFlux の開発者による、iOSアプリケーションでのFluxアーキテクチャ構築のお話し。
iOSにおいてMVVMを構築した時のつらみ、Fluxにすることで解決できる問題など。

how can I make frontend engineer training @kawaguti

speakerdeck.com

フロントエンドの教育体制をいかにして構築するかというお話し。
大企業にお勤めの方で、含蓄に富んだお話しでした。

気の利いた入力コンポーネント by @ymrl

speakerdeck.com

ユーザが使っていて気持ちのよい入力コンポーネントにするために考えるべきこと。
また、Reactにおける具体的な実装の紹介。

チーム産、やさしさが香るフロントエンドコード〜jshintとscss-lintのソースをかけて〜 by @takuhito_hihara

www.slideshare.net

コード品質を保ち、かつ書き手の教育のためにlintを活用するお話し。
lintをかけるべきタイミングや、そのために活用しているpluginの紹介。

requireの循環参照 by @yo_waka

speakerdeck.com

CommonJSのrequireで循環参照していると、2度目以降のrequireで空のobjectが返ってきてしまうというつらい問題。
それに対しどう対処するかというお話し。

サービス改善のために エンジニアがすること、 しないこと by @kamonegi1977

speakerdeck.com

RailsにおいてABテストの構築する方法の紹介。
また、その作業においてサーバサイドエンジニアとフロントエンドエンジニアの作業分担、意識するべきこと。

座談会

@kuy さんが飛び入りで参加してくださって、より議論の幅を広げることができました! ありがとうございました 🙇

弊社からは @kambielden@ymrlが。
みんなのウェディングさんからは @azipon_zzz@kamonegi1977さんが前に出てくれました。
また、E2Eテストの話題が出た時には、弊社QAエンジニアの@tmasuharaに前に出てもらって語ってもらいました。(無茶振りすみませんでした!)

主には

  • 各社のjsフレームワークの変遷
  • cssの標準化への取り組み
  • APIの構築で気をつけるべきこと
  • Viewのテスト、E2Eのテストをどうしているか
  • チームで開発する上での情報共有の大切さ。活用しているツールなど

というお話しをしました。

加えてslackで騒いで拾ってもらう文化を作るの大事とか。
レガシーなイメージあるけど実はメール便利!とか。
webエンジニアならでは話も出て盛り上がった。

感謝

LT大会では @xga に司会をしてもらったり、
準備の時にも社内の有志メンバーが自発的に会場設営をはじめてくれてたり、
みんなのウェディングさんも受け付けしてくれたり(当日丸投げですみませんでした!)、
結構忙しくてテンパっていたのですごく助かった。

当日手伝ってくれた方々ありがとうございました! 🙇🙇🙇

ちゃんと開催できたのはみなさんのおかげです。

(実際のところ、自分は飲み物が来たのが開場10分前で焦ってたり、直前に会場説明資料作ってたり準備不足乙奴だったのでほとんど使いものになってませんでした。。すみません。。)

感想

割と雑な感じであんまり深く考えずに開催してみた感じだったけど、レベルも高いちゃんとした勉強会になってよかった!

こんな感じで、いろんな方と交流できる会をどんどん開催していきたい!

JSer.info 5周年記念イベントに行ってきた(LTもした) #jserinfo

jser.connpass.com

jser.info

すごく楽しかったです!5周年、おめでとうございます!

尊敬

僕も尊敬しています。

僕がWebの技術者になって、2年ほど経ってしまいました。
その前にいた業界と比べてWebの変化は早くて、最初のキャッチアップは苦労しましたが、js界隈に関してはJSer.infoがあるおかげで継続的なキャッチアップができています。

azuさんの情報収集力凄すぎる。

内容

どれも面白かった。(内容はJSer.infoでまとめられているので、ご参照ください。)

個人的な収穫としては、armorik83さんのAngular2の話と、 id:saneyuki_s さんのRxJSの話から得たものが大きかった。

speakerdeck.com

上半期中にAngular2とRxJSの知見を得よう。

さよならあいいい8

id:hasegawayosuke さんによるIE8のすごい機能についての発表。 最高に面白かった。

僕もLTさせてもらいました

www.slideshare.net

id:mizchi さんが Increments社でRailsでモダンJSな構成をどうやって実現して行っているか、というお話をしていた。

それを聞いて、弊社ではこうやってるよー、というのを話したくなったので飛び入りでLTさせてもらった。
(普段いんたーねっとの向こう側でよく見かける人たちがいっぱいいたので緊張しました。)

内容的には去年のAdvent Calendarで書いたのと一緒。

qiita.com

雑に「Reduxは使わずにflux/utilのReduceStore使うぞ!」みたいな事も書いてみた。

このあたりは口頭で説明したので、補足しておく。

Reduxは良いアーキテクチャを提供してくれる感はあるのだけど、構成がかなりロックインされてしまうのがつらいところだと思っていて、具体的にはStoreはReduxがシングルトンとして提供する(つまり自前では実装しない)オブジェクトになり、それを監視するContainerというコンポーネントを持つ単位を作らなければならない、というところが大きいところかなー、という感じ。

これはStoreの単位とそれ監視する場所が制限されてしまうという事で、既存の実装を徐々に置き換える上では足かせになりうると思っている。

flux/utilのReduceStoreはreduxからの影響を受けて実装されたものだけど、いい感じでReduxとの中間地点を提供してくれる。

先に述べたとおり、ReduxにおいてはStoreを実装しない。
その代りにreduce関数を定義し、更新前の値と更新後の値を関数内で処理すれば、Storeが勝手に更新されることになる。(このreduce関数の考え方が、Reduxの素晴らしいところだなー、と思います。)

ReduceStoreはRedux同様のreduce関数を提供するのだけど、この場合はStoreである自分自身の中にreduce関数を持つことになる。
本来のFluxから外れずに、Reduxのreduce関数をいただける感覚。すごく使いやすい。

Flux Utilsについては、以下の記事が詳しい。(これもazuさんだ)
はてなブックマーク検索を作りながらFlux Utilsについて学ぶ | Web Scratch

さー

Angular2とRxJSやるぞー

Gotanda.js#2 で request-specを利用していい感じにモックデータを作ってフロントエンド開発を楽にしたい! というLTをした

ご飯おいしくて最高だった。(GaiaX さんありがとうございました!)

資料

www.slideshare.net

お正月休みにautomockというGemを作った。 joe-re.hatenablog.com

その紹介と、これで何を実現したいのか、という内容を中心にLTさせてもらった。

(js勉強会なのにgemかよという感じですが、まぁ中のコードのほとんどはjsなので。。)

automockとは何なのか

RSpecで書かれたrequest-specの実行時に発生したレスポンスを抽出し、WebAPIのレスポンスのモックデータを生成する。
そしてRailsが返却するレスポンスを奪い、モックデータに差し替えるプロキシサーバを立ち上げる。

SPAを開発する場面においては、サーバサイドとクライアントサイドで扱うコンテキストはWebAPIのIFしか共通しない。
そこから先の世界についてはお互い知らない。
つまりクライアントサイドにとってはWebAPIによって得られる情報が全てであり、本当に雲の向こうにデータがあるかどうかは知りようがない。

automockはこの性質を利用する。
サーバサイドにデータの用意をせずとも、request-specで書いた状態を再現することができる。

autodoc というrubygemsにインスパイアされて作ったもので、 autodocはドキュメントを生成するんだけど、こちらはモックデータを生成する。

どんなメリットがあるのか

前述の通りSPAにおいてのクライアントサイドにとっては、サーバサイドに本当にデータがあるかどうかは動作する上で直接関係がない。
ゆえに開発をする上で、面倒なデータの用意などせずとも誰でも描画の確認や微調整は簡単にできるように、パターン別にレスポンスをモックしよう!

という発想は昔からあって、具体的には以下のような実装がある。

stubbyは昔僕も使っていたのだけど、モックデータを自前で用意しないといけないので、実装との乖離を起こさないようにするのが大変だった。

automockを使うと、モックデータは実装を元に自動で生成されることになるので、実装との乖離は発生しない。
こうしてメンテナンスの煩わしさから解放されるのと、実際に受け取ったresponseからモックデータを作成する(人の手を介さない)ので、信頼性を保てる点が利点だ。

作りたい世界

フロントエンドエンジニアとサーバサイドエンジニアがそれぞれを実装する場面においては、

サーバ先輩「request-spec、cucumberでシナリオ書いて実行できるようにしたお。」
クライアント後輩「うっすうっす。automockでレスポンスモックして、シナリオに基づいて画面作っていくっす。」

みたいな会話ができる。

specを書くことでautomockが機能し、開発効率が上がる。
開発効率が上がることでspecを書くモチベーションが高まる。
specを書くことでまた開発効率が上がる。

というループを実現したい。

Gotanda.js

Gotanda.js、すごく温かみのある会で楽しかった。
主催はまさかりより温かみというモットーで運営しているそうで、LTの敷居も低い。
お近くのJSerはみんな参加すればいいと思う。

また次回もよろしくお願いします!
といいつつ懇親会で開催者とお話しして、次回は弊社で開催させてもらえることになりそうなので、次回は運営側に回りそうです。(よろしくお願いします!)