hrfmmymt

[hrfmmymt]

二歳の肖像

二日前になるが、帰宅した際妻から、保育園で娘による他の園児への悪ふざけに対して、先生から娘へ強めの怒られが発生したようだという話を聞いた。要するに、娘が保育園でお友達に悪さをして、しっかりと怒られた。

それから妻と娘は二人で風呂に入り、娘の入浴が終わったら自分が娘の濡れた身体を拭き、パジャマを着せて、布団で絵本を読んだ後、寝かしつけるときに少し話した。

「今日は保育園で何したの？」

他愛もない会話のつもりで聞いてみた。いつもしている質問だし、いつもは「パズル〜」とか「おままごと〜」とか、その日あった出来事を簡潔に答えるものだったのだが、 今日返ってきたものは沈黙だけだった。

娘「...」

私「...保育園楽しかった？」 娘「...」 私「保育園楽しくなかった？」 娘「楽しくなかった」 私「どうして？」 娘「...」 私「先生に怒られたから？」 娘「怒られたから」 私「お友達にごめんねした？」 娘「...」 私「これからはお友達や先生やパパとママが嫌だよって言ったら、もうしたらダメだよ。もししちゃったら ごめんね しようね」 娘「うん」 私「したらまた保育園楽しくなるよ」

それから程なくして、風呂から上がった妻がやって来て

娘「あ、ママおかえり〜」

そして就寝した。 会話の間の沈黙からは怒られて凹んでいる、普段とは違う感情が察せられた。そうして親父は娘の成長を少し実感したのだった。二歳だもんね。

[hrfmmymt]

クリスマス、世界中の子どもたちが、今日のこの日くらいは皆幸せに過ごせますようにという願いの表れなんじゃないかと思うようになった。

[hrfmmymt]

意匠のところに Sketch とか Photoshop とか書くのを忘れました。

[hrfmmymt]

Static AMP Site Generatorc - 続き

進捗

オフライン表示ができてなかったのでやった。

なぜできてなかったか

amp-install-serviceworker を使っているのだけれど、data-iframe-src で参照する HTML を express で .static() 指定してるディレクトリ以下に置いておいたら ServiceWorker の scope が /static/ のディレクトリ限定になってて fetch できてなかった、、ことにしばらく気付いてなかった。 結構ハマってて、それは '/' は pre-cache できてたからっていうのもあって本当に「ウーンウーン」してた。

やったこと

const app = express() app.use(express.static(staticDir)) app.use(express.static(rootDir)) // 今回追加

みたいにしておいて、install-service-worker.html、キャッシュ定義の JS ( service-worker.js ) と関連ライブラリ ( Workbox 使用 ) をプロジェクト・ルートに置いた。いい解決方法ではない気はする。

というかまあザックリ言うと経験不足かなと思って、作業記録として書いておこうと思った次第。

[hrfmmymt]

Static AMP Site Generator

つまり

静的 AMP サイト・ジェネレーター。

Node.js で marked.js をパースした HTML を mustache のテンプレートに埋め込むっていう、たぶんよくあるパターンで、 テンプレート部分を amp ⚡ してみたらできてしまった。

リポジトリは hrfmmymt/iiyatsu（良いやつ） 本当になんとなくで始めてしまったので、リポジトリ名がこれでもかってくらい適当なのである。

お気持ち

とにかく tumblr で日本語書くのがちょっとダルくて。。Hugo / Hexo あたり試してみたいなと思いつつ。。（Jekyll は使ったことあって、なんか mac の OS アップデートのたびに壊れて嫌になった）

気が向いたらこれで記事書いていくかもしれない

その上で気が向いたら機能追加するかもしれない（タグとかカテゴリとか）

Service Worker 適当にやりかけてるのでこれはどうにかするか

あと本当に適当にデプロイできてしまう Now すげえな。

やってる間に日経電子版のやつ見てて、H2 で静的リソースプッシュするなら AMP いらないのかーって素朴に思った。

[hrfmmymt]

はじめての PWA をはじめている

何の話か

最近 PWA (あと AMP も) やっていってるっていう話です。なんとなく時系列その他で順序立てて一つのエピソードとして成り立たせ難かった。

ハッカソンed

まずは縁あって参加した AMP / PWA ハッカソンの話。 Google 社で二日に渡って行われたそれに行ってきました。 1日目はリリースすることを目標に、業務案件への AMP / PWA 実装、2日目は知見の共有 ( LT 大会 ) という内容でした。 実装に関しては、自分はとりあえず放り込まれた形だったので目標がなく、なんかプッシュ通知でもやってみるかという気持ちで作業してました。

