ゆとり日記

心にゆとりを持って生きたいプログラマーの雑記です。気が向いたら書きます。

Frontend de KANPAI! #01 に行ってきた感想

frokan.connpass.com

ブログ枠で参加してきたので、ブログを書く。

参加してみての感想

面白い話は多かったけど、次回開催があってもたぶん行かない。理由は後述。

KeynoteとLTについての感想

Keynote3本 + LT7本という構成で、合計で90分くらいでした。惹かれる内容もいくつかあったので、感想を述べます。

Keynote

あと3年フロントエンドでやる力

イタリアンレストラン、Webの受託会社で働いてきた人が30歳でDeNAに入り、普段どんな事を求められながら働いているのかという話を聞いた。「最初に求められたのがスタイルガイドの作成だった」という話を聞いて、実際にどういう運用をしているのかを深掘りして聞いてみたい気持ちになった。

FrontEnd:DDD - フロントエンド実装のコアドメイン

  • 早口 + 声が小さくて、話が聞き取れず。(マイク音声が篭っていたような気もする)
  • スライドの文字が小さくて全然読めなかった。

上記のような感じだったので、内容が全然頭に入ってこなかった。

keynoteの中では一番惹かれるタイトルだっただけに残念。スライドが公開されるなら、見返したい(ヽ´ω`)。

MobXではじめるReactiveアーキテクチャ

名前は知っていたものの、MobXの話をちゃんと聞くのは初めてだった。

「stateという単語が出てきたので、Reactに似てるといえば似てるのか・・?」という印象を受けた。「observableが理解できれば、すんなり入っていける」的な話だったので、自分で手を動かしてみようと思っている。

LT

この先生きのこるためのPostCSS実践入門

まあ、autoprefixer使うくらいで十分だと思う。

個人的に、今はCSS4とかの先取りをするモチベーションが無いので、PostCSSのオレオレ構成を作る気も無い・・。

フロントエンドで大切なことはAuditから学んだ

Chrome60で大幅に機能追加があった、DevToolsのAuditsパネルの話。

  • PWA化がどれくらい出来てるか
  • 画面が表示され始めるまで何秒くらいかかったか(WebPageTestの結果で見れるようなやつ)
  • アクセシビリティの計測
  • 改善のためのヒント

などが見られるようになる。Canaryの最新版が既に61とかなので、そっちで試せる筈。

「Webの品質」について考え直すきっかけになるとも思うので、気になる人は発表資料に目を通そう。

Webフロントエンドで大切なことは全てAuditsが教えてくれた

今日から始めるShader

WebGLとかthree.jsとかそっちよりの話。

AndroidJavaをやっていた時にOpenGLを勉強していた事もあって、個人的に凄く惹かれる内容。 しかし、5分で収めるにはディープだった感が否めなかった。別の機会があれば、もっと深い話も聞いてみたい。

https://www.shadertoy.com/

GLSL Sandbox Gallery

↑この辺で遊んで見ると楽しそう。

Hello,Fire!

Firebaseでチャットルームみたいのを作ってデモをやっていた。近くで内部の社員っぽい人達がワチャワチャ喋っていて、あまり発表者の声が聞けなかったのが残念。

FirebaseでSlackチックなものを雑に作るのは楽しいかもなーと思いながら、デモを眺めてました。

AndroidとWeb

「フロントエンド開発、iPhone基準で考え過ぎ問題」がテーマのLT。

  • MediaSession API
  • Payment Request API

↑の辺を紹介しつつ、PWA化の実装を今から始めていこう的な話が聞けて面白かった。

ただ、日本ではiOSのシェアが大きい事もあり、普段からPWA化の時間をどれくらい確保できるかが悩みのタネな気がする。

フロントエンドを1つの職能として見た場合

  • 専門家少なくない?
  • マインドもバラバラ(片手間にやっている人もいますし)
  • 目的と手段が間違っていることがある ⇒ 「jQueryやること自体がダサい」みたいな風潮

↑みたいな導入から始まったLT。社内でも「jQueryやりたくないです(流行りな事をやりたいだけ)」みたいな声はちょくちょく聞くので、共感出来る所はある。

  • 環境構築とかに時間をかけない。
  • 楽をすることに時間をかけすぎない。
  • 始めることに時間をかけない。

↑みたいな話にも触れていて、自分としても耳が痛い話があった。

これからは、チュートリアルを一通りやるだけで満足せずに何かしら形にしてアウトプットすることを心がけたいと思う。

あと16年活躍しようと思います

  • 興味を持った技術はひとまず触って、知識や技術のネットワークを広げる。
  • 結果を残す。
  • 仕事の事を人に伝える。
  • 健康は大事。

Web業界に20年近くいるベテランの方から、↑みたいな話を聞けた。

「知識や技術のネットワークを広げると、どんどん面白さを感じられるようになっていく。」って辺りには凄く共感。触っていく内に徐々に慣れてきて、やれる事が広がると楽しくなるもんだと自分でも思っている。

参加してて気になった箇所

KeynoteやLTは非常に楽しめたのだが、「LT + 懇親会」という構成は辛かったように思える。

「静かに発表者の話を聞きたい人」と「おしゃべりをして懇親したい人」が混在しつつ、「静かに発表者の話を聞きたい人」の方が割合多めだった気がするので、空気が少し重かった。

個人的に一番気になった(というか不快だった)のが、発表中に社員っぽい人達が雑談してる声が聞こえてきた事。発表を聞かないのは自由だと思うけど、それならそれで静かにしてて欲しいと思った。Keynoteの時間からそんな感じで、イベントに参加して嫌な気分になったのは久々だった。

「次回開催があってもたぶん行かない。」と思ったのはこの辺りが原因。お疲れ様でした。

【React】Goodpatch×TeamSpirit Meetupに参加してきた

teamspirit.connpass.com

↑のイベントに参加してきました。
(通常枠で申し込んだつもりでいたが、直前になって「ブログ執筆枠」で申し込んでいた事に気づくという阿呆ぶりを発揮。)

  • フロントエンドエンジニア3年目。
  • Redux + React + Node.jsのSPA開発を1年くらいやってる。
  • Reactに若干飽きてる

こんな人間から見た感想を書いていきます。

各LTの感想

※発表者の方の資料は、展開され次第追記していきます。

LT1 Reactのパフォーマンスを改善する必要が無かった話

チームスピリットさんが開発してるプロダクトがReactで開発されていて、それのパフォーマンス改善の話を聞いた。

結論はLTのタイトルにもある通りでそこまでパフォーマンスを改善する必要が無かった、とのこと。普段から設計やコードレビューに気をつけていた甲斐もあって、現状のパフォーマンスは悪くないし、改善を試しにやってみても0.01秒くらいしか変わらなかったらしい。

「Reactは最初から、ある程度のパフォーマンスを保てるようにできてる。」と言いつつも、何も考えずに開発を進めていると徐々にパフォーマンスが悪くなるので、以下のような事を開発の際に意識していたそう。

  • stateを浅く保って、再レンダリングの効率を良くする。
  • スプレッドオペレータでpropsを全部渡すのを避ける。(ついついやってしまいがち)
  • 更新の前後でstateが同一でも再レンダリングが走るので、shouldComponentUpdateやpureComponentの使用を検討する。
  • Perfでコンポーネントの描画速度を計測する。

パフォーマンスが悪くなってマジで困ったら、Perfで何とかするそうです。

感想

以前は自分も「スプレッドオペレータでpropsを全部渡す」をやってしまっていたので、同じ道を通った人がいて親近感を感じた。
やはり、必要なものだけを渡した方が無駄なprops比較も無くなるし、コードの見通しも良くなって良いですね。

自分が関わっているプロダクトではrecomposeのpure、shouldComponentUpdate、onlyUpdateForPropTypes辺りを使って、再レンダリングの負荷を出来るだけ軽減してたりします。

github.com

あと、スライドにちょいちょい挟まれる「いらすとや」の画像がジワジワ来て面白かった。

LT2 いまSPAを作るなら〜Prott2の技術選定のウラガワ〜

Goodpatchのよしこさんのお話。
Prottをリニューアルする動きがあるらしく、リニューアル時に使用する技術選定の話を聞いた。

  • React
  • Redux
  • AVA
  • Flow
  • styled-component
  • yarn

この辺りの技術を使用する予定らしい。「Goodpatch = Angular」みたいなイメージを持っていたので、Reactに舵を切るのは正直意外だった。

  • Web標準に即していて、剥離しすぎていない。
  • ある程度枯れていて、情報が多い。
  • エコシステムが多い。
  • ある程度枯れている。
  • Angularの使い勝手は好きだが、情報が少なく枯れていない。
  • Angularをちゃんと書ける人よりも、Reactを書ける人の方が多いので採用も楽。

といった感じの選定基準(+Angularを選定しなかった理由)らしい。

Reduxを入れた理由は「オレオレFWへの恐怖」だそう。Reduxのstate管理は良いと思いつつも、middlewareを使ったりせずに薄く使っていくつもりらしい。
middleware不要論についての参考リンク

Flowを入れた理由は、やはり型が欲しいから。TypeScriptは候補に上がったものの、言語そのものをスイッチするよりもJSに型チェックを入れる方がライトに感じて、Flowに決めたそう。(ただし、Flowはハマりどころが多いそう)

とはいえ、まだ始めたばかり。Reduxを脱却するかもしれないし、TypeScriptに移行するかもしれないとのこと。

感想

複雑な物を作ろうとすれば、何を使おうが大変になるだろうなーと思う。自分も1年間Reduxをやってきて、多くのメリットを感じつつもかなり苦労したので・・。

Flowは導入時に結構辛い思いをしたが、入れた方がコードの品質は高まっている感覚がある。

LT3 React沼 CSS Architecture

React沼CSSArchitect // Speaker Deck

試用期間中にReact、webpack、1つの巨大なSassファイルと戦った話を聞いた(個人的主観)。

「Reactでの画面のコンポーネント化は進んでいたが、CSSは1つのSassファイルに集約されていた。」 webpackによる長いコンパイル時間、CSSの見通しの悪さをどうにか解決したかったので、技術的にCSSを解決するアプローチを始めたらしい。

とはいえ、ツールは設計の解決までやってくれるわけではない。その辺りは別で考える必要があるので、BEMを使って設計アプローチを試みたそう。最終的には「単純で誰でも理解できる設計」に落ち着いたとのこと。

コンポーネントの粒度は、JSとCSSで1:1」の原則で運用。CSSのimportルールとかも資料に詳しく書いてあるので、読むと良いかもしれない。

React-Storybookを使って、コンポーネント単位でのサンドボックス環境を作っているらしい。作った理由は、webpackのビルドが遅かったから。今後はstorybookを使って、styleguideにしていく計画もあるそう。

感想

自分も昔はBEMでCSS設計をやっていたので、苦労は凄く理解できた。特に「クラス名考えるのが大変」って辺りの件は非常に共感。 (正直、もうBEMを使いたいとは思っていない)

今のプロジェクトではCSS in JSを使っているので、今後別の仕事をする際もそれで行きたいなーって気分でいる。

スタイルガイド作るのメンドイ。

パネルディスカッション

LT後はビールを飲みつつ、スピーカーの方々のパネルディスカッションを聞いてました。

色々議題は合ったんですが、その中で印象に残ったものを少しだけ触れます。

デザイナーとの協業について

会場で話を聞いた限り、コーディングまでやるデザイナーさんは稀らしい。
Goodpatchさんでも、フロントエンドとデザイナーの業務は明確に分かれていて、デザイナーさんがコーディングまでやることは基本的にないそう。

「コーディングまで綺麗にやってしまうデザイナーさんは、もはやデザイナーという枠を超えた存在なのでは・・」という気がしてる。

ReactとjQueryの共存

結論から言えば、共存は可能。とはいえ、「jQueryが必要になる場面は殆ど無いのでは?」という意見も出ていた。

自分もReactやり始めの頃は「jQueryの世界に帰りたいよぉ・・」とか言ってたので気持ちはすげー分かる。
今ではReactにすっかり慣れたので、「アニメーションさせるなら、jQueryの方が楽だな・・」というくらいの心境。

react-sketchappでスタイルガイドを作る

github.com

Airbnb凄い。

スタイルガイドを運用する上で起こりがちなのが、「実装とスタイルガイド間のズレ」。スタイルガイド側への反映が漏れていて、気づいたらスタイルガイドが役立たずになってるアレです。

これを技術で解決しましょう、ってことでreact-sketchappの出番が来ます。 要するに「作った画面をSketch上に描画する」という仕組み。こうすることで、実装とガイド間のズレを無くそうって話です。

今まで使ってなかったけど、ちょっと興味を惹かれたので試してみようと思っています。

まとめ

翌日早起きしないといけなかったので、懇親会に出れなかったのが心残り。
スピーカーの人が作ったという、ローストビーフが食べたかった・・(ヽ´ω`)。

