FRONTEND CONFERENCE 2016 に行ってきた話しFRONTEND CONFERENCE 2016 に行ってきた話し

現地にちょっと遅れて着いて基調講演聞きはじめたら、しょっぱな「インターン先の新サービスが先日リリースしました」って STEERS のサイトサムネイルが表示されてたんだけど、

友人が関わってるプロダクトだったので、ちょっとビックリした(というか中継先の別室で一人ふきだしそうになった) 

自分もシャツつくってみたけど、T シャツのクラウドファンディングみたいなサイトなので、元々の知名度の無い個人プロダクトだと

身内イベントに絡めるか、広範囲に売る前提でプロモーションしていかないとな感じはするけど、スタートが気軽にできて楽しい。

ここからは いつものスタイルで、セッションを聞きながらとったメモをベースに感想を。(詳細な内容は資料読めばいいと思う。

会場のアンケートに3セッション分の感想欄があって調度いい感じだったので、興味を持った3セッションほど。

 

大型フロントエンド開発における TypeScript と DDD

(奥野 賢太郎さん - 資料 )

チャットワークの方なのでチャットワークの紹介から

導入企業92k...200地域... すさまじい...

 

前半はノンフレームワークな現行の WEB 版チャットワークを変えていく話し。

レガシーなコードを書き換える上で、フロントエンドチーム全員がES2015を習得済み という環境は羨ましくある。

AngularJS をプロトタイピングで採用していたので、そちらの導入もスムーズ。

どんどんチームで作業をする時の問題点の解決の話題に。

 

コメントは指針をもつ/意図を残す

→　そう書かざるを得なかった理由を明確にする

コーディングスタイルの統一は自動化(tslint)

 

・デザイナー連携

JS側にはスタイルを書かない

デザイナーがテンプレートをさわることがない

→ロジカルな設計にする必要があるので エンジニアがテンプレートを書く

(うちだとここまで切り分けできるテンプレートをエンジニア側が書けんな...

メンテしやすいよう BEM のライブラリを採用

axross/bemmer: BEM-like simple classname builder.

・デザイン仕様書の取り扱い

GitHub Wiki 全文検索できない　更新に気づけない

Markdown にして　プルリク必須

（デザイナが git 使いこなしてる環境うらやましい

 

・単体テスト

盲目的なカバレッジ100％はめざさない

→変更の度に修正が必要なテストは　メソッドのロジックが切り分けられていない

テスト内の負債を無視しない

 

・タスクランナー

gulp　属人化に気を付ける / 記述者を分散する

差分が見やすいように ファイルを分割、ワンライナーにせず改行をいれていく

 

・環境の構築

保守、ダミー、更新...だれが？

Ciが回る度に容量が許すかぎりデプロイして実行できる状態でのこしていく

非エンジニアも確認しやすい、バグも追いやすい

（おぉ...これやりたかったやつだ...

ストレスなくビルドできるように改善していく

・TypeScript と DDD(ドメイン駆動設計) が必要に

TypeScriptの型はチーム内で設計を共有するのに役立つ

大規模なシステムは覚えないといけない事が増えていく

→共通言語の定義

・型の恩恵

→一ヶ月後の自分は他人（あるある

コンパイラはドキュメントと違い嘘をつかない

＠param に型をかかない　　短いコメントをつけるくらいなら型で

型名厳格にすると IDE が活きる

テストで型を意識せずといいので　ロジックの振る舞いに集中できる

 

・ドメイン駆動設計

完璧な実践は難しい（重い

→活かすために触れる

ユビキタス言語の定義

人によるブレを無くす

 

・フレームワーク

どれがオワコンか？ という考えを捨てる

フレームワークの隆盛に影響されないアーキテクチャ

フレームワークを捨てられる状態を保つ

ロジックをapplicationドメインに

二槽式アーキテクチャ

フロントエンド内をフロントとバックエンドにわける

（ビューによったもの　　コアやアプリケーションによったもの

 

 

チーム全体がうまく回る　仕組み作り

管理がおいつかなくなる　→　機械に頼ろう

-----------

うちはそこまで大型な開発ではないけど

チームで作業する上で導入したい事がやま程ある

チーム規模小さくても、その辺のフットワークが重いのは自分の力不足だなぁ...

 

HTML5 の API 群を ただひたすらに触ってみた記録

(花谷 拓磨さん / http://webrunner.jp/ に後日関連する記事が上がるそうです )

タイトル通り HTML5 に存在する様々な API を使ってみた話し。

(色々触った中でも絞っての紹介)

冒頭は webstorage,indexedDB,webSQL あたりで、自分でも触った事がある範囲のお話。

webSQL は廃止されるので、それ以外の話しだが、まぁ個人開発の規模感だと webstorage が使いやすくていいよね。

・WebRTC

ブラウザ同士でリアルタイム通信をする為のAPI

(サーバークライアト間ではなくクライアントクライアント通信

IE/Safariは使えないが Edge は対応している

クライアント間通信の前にサーバーに相手を問合せないといけない為，シグナリングサーバーが必要になる

(ロビーサーバー的なやつね

実装範囲が低レイヤーなため スキルが求められる

シグナリングサーバーを作るのがそもそも大変

WebRTC をラッピングしたSkyWayでだいたいやってくれる(PC間だけじゃなく、スマホまでやってくれるらしい

その他類似事例(ちょうど3/3に GIGAZIN Eに記事が出た． ファイルの相互送信とか，ビデオ通話ができるサービスとか

自身でつくったもの(音声通話とかの実験用

PeerJS のラッピングを利用、PC/Android では動作できた(iOSはダメ

PeerJS 用の無料のクラウドサーバーが使える

peerJs に頼る形で 100行程度のコードで実現している

(接続の確立のネゴシエーション部分がよくわからなかった

ある程度ラッピングされてるので ハードルは下げれる

iOSが対応してないので，ファイル共有とかPC/PCをメインターゲットにできるところだと利用できるかも

 

・notifications

push api とは別物で，ブラウザからの通知を一元化して扱えるというもの

(tiarraMetroにいれてみるか

 

・実験的なAPIについて

Chrome/Firefox でしかうごかないものがおおい

iOS が使えないのがおおい ので iOS で使えるかどうかにひっぱられる

SSL 以外禁止になってどんどん使えなくなっていくので https で動かしましょう

localhost で動いても、本番環境に持っていくと通信制限の問題で動かなくなる事があるので気をつけて

 

日本は iPhone のシェアが高いので厳しい

まだパフォーマンス論争以前に機能が足りてないものがおおい

よいところとしては Web 技術ですべてかける

-----------

昔、Firefox に実装された加速度の API とか geocoding の API とかは、何かの勉強会で見て弄ってみた記憶があるが

HTML5 になってほんとに出来る事が多彩になっていて、それを WEB の技術で制御できるのが面白い。

個人的にはスライドの最初にリスト表示されていた D&D API とかも気になったし、

個人的に自作して使っているプロダクト(tiarraMetro)とかで気軽に導入できそうなものもあったので為になった。

push はちょっとハードル高そう。

 

Webサイトパフォーマンス管理の基礎知識

(竹洞 陽一郎さん 資料 126ページ！)

前半は統計学がいかに大事で、日本が統計学教育でどれだけ遅れてるかという話し。

今は高校の数I に入ってるみたいだし、最低限教育課程でやられてる範囲くらいは自習しとかないと 共通言語が扱えない みたいになって追いていかれるのかもしれないな。

・配信品質の話し「速さはなぜ大事か？」

我々が思う以上に一般の人は、サイトロードの遅さに対してシビア

最初に行って遅いサイトにはもうアクセスしない、っという人が半数近く居る。

「サイトパフォーマンスの大事さは分かるけど、他の優先事項が出来てない...」

というのは間違いで、サイトパフォーマンスを上げておかないと 優先で実装されたものを見てもらえない。

チャンスは一度きり。

こっから人の感覚の不確かさの話しとか。

・手法のはなし

ハイパフォーマンスwebサイト、9年たった今も通用するのか？

→通用しないよ

そもそも事象の背後にある原因が違うと解決策は変わる、ベストプラクティスとか辞めませんか？

(個人的にはハイパフォーマンス WEB に載ってる内容は使っているのだが

(結局そのまま当て嵌める何て出来ないし、要は参考にする指針程度のものだと思って使っていたので、柔軟性の問題よな...と思う

 

ベストプラクティスはそこら中にころがってるが，それは「健康法」みたいなもん

問題は特定の事象から発生しているもので，それは「健康法」で解決できるわけじゃない

ちゃんと医師の診察を受けろ。

 

・PPDACサイクル

(ニュージーランドでは小学校でやるらしい、何か基本情報かソフ開でやった気がする。

診察(実行可能データの計測)→手術

「健康法」をどうこうするのではなく，エンジニアは「医師」であるべき．

ベストプラクティスやめましょう

(まぁ参考にするくらい でいいよな っと思うし，エラー対応はまずログを見ろ！！！！みたいなのと同じかな

 

・計測の仕方

サーバーサイド / 合成 / リアルユーザー

リアルユーザ→エラー率が分からない(欠損値)

ランダムの欠損なのか，パターンの欠損なのか

また何の環境に依存しているかも分からないから統計的には扱えない。

 

・品質管理の原則

コントロール可能な範疇に中力

→なので合成計測でやっていこう

実験計画法 三原則

• 局所管理化 (オッカムの剃刀やな
• 反復 サンプル数を増やして 誤差をのぞく (1～2回じゃだめ！
• ランダム化 パターンに陥った計測は統計的に意味がない

表示速度，どれくらい確かか？

→サンプルをふやしていかないと 正しい情報がえられない

ラプラスの魔 → 全てを知る事はできないので，確率的に近づくしかない

母集団と標本 → 神しか知らない真の平均値(μ) 標本から得られる人間が知れる値x_

3回とか5回で何が分かるのか？ 統計学的に最低20～回はやろう

平均はバラつく、偏差をとる

6σ(製造業は100万個に1個のレベルで管理している

 

平均が全部4秒のグラフ

(品質がいいのは まとまってるやつ という話しだが、まとまってても4秒だと品質とは という気持ちになるな

=======この辺で時間切れで駆け足

パフォーマンス改善の手順

主要動線でのページ遷移計測

(これは合成計測の短所になってた部分でもありそうだが

分散の加法性

例外が発生しているものは、エラー値かパターン値か？ これはサンプルの期間を増やすしかない

chrome の開発ツールではそんなに取れない ツールの限界は知るべき

PageSpeed Insights では今上げてきたような問題が計測できない

google は自社の計測ツールではなく catchpoint のを使ってる

サンプルに出してるような接続ホスト数(40とか)だと、http2 にした方が ssl を接続数が大量になって重い

(最近 DeNA の H2O でリンザンプション使えばその限りじゃないよ みたいな記事を読んだのでタイムリー

-----------

ちょうど今仕事でやってるような範囲に近かった(こちらの程度はかなり低いのだけど)ので、勉強になった。

仕事にすぐ活かせるかは分からないけど、計測に関しては まだ手を付けはじめた感じで序の口なので、

今回学んだ事を活かしていきたい所。

 

 

あとがき

最近はあまり個人開発のモチベーションが無かった(...というか家にいると無限に FF14 やってるというのがあるが、

とりあえず出来る所から何かやろうかな っと思って、手元の環境で初めやすいのもフロントエンドのいい所だと思う。(成果を見やすい

長らく触ってないものの、自分自身で利用は続けてる tiarraMetro に notification API を取り込む、なんて小さな所からでいいので ちょっと触ってみたくなりました。

あとイベントのランチマップがいい感じだったので、「お昼ここに行くぞ！」っと決めて 友人と約束してて梅田に戻っちゃったのはちょっと勿体無かった。

そして40分開始だと思って悠長に買い物して戻ったら、午後が20分からで聞きたかった。 

・JS フレームワークと年月- ExtJS, AngularJS, React -

を聞き逃したので、他の方のレポート blog なんかが上がるのを楽しみにしておくかな...っといった所。