LT 資料を一応公開してます -> 2017/11/01 - AMP/PWA ハッカソン

プッシュ通知あかんかった。。

自分が得た学びとしては、

Add to HomeScreen するのに、オフラインで動かないとダメよって怒られる

生 SW 書いてた時、れれー？ってなってた。つまり要 fetch イベントなのかな（未確認）

まあ Workbox で解決

Webpack - Workbox のディレクトリパス指定がなんかムズかった

これは Webpack の文脈だろうか。苦手。

静的リソースの更新を常に気にかける必要がある

画像の差し替えとかで workbox generate:sw するのなんか忘れる自信満々である。継続的にプログレスするために、いい感じのビルド・リリースフローを再構成する必要がある。*1

やっぱ優勝争いした某社 ( AMP & Firebase )と某社 ( Payment Request API ) が強かったですね。

自サイトで PWAMP やってみた

続いては ARCHIVE - AMP対応してみた の記事その後の話。

対象

https://hrfmmymt.github.io/

こっちは npm の Workbox 使用。で、キャッシュ、Add to homescreen したら既に Chrome の Lighthouse で Progressive Web App の項目が 100 になってたのでこれはもう PWAMP と言って差し支えないのでは。前からやってたパフォーマンスチューニングと AMP が効いたのでしょう。

こちらに関しては以上でしょうか。

あとがき

Payment Request 練習中、ちょっと逸れるけど Firebase 練習中。 hrfmmymt/skillsheet を AMP 化しようかなとか。Next.js で AMP するの積んでみたりしてるけど難航しそう。。

検証用 Android 端末欲しい。いや、本当に欲しいのは Pixel2 。。

注釈

*1 自分じゃないけど、ギョームで実験的に入れていたという生 SW というか、 はじめてのプログレッシブ ウェブアプリ のコードを丸っとコピペしてデプロイしてあったことが原因でのボヤ騒ぎがあって、もうなんか色々と "学び" を感じた。（コードはおろか日本語も読まないのかよー…）

[hrfmmymt]

datepicker を自作している

まえがき

自分が今携わっている弊サは常にデザインのアップデートを繰り返していて、デートピッカーも同じく見直されることになった。 という普通の流れがあり、種々のライブラリを見て回った結果、どうしても痒いところに手が届かなくて仕方なくデートピッカーを自作することにした。

作るにあたって

まず作るにあたって、二段階の筋を用意した。まず一つがカレンダーの開閉・生成、二つ目が日付の選択・フォーム要素へのセット。分け方としては前者がどんなサービスでも同じだろうと思われる要件、後者が若干異なるのでは、という考え方でいる。 そんなこんなでリポジトリも仮で二つ作ってしまった。

https://github.com/hrfmmymt/plainpicker https://github.com/hrfmmymt/plainpicker-

とりあえずなんとなく plainpicker という単語をライブラリ名にしている。

要件としてはライブラリ非依存。 Pikaday を大いに参考にしつつ、ES2015~ で書いて最近は Rollup でビルドしてる。モジュール化とかできてなくて、1200行の普通のプラグインになってる。https://github.com/hrfmmymt/plainpicker-/blob/master/src/js/app.js

というかここまで書いておいてなんだが、弊サへのマージはおろかまだちょっと未完成。。でも書く機運が熟しているのを感じるので書いて投稿しちゃった。

[hrfmmymt]

react-redux で SSR の練習した

（4~5か月前ですけど）

SSR (サーバー・サイド・レンダリング) が取り沙汰される、つまり旧来の普通の Web サイト (非 SPA ) の要件を満たしつつ、そこに SPA 的な UI を持ち込むって要求があるというのは自分としてはまあ必然かもと思っていたりして。というか、Pitchfork なんかを見てて、まあこういう風にやりたいよなーそうだよなーと考えているのはあって、かつて練習していたことがありましてですね。（最近まで忘れていたのです）

https://github.com/hrfmmymt/react-redux-ssr http://glacial-mesa-58415.herokuapp.com/

heroku にデプロイしてるのはここの辺り↓↓を確認しておきたくて https://developers.google.com/speed/pagespeed/insights/?hl=ja&url=https%3A%2F%2Fglacial-mesa-58415.herokuapp.com%2F