あと、話に上がっていたAtomicDesignの本が面白そう。

bradfrost.com

第二回があれば、是非参加したいなと思います!

GWを振り返る

GW明けはどうにもテンションが上がらないので、GWを振り返る事で現実逃避していくスタイル。

GWにやったこと

  • ダークソウル3をとりあえずEDまで進めた。
  • 身内で開発合宿した。
  • Reduxの再入門をした。

ゲームやって、開発やって、後は酒を呑んでた。

あとは連休前に会社が買収されたので、それについて思いを馳せたりもしてた。

ダークソウル3

発売日に買ったのに途中で飽きて積んでたけど、なんとなくやり始めた。 EDを1つ見れたので、連休中の目標は達成出来た感じ。

トロフィーもコンプリートしたいけど、 ダークソウル3は3週くらいしないとトロフィーコンプが出来ないのでそこまでやる気が続くかわからん。

身内で開発合宿

開発合宿という文化に憧れがあったので、身内メンバーで千葉まで行ってきた。

  • 半年くらい前に転職した元同僚
  • 来月転職する同僚

という面子の男3人旅。

宿について

今回使った宿は↓。

土善旅館[弓道合宿・開発合宿]

宿に開発合宿プランというのもあったが、5人以上で予約しないと利用できないため、今回は普通に宿泊。15畳くらいの部屋の中央にテーブルを出してもらって、そこでずっとモクモクしてた。

  • 周辺に田んぼしかないので、開発に集中できる。
  • 歩いて数分の場所にコンビニがあるので、買い出しとか出来る。
  • 回線が早くて快適。
  • 24時間風呂に入れる。
  • 飯がなかなか旨い。

