ゆとり日記

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

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部分の話もメモっているんですが、殴り書き過ぎたので、別のエントリーで纏めるかもしれません。

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

HTML5とか勉強会「Webパフォーマンス」でLTしてきた。

html5j.connpass.com

これに行ってきました。LTもしました。時間配分をミスって失敗しました、ごめんなさい/(^o^)\。

元々はLTをするつもりは全く無かったんですが、気づいた時には補欠が100人くらい居たので、勢いでLT枠に申し込みました。

話したこと

話した内容を箇条書きにすると、以下の通りです。

  • 社内に勉強をする習慣を根付かせたかったので、行動してみた。
  • その題材として「パフォーマンス」を選んだ。
  • でも、周りとの温度差が半端なくて何回か心が折れた。アプローチを変えて再挑戦した。
  • 組織には色々な人間がいて、皆が技術に燃えている訳ではないことに気づく。でも、何人かは熱い反応を返してくれる人がいて救われた。
  • 他人に変えてもらうなんて甘えなので、自分が行動しろ。まずは自分を変えろ。

資料は以下に挙げてます。時間内に終わらなかったので、補足文章をあちこちに加えてます。

https://speakerdeck.com/rukiadia/zu-zhi-nipahuomansugai-shan-wogen-fu-kaserutiao-zhan

反省点

5分で収まるようにする努力をもっとしないといけない。話す内容はもっと絞るべきだった。