https://gtmetrix.com/reports/glacial-mesa-58415.herokuapp.com/IwcnbYZy

SSR をしたということに加えて、一応それなりに"緑"にするためのテクニックは抑えていて、その関連作業も行なっていて、というのを踏まえての結果ではあります。もちろんこういった技術は SPA / 普通の Web サイトいずれかに 限った話ではありません。 というところで、個人的な結論としては「できるんならやったほうがいいでしょう。ただし、 Web サイトのパフォーマンス向上の取り組みは SSR 以外にもあるし、それを効率よく継続していくための最適解は組織ごと、プロジェクトごとに都度求めていくべきでしょう」で。

参考

React-Reduxを使ったWebアプリをサーバサイドレンダリング(SSR)するには、こういう風にしたらいいんじゃないか的なお話 ~ 適当な感じでプログラミングとか！

[hrfmmymt]

AMP対応してみた

対象

http://hrfmmymt.github.io/

参照とやったこと

初めての AMP ページを作成する – AMP

の width 属性値は反映されないことに注意 - Qiita

AMP ページにアナリティクスを追加する  |  AMP ページ向けアナリティクス |  Google Developers

上記の情報でだいたい間に合った。 2番目の記事は若干ハマって役立った。今までの PC から SP 向けにレスポンシブ対応する流れを逆転させることになって、「うおおこれがモバイルファーストかー」と思った。

以下やったことリスト

外部 CSS 参照の <style amp-custom> 化

<img> から <amp-img>

ブログ最新記事のタイトル・リンクの XHR による API 取得・表示を廃止。静的に書き換えた。

最後のだけは対応による完全なるデメリットを感じる。。この記事公開したら <li> 増やしてコミットしてデプロイしなきゃいけないんだぜ。。

[hrfmmymt]

React で WAI-ARIA 対応の modal dialog (window) を実装した

まずはReact も WAI-ARIA も手探りな件ご容赦ください。 （それぞれ双方からのツッコミが欲しいです。React に関しては、業務でやってないから XO くらいしか話しかけてくれるフレンズがいない。。）

Demo

See the Pen React a11y modal dialog by hrfmmymt (@hrfmmymt) on CodePen.

Codepen

React

ModalWindow をなんとなくカスタマイズして使い回す想定です。 なんですけど、overlay は任意で要調整。

（キーバインドの書き方これでいいのかな…ダメなんじゃね？ なんか React でも Angular でもそうなんだけど、普通に document.getElementBy~みたいなコード書くと敗北感あるのなんなん。。）

といったことを、以前作ってあった開発環境で XO に怒られながら考えていました 。

WAI-ARIA

前述したキーバインド、esc でダイアログ閉じます。 開いたときダイアログにフォーカスか、中の見出しにフォーカスのどっちがいいか確信が持てず。（あえて見出しに）

感想🤗

それにしても、「状態」を一つ管理しておくだけで "aria-*" の属性操作、キーバインド実装、toggleClass までが簡単にできるのかなり満足感ありますね。すごい今更な React の感想なんですが。

[hrfmmymt]

柿食えば React - Babel - Webpack

hrfmmymt/react-babel-webpack

まえがき

なんか2016年末からいわゆる Boilerplate っぽいものを作るのにハマり出してて、

hrfmmymt/postcss-starter hrfmmymt/es2015-starter hrfmmymt/frontend-starter-2016

その流れで React の素振り環境作ってみようと思って、気付いてみたらちょっと重たくなってた。 ただ、ただの React の最小構成とかはいくらでも乱立してるし、一瞬で拵えることはできると思うんだけど、それで終えてしまうのは個人的には現実的ではないというか。実際何らかを作って公開するなら CSS とか必要だしーとか、ビルドは今なら Webpack なのかなーとか、いろいろとリアリティありげな仮定タスクを積んでみたらこうなったというか。 周りを見渡してみる限り、やってないことといえば 型システムとか flux とかになるんじゃないかと。

とりま以下、やったこといくつかかいつまんで。

- Yarn

とりあえず、、で使ってみてる。scripts で run 入れなくていいのが何気に楽。

- Webpack

リポジトリ作った当時は「ややこしいなこれ」と思いながら@1でやってて、年明けてしばらくしたら@2の正式リリースがきてて、バージョン上げてみたらやっぱりちょっと難儀でしたね ( PostCSS ウオオオ…！ってなった)。module つなぐところとか。なんだかんだ調べましたが、公式のドキュメントを見たら大体解決しました。