といった感じで、環境については文句無し。ひたすらAngularの勉強してただけなんですが、凄く集中できた。

Reduxの再入門

去年はずっとSPAの開発を業務でやっていて、そこで常日頃触れていたReduxについて復習したかったので再入門してた。

ひたすら公式ドキュメントを読み込むのもアリだと思ったが、動画を使った学習を試してみたかったのでUdemyで学習コンテンツを買って勉強してた。買った動画は↓。

https://www.udemy.com/react-redux/

内容も結構良かったし、セールで安売りしてる事も多いのでオススメ。

ハマったこと

学習コンテンツが少しだけ古いので、使用しているモジュールを現行の最新に上げようとするとハマる。

具体的にはreact−routerのバージョンが2系だったり、webpackが1系だったりするので その辺を雑に最新にすると、そもそもローカル環境の立ち上げに失敗したりして冒頭からハマる事になる。

ハマる経験をしたい人は、あえてやってみるのも一興かも。

GWが終わってからの予定

フロントエンドエンジニアの需要がありそうな会社を探して、会社訪問でもして行く予定。 会社を6月くらいに辞められるよう、地道に動いていきます。

以上。

Chrome Tech Talk Night #10に参加してきた。

朝起きたら書こうと思ったが、絶対書かない未来が見えたので寝る前にブログを書く。