機会を見つけて、再挑戦します(ヽ´ω`)。

そして現在

色々頑張ってみたけど、会社を辞めようかなと考えている。

理由は「キャリアパスが描けなくなった」とか「一緒に働きたかったメンバーがいなくなってしまった」とか色々あるけど、 会社の方針に従う気が起きないのが大きい。

次回は事業会社に行こうと思ってるので、良い事業会社があったら教えてくれると嬉しいです。

最近、仕事をしている時に心がけている事

ここ半年近く、意識している事がいくつかある。主だった内容を挙げると以下のようになる。

  • 作業をキリの悪い場面であえて止める
  • コーヒーを飲む量を減らす
  • こまめに席を立つ

それぞれの説明と、こんな事を意識しようと思い始めた経緯を書いていきます。

それぞれの説明

上で挙げた3つの行動の意味をちょこちょこ書いていきます。

作業をキリの悪い場面であえて止める

キリの悪い場面であえて作業を止めておくことで、昼食や会議から戻ってきた後に作業を再開しやすくするのが目的です。

キリの良い場面まで進めてしまうと、時間を置いた後にスムーズに作業に戻りづらくなってしまうんですよね。 昼食を食べつつ、途中まで進めていた実装を再考していると、より良い方法が思い浮かんだりもするので、習慣化して正解だなと個人的には考えています。

コーヒーを飲む量を減らす

コーヒーを飲みすぎると、頭が痛くなって効率がガタ落ちするので量を控えるようにした。ただそれだけの話です。 それだけの話なんですが、自分は珈琲大好き人間なので、量を減らすのはなかなかに大変でした・・。 一気に量を減らすのは現実的ではないので、週ごとに量を少しずつ削っていく計画を立てて地道に矯正しました。

今では、午後に1杯飲むくらいの量に落ち着いてます。 量を適度にしておけば、頭も冴えるし、トイレも近くならないので非常に良いです。

こまめに席を立つ

1時間半に1度くらいのペースで席を立つ。ただそれだけです。

集中するとモニターに顔を近づけて前のめりになってしまい、その姿勢を長時間続けて腰が痛くなる・・というお決まりのパターンから脱したかったというのが主な理由ですね。ヘルシープログラマーという本にも「長時間同じ姿勢でいるのはNG」的な記述があったので、それを真似しただけです。

厳密に時間を測っている訳ではなく、実装で詰まったりハマり始めたら席を立ち、水を片手に外に出てウロウロ散歩するというリズムを作っています。 そうしている内にパッと解決策が浮かぶ事もあるのでオススメです。 ※それでも解決策が浮かばなかったら、周りに相談しましょう!長時間悩んでるアピールをするのは時間の無駄です。

思い始めた経緯

「一丁前に他人に意見する前に、自分の不出来な点を直すのが筋かも」 そう思ったのがきっかけです。

去年の夏頃は、社内で荒れに荒れていた時期で上司に反発しまくっていました。

  • 新人を雑に教育して案件に放り込む体制(「Java歴3年です」みたいなノリ)が糞だった
  • 明確な方針や展望も示さずに「面白くしていこう!」とか宣う上の連中に嫌気がさした
  • 一緒に働きたかった人間が辞めてしまって半ばヤケになっていた

こんな感じの環境の中で、内部のイケてない部分を指摘して改善していこうとして裁量を持っている人達に噛みつきまくってた訳です。 荒れに荒れていた中で思ったのが「まずは自分の不出来な点を直すか」という点でした。 「自分のイケてない部分を棚に上げて文句を言うのは筋を通ってない」という、割と精神論に基づく考えではあります。

敵を少し増やしてしまったし、社長には嫌われたっぽいけど、自分の働き方を見直す機会になってよかったなと思っています。 ※チームで開発する時に注意する点とかも色々やっているのですが、長くなりすぎるのでここでは書きません。

やってみて

障害対応とか、周りへのフォローとかが無ければ、ほぼ残業せずに帰ってる。 作業も徹底的に前倒しでやっているし、懸念点は先に潰し切っているので、遅れも全然無し。割と良い流れが出来てる。 改善出来る点は多分あると思うので、地道に良くして行こうと思う。

「最近定時で帰ってるけど、忙しくないんですか?」 とか宣う周りの声はガン無視しとけばいいです。

Frontrend Conferenceに参加してきた話

Frontrend Conference - A conference for front-end developer(2015年2月21日開催)

フロントエンド界隈のコミュニティとして名を馳せていたFrontrend。 その活動の締めくくりとして''Frontrend Conference''というイベントが開催されると聞いて参加しました。様々なセッションやLTを聞いた中で、「これは良かったな〜」とか「印象に残ったな〜」みたいな感想を書きます。

Pragmatic Front-end Developer: From Artisan to Expert

個人的に印象の残ったセッションその一です。 内容としては、フロントエンドエンジニアに求められるスキルセットにフォーカスを置いたお話でした。主に印象に残っている点を列挙すると、

  • HTML/CSS/JSはメンテナンスしやすいとはいえない。
  • 専門的な知識がなくても書けてしまう手軽さによって生じる問題。
  • ソースをメンテナンスするためのツールの重要。
  • 方法論やツールは多く存在するが、そもそもの問題が人と人の間にある。
  • コーディングガイドラインツールは運用され続ける事に意味がある。
  • 人は「実際に見えるもの、動いているもの」に対しては意見が言いやすい。
  • Webは変化するもの。変化に対して寛容であるべき。
  • 作ったものに責任を持つ。
  • ツールにはツール毎に解決しなければいけない問題がある。
  • ツールは開発者の利便性を優先しがちである。
  • 知識を増やすための時間を定常的に設ける。

モダンなツールやら世界的にメジャーなコーディングルールを入れたところで、運用する側の人々に問題があれば、結局問題の解決には結びつかないというのは強く感じました。ルールを決める等の行動を起こす前に、チーム内で現状を認識して、向かう方向を統一しておくことが下準備として重要なのかなと思います。

チームの規模が大きくなればなるほど、品質を保つためのルールが必要になると思いますが、そのルールで運用をやっていくのが無理になっている現状を目の当たりにしてる自分として頭の痛い話でした。

Reactive Programming in JavaScript

「リアクティブプログラミングとは何ぞや?」というテーマのセッション。

「リアクティブ」がそもそも何なのかについてをネットで検索すると玉石混交状態で「結局どういうことなの??」みたいな感じになるので、The Reactive Manifestを読んでみましょう。
寝る前に読むと、気づいたら朝になったりしてることがあるので、日中の元気が残っている時に読むのがオススメです。

感想としては「雰囲気はわかったけど、これ自分で実際にやらないとすぐに頭から消えてくやつだ」って感じでした。少し前にMeteorというフレームワークを使ってみた経験があったので、理解度はそこそこ・・だった気がしてます。

セッションの内容はRxJSがメインだったのですが、発表者の方はBacon.jsが好きという事だったので、どっちを学んでみるか悩み中です。

Inline layout

CodeGridの高津戸さんのセッション。JS側の「ServiceWorker」のセッションも興味があったので悩んだのですが、CodeGridの著者の方の喋りを聞きたかったので、結局こちらを選択しました。

  • font-size
  • WindowsXPのサポート終了に伴って使う機会の増えた「display: inline-block
  • vertical-align
  • line-height

普段良く使っているCSSを掘り下げた話でした。 「リストの点と文章が綺麗に揃わない」「チェックボックスラジオボタンがブラウザによってズレる」 といった誰もが遭遇したことのある現象。僕も今までゴリ押しで直して、そもそもの原因を深堀りすることはしていませんでした。

目新しい話ではないかもしれませんが、こういう細かい話も絶対に大事だと思うので聞いて良かったです。

JavaScriptテストの疑問、お答えします。

個人的に一番印象に残ったセッション。

JavaScriptのテストの手法は知ってても、普段は手動でUIテストをやっている事が多く、テストコードを書いたことはあまり無かったのでモヤモヤしていました。Javaならユニットテストをする前提でコードを書くのは普通かもしれないけど、JSはうーん・・?」みたいな感じです。

しかし、テスト界隈を遠目で見てると

  • テストコードを書かない奴はギルティ
  • 自動化最高!!ヒャッホー!!
  • まだ手動テストで消耗してるの??

みたいな空気感が漂っている気がしていました。思い込みかもしれないですけど。
自動化する事自体を有難がっている風潮が少なからずあった気がして、正直あまり近寄りたくないと思っていたのは事実です。

ただ今回のセッションを聞いて、

  • 不安を解消するためにテストをしている。
  • 何のためのテストなのかを明確にして、そもそも必要がなければテストをやらないという選択肢もある。
  • 部分的に自動化をするだけでも価値はある(テスト自体は手動でやるが、準備は自動化する)

といった辺りの話を聞けたので、大分スッキリした感じはします。 自分自身、テストという行為を必要以上に高尚なものだと思い込んでいた面もあったので、 そういった反省点を見つけるきっかけにもなり、非常に有意義な話が聞けたと思っています。

まとめ

CSSは辛くて糞だと思ってるけど、僕はCSSを愛してます。