- React

ルーティングまでやったら SPA っぽくなるんですかみたいなノリで React Router。gh-pages にデプロイする段で最もハマった。（つぶしの効かない技術だと思う。基本的な Web サイト作れりゃいいやくらいのつもりで始めたのに。。ちなみに SuperAgent も普通のサイトのノリです。実データ扱いたかったし。） テストは Enzyme。

- XO, AVA, nyc

Electron 再入門した時に（「Backlog のデスクトップアプリ」「Electron 一年振りの 所感など」） sindresorhus さんのリポジトリ参考にしてたのでその流れでこの辺りまとめて使い始めてる。お手軽。

- PostCSS

個人的なデファクトになってきてる。何でもいいなら PostCSS で。今回は Webpack のローダー使ってるけど、本当は .postcssrc 用意して npm scripts にタスク振り分けるほうが好きかも。

あとコンポーネント化時代の CSS 管理手法的なアレ、どうしていこうかねって思ってて。今自分がやりたい感じだとこう https://github.com/hrfmmymt/react-babel-webpack/tree/master/src/css 以下概要

base.css : リセット、ヘッダー・フッターとかの共通要素

home.css / about.css / contact.css : ページ毎に親コンポーネントを定めて、以下に子要素吊るして指定して1ファイルとする。つまり table.css とか list.css とか input.css とか作らない。

style.css : 各々を import

と、書いてみたら昔ながらっぽく見えてきた。Bootstrap みたいに抽象化した要素・クラスを繋ぎ合わせてレイアウト組んでく手法の反動のような感じです。Bootstrap のデザインで何ヶ月か作り込んでくと、class の要不要がわからなくなって次第に考えるのをやめるとかないですか。

以上

React の素振り環境できたので使ったり遊んだりするかもしれないけど、面倒は見たくないなあ。。 とにかく、これらは業務でやったことないので「ちょっと見てみてくれ」って気持ちも。

[hrfmmymt]

Electron 一年振りの 所感など

丸一年以上前に雑に push した Electron アプリを久しぶりに触ってみたメモ。

hrfmmymt/Random-PW-Generator

やったこと

Electron のマイグレーション的なやつ（今日の作法で動かなくなっていた箇所の修正など。restart() が reload() になってたの知らなくて若干ハマったとかの。）

^ES2015

PostCSS

Travis CI

ちょっとした UI 修正

コミットログ

というか、いたって簡単な Chrome の拡張機能をそのままごっそり Electron 化しただけだったのを、もう少し現実的かつ継続的に開発していけるような体制に整えたという感じです。（但し、継続的に開発を行うとは言っていない）

それにしても誰かも言ってたような気がしますが Electron 、フロントエンドで荒みきった心の癒しですね。

[hrfmmymt]

Backlog のデスクトップアプリ

Electron で Backlog のデスクトップアプリを作ってリリースしました。 hrfmmymt/spinach

作ったといっても Webview をラップするだけ。しかも同じく Electron 製のアンオフィシャルな Facebook Messenger デスクトップアプリ、sindresorhus/caprine を大いに参考にさせてもらうだけというお手軽な製法。

Spinach という名前にしたのは Backlog のアイコンの葉っぱみたいなやつからの連想です。え、ていうか確認ですけど、これ葉っぱですよね？

Mac だけですが、お知らせのバッジ表示ができます。

Windows はメンテしないかも…動作検証くらいならまだいいけど、Windows 対応を前提とした開発めんどいなって…プライベートなアプリってことで。

あとはこれやっちゃうと Desktop Notification とかがなし崩し的に気になって来たりします。nーラボさんやるのかな。

[hrfmmymt]

[hrfmmymt]

Tab UI a11y

タブ UI 作ってたらなんかノッてきたのでいろいろ試してみました。

https://github.com/hrfmmymt/tab-test

以下、やったことをかいつまんで説明してみます。

WAI-ARIA