イベントURLは↓。 Google Developers Japan: Chrome Tech Talk Night #10 を開催します

  • Progressive Web Appsの名付け親が来るのかー、面白そう。」
  • 「HTTP/2はめっちゃ気になるから聞こう。」
  • 「ServiceWorkerはプロダクトで使ってないからよく知らんけど、まあ・・とりあえず聞いとこう。」
  • 「通訳無しだけど、DevFest.asiaで二日間英語漬けになった時に比べればチョロいでしょ」

こんな感じの心境で参加したので、適当に感想書いてきます。

一部のセッションを除いて、↓で録画が見れるので気になる人は見てみると良いかもしれないです。

www.youtube.com

“HTTP/2” 😂

@DasSurma さんのセッション。

「HTTP/2化すれば、とりあえずページの表示早くなるよ」的な話からスタート。 その後は、HTTP/1.1だとなんでページの表示が遅くなるのかを聞いた。

主な理由は

  • 「レスポンスが遅いリクエストが一個あると、その後にリクエストにも影響が出る(ヘッドオブラインブロッキング)」
  • 「一度に張れるリクエストの数が少ない(6つとかそれくらい)」

HTTP/2だとTCPコネクション内でストリームの多重化が出来たり、張れるリクエストの数が多くなるから効率的ですね、という流れ。

