読者です 読者をやめる 読者になる 読者になる

ゆとり日記

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

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を愛してます。

スクロールバーの有無によって、ブラウザの画面が横にずれる話

今日の午前中、ずっとハマっていた内容をメモ。

今回対処する事象

ページ内容の高さが、ブラウザのウインドウの描画領域におさまらなくなった時 ページがスクロールバーの幅の分だけ横にズレる。

作ったもの

今回は下記のような画面を作った。

「説明文のタイトルがリストで並んでいて、リストをクリックすると詳細な説明文が表示される」 よくあるアコーディオンっぽい画面ですね。 ※上記のサンプルでは、青空文庫から適当に持ってきた文章を使っています

対処前の状態

サンプルの画面で説明文を表示していくと、ブラウザにスクロールバーが表示されたタイミングで 画面がカクッと左にズレる。これがどうしても気になったので、対応策を調べてみました。

行った対処

今回はCSSの修正だけで対応を行うことにしました。

html {
    overflow-y: scroll;
}

「スクロールバーの表示有無で画面がズレるなら、 最初からスクロールバーの領域を表示しておけばいいじゃないか」という話です。

動きが気になる方は、上のJSFiddleで動きを試してみてください。

所感

jQueryのバグを真っ先に疑ってしまったせいで、午前の3時間をこいつの調査に使ってしまったのはここだけの話。泣けます。

MeteorでAndroidアプリが動かせるのかどうか試す

本記事はMeteor Advent Calendar 2014の14日目の記事になります。

ネタの完成度がイマイチだったので、Qiitaでは無く自分のブログに書かせて頂くことにしました。

今回のお題は「MeteorでAndroidアプリが作れるのかどうか試します」ということで、早速始めます。

Meteorとは?

AdventCalendarの初日担当の方が詳しく説明して下さっているので、ここでは簡単な説明だけします。一言でいうと「リアルタイムなWebアプリケーションフレームワーク」ということです。

フレームワーク内部にデータベース(MongoDB)が内包されており、DBが更新されたタイミングでアプリ画面が逐一切り替わる動きを簡単に実装できたりします。 一々ブラウザの更新を手動で行わなくてもいいのは地味に便利です。

詳細が気になる方はMeteor公式のチュートリアルをやってみると良いと思います。 「おお・・!これ・・いいかも!」ってなること請け合いです。

AdventCalendarを書こうと思ったキッカケ

https://www.meteor.com/blog/2014/09/15/meteor-092-iOS-Android-mobile-apps-phonegap-cordova

「よし試そう!」って思いました。

アプリを作って、ローカル環境で動かす

※ここからの操作はMacLinuxで行うことを想定しています。 Windows環境はまだ公式でサポートが始まっていないようです・・。

1.ターミナルで以下のコマンドを実行する。

curl https://install.meteor.com | /bin/sh

2.インストールが完了したら、任意のディレクトリで以下のコマンドを実行。アプリのプロジェクトファイルが作成されます。

meteor create myapp

3.作成されたプロジェクトファイル内に移動し、以下のコマンドを実行。

meteor

ローカル環境でアプリが立ち上がっていることを確認してみましょう。http://localhost:3000/

f:id:rukiadia0401:20141214230532p:plain

こんな画面が立ち上がれば成功です。

アプリをサーバーにデプロイする

Meteorには公式から提供されているサーバー環境があり、そこに自分のアプリをデプロイ出来るようになっています。 (自前で用意する必要がなくて楽ですね)

1.プロジェクトディレクトリ直下で以下のコマンドを実行。

meteor deploy [任意のアプリ名].meteor.com

例:meteor deploy testapp.meteor.com

デプロイが完了したら、ブラウザで動きを確認してみましょう。 コンソールにデプロイ先のURLが表示されている筈です。

アプリを動かす

meteor公式のwikiとか見ながら、アプリが動かせるかやってみます。

1.AndroidSDKを入れる

※結構大きいサイズのファイルをDLすることになるので、テザリングでやるのは控えたほうが無難です。

meteor install-sdk android

2.Androidを動作対象に加える

ディレクトリ直下で以下のコマンドを実行

meteor add-platform android

Android SDKのライセンス条項が表示されるので、サッと目を通しておきつつ同意。

meteor list-platforms

と打って、androidが出ていればOKです。

3.エミュレータでアプリを動かす

(※実機で動かすことも可能ですが、今回はエミュレータで動作確認を行ってみます)

meteor run android

しばらく待つと・・

f:id:rukiadia0401:20141214233642p:plain

こんな感じでエミュレータ上で先程作ったアプリが動かせます。

あとがき

実機で動かすことも出来るんですが、ブログを書くタイミング実行したら何故かビルドに失敗してしまったため やむなくエミュレータで動かすことにしました。

あと、投稿がギリギリになってしまったのは非常に良くなかったなと反省してます。

Meteor Advent Calendar 2014 14日目の記事は以上です。 お疲れ様でした。