アクセシビリティやってみた。 タブの WAI-ARIA は実装するの初めてで、「お前の WAI-ARIA は本当の WAI-ARIA ではない」ってならないか不安です。とりあえず Nu Html Checker (https://validator.w3.org/) と ARIA Validator という Chrome の拡張は通してます。アクセシビリティのピンク本はしばらく電書待ちしてましたが、諦めて紙読み始めました（さっそく娘にシワつけられてる…）。

↓ HTML コード抜粋

以下お気持ち

タブの li に role="presentation" いるのかな？と、疑問が。

role="tabpanel" は section タグには設定すると上記 W3C バリデータでエラーがきた。微妙なハマリポイントかもしれない。理由もよくわからないです。

PostCSS

プリプロセス〜最適化に至る CSS に関わる一連の作業はすべて PostCSS を使用しています。 使用したプラグインは以下

プリプロセス - postcss-nested - ネスト - postcss-custom-properties - 変数 - postcss-calc - calc 関数 (上記 custom-properties にも対応してて、変数を織り交ぜた演算もできた)

ポストプロセス - autoprefixer - cssnano - minify ( PostCSS プラグインとは言い難いか)

あとはリンターに stylelint を使用。ESLint ライクにルール記述ができてよかった。

いちおう IE9 対応をうたってますが、具体的に何かというと、CSS の transform / transition をレイアウトに影響ない程度で留めたとか display:flex; を使わなかったってくらいのもんです。

JS あれこれ

2016年現在、特定の JS フレームワークに対する特定のお気持ちは割と冷めてきていて、でも Babel はやっていこうというのだけはある感じです。 あと、めっちゃ煽られそうですが jQuery です。割とササッと。 WAI-ARIA 対応のアクセシブルなタブ UI を React で実装する ::ハブろぐ の最後の文にはこうありますが、ユーザー操作をトリガーに取る処理書くの、jQuery がやっぱ楽だなと。ただ、やはり今おすすめはしづらいですね。パクるなら React 版にするべきです。 リンターは既に軽く触れましたが ESLint を使用しています。

テスト ~ CI

ノッたので E2E もやってて、使ったのは以下

Testium - テストフレームワーク

Mocha - テストフレームワーク

power assert - アサーション

つまり、 テストできないコードをE2Eテストを使ってリファクタリングしよう | Web Scratch で、これを要約するとすれば「最高」となります。テストコードも ES2015 で書きました。 テストフレームワークはまだまだお試し中。

で、プッシュ・プルリクエスト（ひとりだけど）する度に Travis CI で回しています。 ビルド結果はソロ Slack に通知。

その他

タスクランナーは Gulp 、サーバーは browser-sync 、あと conventional-changelog も使ってみてて、今では順調にサボっています。

デプロイは Github Pages。master ブランチの docs ディレクトリで公開できるようになったのも試してみてますが、.travis.yml をルートディレクトリに置いて node のバージョンとか見るのどうやるんだろうとか思いつつ、gh-pages ブランチを使ってます。 https://hrfmmymt.github.io/tab-test/

TODO

E2E 不足の解消としっくりくるテストフレームワークが欲しい

issue ブランチで Nightwatch とか Nightmare を試してみようとはしてる

Travis CI で自動デプロイやろうとしてた

関連で、Nu Html Checker とかビルドプロセスに組み込めたらーと思いつつ何もしてない

所感

タブ UI とか、今までだったら JSFIDDLE や Codepen などで完結させるところでしたが (実際痕跡がある http://codepen.io/hrfmmymt/) 、この程度の極小規模開発でも（だからこそ）あえてリポジトリを作ることで、いつの間にかクライアントサイド（あえての表現）でできるモダンな開発環境セットアップ〜開発フローを一気にさらえた気がしています。満足😇

やっていく

やっていくぞ

参考文献

WAI-ARIA の基礎知識 — Website Usability Info Accessible Rich Internet Applications (WAI-ARIA) 1.1 Practical ARIA Examples PostCSSとは何か - morishitter blog PostCSS とは何か // Speaker Deck morishitterのCSSの書き方（2016年夏） - morishitter blog CSSのLintをstylelintにする - Qiita WAI-ARIA 対応のアクセシブルなタブ UI を React で実装する ::ハブろぐ テストできないコードをE2Eテストを使ってリファクタリングしよう | Web Scratch Auto-deploying built products to gh-pages with Travis

[hrfmmymt]

「マイクロインタラクション」

読書感想文。

“Design is not just what it looks like and feels like. Design is how it works.” --Steven Paul Jobs

これを Web デザインで解釈するにあたっての具体的な方策・答えの一つ、それが本書に書かれていたように思う。

この前に「誰のためのデザイン？」「融けるデザイン」を読んでいて、この連続した読書体験がとても気持ち良かった。

[hrfmmymt]

土日開放してる保育施設に、バス乗って行った。 黒塗りの高級車。