(HTTP/1.1環境での高速化を図る場合は、画像とかSVGのSprite化をしたり、JSのbundle化とかして頑張るのが一般的なので 早くwebpack捨てたいなって思いながら聞いてた。)

その後は、

  • HPACKを使ったヘッダー圧縮の話
  • HTTP/2を使うならHTTPS化ほぼ必須なのでは
  • ローカルでHTTP/2サーバー作って開発する
  • HTTP2 PUSHの話

など、色々な話を聞いてた。その中でも、ローカルでHTTP2サーバー試せる話は良かった。 URLは GitHub - GoogleChrome/simplehttp2server: A simple HTTP/2 server for development。まだ試してないけど、dockerでも動かせるっぽい。

HTTP/2以降ガイド、みたいなページも共有されていた気がするけど、動画から掘り起こすのが面倒になったので省略。

Streams (Streamy streamy stream stream)

@jaffathecake さんのセッション。ServiceWorkerの仕様決めに関わっている方からのServiceWorkerの話。

async awaitを使ったコード説明からスタート。次にasync Iteratorsの話になって一気に分からなくなった/(^o^)\。

帰り道に調べたんですが、ES2017の仕様なんですねー。 GitHub - tc39/proposal-async-iteration: Asynchronous iteration for JavaScript

セッションのメインになっていたのは、Streamsという新たな仕様の話でした。 集中して聞いてたつもりなんですが、正直あまり理解できてないので明日復習します。

HTMLのパースが始まるまで、他のリソース(CSSとかJSとか画像とか)のリクエストが始まらなくて表示が遅れるからasync属性で並行してリクエストしておく。SPAは最初に読み込むJSがデカイから初回表示が遅い。SPAは複雑だから、streamを使ってHTMLを構成していく仕組みを作ろうとしている。という感じの話は聞いた気がするけど、脳内で上手く纏まってない。

Real World PWA Performance

@slightlylate さんのセッション。

動画も非公開だし、ここでは詳細を書かないことにするが、ページの表示速度についての話が主だった。 パフォーマンス計測をWebPagetestで行って、色々デモをやっていた感じ。

スペックがそんなに高くなくて、回線状況も良くない端末でページを開いた時に firstviewまで何秒かかるかとかを可視化出来るので、使った事がない人は触ってみると良いかもしれないです。

懇親会

夕飯も食べずにセッションに集中して腹ペコだったので、ピザを遠慮なくムシャムシャしてました。

話しかけた人がたまたま「Angular使ってる人」「ScalaとかJavaでサーバ側やってる人」「Railsやってる人」という面々で、それぞれ違う目線の話が聞けて楽しかった。自分もReactの話とかすれば良かったし、名刺交換とかすれば良かったなとちょっと後悔している。

反省

英語を話せないと、普段出会えない人と話すチャンスすら掴めないと強く感じたので、本気でなんとかしようと思った。

ある程度は聞けて書けるとはいえ、やっぱり日常会話レベルで話せないと気軽に質問とかするのは辛い。

PassiveEventsListenerを試験的に入れた

EventListenerOptions/explainer.md at gh-pages · WICG/EventListenerOptions · GitHub

今個人的に熱いと思っている↑を、関わっているプロジェクトに試験的に入れることにしてみた。 入れることにした理由としては、

  • スクロール時に発生するイベントが多い画面があるので、少しでも軽くしていきたいと考えた。
  • ブラウザ対応が割と進んできた。(IE11から目を逸しながら)

この辺りが大きい。ブラウザの対応状況については↓を見ると良い。 http://caniuse.com/#search=passive

Safariも10以降であれば対応しているので、iOSユーザが多めなサービスであれば、入れるメリットが大きいと思う。

polyfillを書く

少し調べたらpolyfillはちょこちょこ見つかったのだが、最小限の実装で済ませたかったので自前で簡単に書いた。 解説とサンプル説明をQiitaにも上げているので、興味のある人はご覧ください。

間違った説明とかしてたら指摘頂けると助かります。

入れた感触

「目に見えて軽くなった!」という程ではないが、スクロールの詰まりは多少改善されたように思える。 特にモバイルで、「スクロールに追従する要素」「lazyload」のコンボをキメている画面については大分マシになった印象を受けた。

更なる改善

スクロールに追従する要素については改善し切れていないので、position:stickyの先行導入を検討中。

stickyの導入でスクロール時の負荷がより減ると良いのだが、どうなるかはまだよく分からない。

Inside Frontend #1に参加してきた

今日はInside Frontend #1に参加してきた。

一般枠の抽選に当たる気がせず「ブログ絶対書く人枠」で参加したので、後回しになる前にちゃんとブログを書いておく。※受付の時、スタッフの方に「ブログ絶対書くマンですね!」と言われて変な声が出た

  • イベント自体の感想
  • 印象に残ったセッションの話

が主です。途中休憩してて、聞けなかったAMA(Ask Me Anything)とかもあったので満遍なく書いたりはしません。

イベント自体の感想

普通に最高でした!!

セッションの内容も良かったのだが、AMAのブースが特に楽しめた。 「GitHubのIssueに登壇者の方への質問を事前に挙げておき、それに順番に答えてくれる」という流れで話が進むのだが、参加者側にとってはイベントに参加している感覚が増すので、非常に新鮮だった。登壇者の方との距離感が近かったのも、良かった。

issueはここから見れる。今回は質問を投稿出来なかったので、次回があればその時は積極的に質問を投げてみようと考えている。

イベント本編とは話が逸れるが、トイレの設備が充実していたのが地味にありがたかった。尿意を堪えながら個室前に並ぶ・・といった苦行をせずに済んだのは、精神衛生上良かった。

印象に残ったセッションの話

今回は以下のセッションを聴いた。

セッション

  • 「Web over ServiceWorker」
  • 「Web フロントエンドにおけるコンポーネント化のアプローチ」
  • アメブロ2016: 実録、アメブロフロントリニューアル275日」
  • 「データビジュアライゼーションの作り方」

ServiceWorkerの話が個人的にツボだったので、そこ多めの感想文になります。

Web over ServiceWorker

普段からブログを参考にさせて頂いてるJxckさんの話をきくことに。資料はこちら

Webがモバイルネイティブに対して、どういうアプローチをしていけるかという話から始まり、ServiceWorkerがどういった役割を果たしていくのかという流れの内容だった。箇条書きで纏めたメモを以下に載せる。

Web VS moblie

  • スマホを見ている時間が圧倒的に長いが、いつもブラウザを見ているわけではない。
  • アプローチするために出来ることが、まだ足りない。アプリとWebは、元々用途が違うので当然といえば当然の話。
    • ネイティブに勝てない部分はあるし、何でもかんでも出来るわけでもないし。
    • 動作の基本がJSなので、演算能力も低い。
    • メモリやファイルに好き勝手アクセスできるわけではない。セキュリティとかあるし。
  • Webはネットワークにつながってナンボ。
  • APIを安全にSandbox化していけば、もっと出来ることが増えるんじゃないか?
    • ローレベルなAPIを、ブラウザから叩けるようにしようという流れが2015年くらいから出来てきた。
  • 現在では、色々な事が出来るようになってきて、アーキテクチャの整備も進んできた。 (「色んな事」は資料に載っていました)

  • ServiceWorker初期のモチベーションは、mozaic.fmを聴こう。 mozaic.fm かな?

  • OFFLINE

  • ServiceWorkerはオフライン対応をするための手段、という雰囲気が初めはあった。
  • 今では、Webが出来ていない部分を埋める物になりつつあるらしい。

  • cacheAPI

    • cacheAPI経由で取得しておいたキャッシュがあれば、ネットワークにリクエストを飛ばさずにコンテンツを返す。
    • キャッシュの設計はなかなか難しいらしい。
  • PUSH通知。ブラウザの右上に出てくるアレ

    • AMAのブースで以下のような補足があった。 「FacebookやSlackのように、最初は通知に関する設定をする画面に飛ばすべき。通知の前段階になる説明がないと、うっとおしがられてブロックされてしまう。通知機能に対してのイメージが悪くなる。」
    • push通知を一度ユーザーが拒否したら、ユーザーに解除してもらわない限り、ドメイン全体のpush通知が死ぬ
  • TaskManager

    • タスクの同期を、オフライン⇒オンラインになったタイミングで同期してくれる。(onSync)
    • 空気を呼んでくれるイベントだが、「闇雲にsyncする」のは良くない。
  • proxyによるリクエストの効率化を図り、SPAと同じようなユーザー体験を実現

  • proxyのライフサイクル
  • Androidのadd home screen(ホーム画面に追加) でのapk化
  • Navigation Preload

リクエストを投げた後に、ServiceWorkerの起動を待つ機能。レスポンスが遅くなるのを割けるための施策。 ⇒Facebookが追加した機能。


とりあえず、ServiceWorkerの中級者向けのチュートリアルをやって感覚を掴もうと思う。

Web フロントエンドにおけるコンポーネント化のアプローチ

資料はこちら。資料に説明があるので、僕が感じた感想だけ書きます。

個人的にはスタイルガイドを作る意味はあまり無いんじゃないかと最近思ってます。スタイルガイドを作って保守するコストはやはり高いので、それに見合う価値や、解決したい課題がなければやらなくていいのではないかと。

今関わっている事業ではデザイナーさんは画面のデザインに集中、フロント開発者側は設計と運用を担保する感じになっている。CSS in JSを使っているから上手くやれている気もするが。

アメブロ2016: 実録、アメブロフロントリニューアル275日

資料はこちら

React + Redux + Node.jsという、今の自分と近しい感じのアーキテクチャだった事もあり、開発ブログは以前から読ませてもらっていた。パフォーマンス改善のための計測や改善を地道に続けていく姿勢には、頭が下がる。

プロダクトリニューアルをする場合の教科書的な立ち位置にしても良いんじゃないだろうかと、個人的には思う。

データビジュアライゼーションの作り方

資料はこちら

日経Visual Dataの開発者の方のお話でした。D3.jsの本質とか、バッドノウハウ等を色々聞けたので、メモを載せておく。

D3.jsについて

  • Data-Driven Document
  • チャートライブラリではない。
  • 学習コストが高いと言われているが、そもそもの誤解がある。

D3の公式ライブラリのサンプルは色々凝りすぎているので忘れてしまおう。あんな凄いものをサクッと作れるわけがない。

実装の際にはSVGを使うことが多い。

D3が肩代わりしてくれること

データを元にエレメントを操作する機能と、トランジションや計算処理など最低限の機能のみを提供してくれる。データが膨大になっても、問題無く使える。

しかし、ブラウザ間の動作差異を埋めてくれる機能は元々ないので、開発者側が意識する必要がある。

z-index

svgにはz-indexが無いので、重なり順の制御が出来ない。

折り返さない問題

HTMLと違い、SVGには折り返しという機能が無い。 ⇒レスポンシブに対応するためには、リサイズの度に再計算が必要になる。

  • textはtspanで括る。
  • scale()やviewBoxを上手く使う。 ↑で対応が可能な場合もある。

SVGPNGに変換する

「画像としてDLしたい」要望が結構あったので実装する必要があった。 「SVGをラスタライズ」など、方法はいくつか考えられるが、何でもフロントエンド側でやろうとしない方が良い。

まとめ

データビジュアライゼーションは、地味で泥臭い作業が非常に重要になってくる。


D3は数学的な処理を肩代わりしてくれるだけで、ロジック部分はちゃんと考えないといけないし、マルチブラウザ対応も自力で頑張らないといけないしで大変そうな印象を受けた。

業務で必要な場面が今のところ無いから、触るのはまだ先になりそうな予感。

反省点

やっぱり、AMAに質問を書けば良かったなーと反省。せっかくの機会だったので、もっと挑戦的になるべきだった。 AMA部分の話もメモっているんですが、殴り書き過ぎたので、別のエントリーで纏めるかもしれません。

スタッフの方々、本当にお疲れ様でした。ありがとうございました。