アイコンフォントの運用をどうするか考える

gulp-iconfontでアイコンフォントを生成して運用していく生活が辛くなったので、素のSVGを使っていくのが現実的なのかを調べてみた。

辛くなったのはアイコンフォントのCSS調整するのが億劫になったのと、SVGの種類が増えるたびにアイコンフォントを更新するのが面倒になったことの2つの理由がある。

使用できる参照方法

そもそも、SVGをHTML上で扱うには4つの手段がある。

• SVG要素をHTML上にインラインで配置。
• object要素で参照。
• img要素で参照。
• CSSのbackground-imageで参照。

普通に配置したいだけであればどれを選んでも問題ない。しかし、CSSでSVGを装飾したい場合は話が変わってくる。

CSSで装飾したい場合

結論から言うと「SVG要素をHTML上にインラインで配置」しかない。

img要素やbackground-imageで参照したリソースに対して指定できるのはwidthやheightに限られるので、参照したSVGの色の変更することは出来ない。

一方、object要素はiframe要素と同様に外部リソースを参照するための要素であるため、CSSの参照は出来ない。（冷静に考えると、参照できたらセキュリティの抜け穴になりかねないので出来てはいけない）

SVG要素をインラインで配置する際の課題

インラインで都度記述するのが単純に面倒。アイコンフォントであれば、i要素やspan要素にクラスを設定するだけで使用できることを考えると、一層面倒に感じる。

というわけで、丸一日考えた現時点では以下の結論に至っている。

• 装飾の必要がない場合はimg要素やbackground-imageで参照。
• 装飾の必要がある場合はインラインで配置。

アイコンフォントに強いこだわりが無かったり、そもそも素のHTMLを書いたりしていない場合は素直にFontAwesomeとか使った方が圧倒的に楽です。そちらをオススメします。

英語力をつけるための習慣をつける

これまで雰囲気で英語を使ってきて、語彙力が全然足りてないなと日々思っていた。 また、技術的なトピックには日常的に英語で触れているものの、普段から触れている文章のジャンルが偏りすぎるのも良くないと感じてもいた。

ということで、この本の原書を読み始めました。

https://www.amazon.co.jp/Intellectual-Devotional-Complete-Education-Confidently/dp/1594865132/ref=sr_1_1?ie=UTF8&qid=1535375952&sr=8-1&keywords=intellectual+devotional

日本語訳されたものも出版されていて、本屋に行くと平積みされています。

1日１ページ、読むだけで身につく世界の教養３６５ | 文響社 Bunkyosha

どんな本？

日替わりで内容が変わる7つのジャンルのコラムが1年分載っていて、曜日ごとのジャンル振り分けはこんな感じになっています。

• 月曜日：歴史
• 火曜日：文学
• 水曜日：芸術
• 木曜日：科学
• 金曜日：音楽
• 土曜日：哲学
• 日曜日：宗教

各分野ごとに違う人が書いているので、言い回しや文章にも各々の癖が見て取れて面白いです。 原書の初版発行が2006年で本自体は少々古いですが、この12年の間に根底を覆されている話はあまりないと思うので、話の鮮度はそこまで気にせずに読めています。

何をやっているのか

1. 文章をノートに書き写す。
2. 自分で全部翻訳をする。
3. 全文を声に出して読む。

これを毎日継続します。文章の分量は多くないはずですが、1日分の量を済ませるために今は2時間くらいかかっています。

聞き慣れない単語や知らない文法が多く出てきて調べるのに時間がかかったり、自分の訳が文章的におかしかったりするのを見直したりしている間に結構な時間が経過しているようです。

あと、造詣がない分野の日はきついです（僕は海外文学をあまり読んだことが無いので、文学の日は基本的にハードモードです）。

やってみている感触

毎日継続するのはなかなかきついんですが、継続の甲斐あって英文に対する抵抗感（「読むのめんどくさいな・・」というような気持ち）は少しずつ薄れている実感があります。

また、知らない分野のことを知れるのは単純に面白いので、これを楽しみに続けられてます。

継続にあたって意識していること

• 「体調が悪くて、今日の分が出来なかった。」
• 「急に呑みに行くことになって、今日の分が出来なかった。」

こういう展開はたまにあります。たまにあるんですが・・その日に勉強出来なかった事で自分を必要以上に責めないようにしてます。自分に厳しくし過ぎて消耗してしまっては本末転倒です。

そういう日が週に4、5日あるようでは、さすがに生活を見直さなければならないと思います。ですが、週に1日程度であればそこまで気にしない事にして、別の方法で勉強することで穴埋めをする方針にしています。

別の勉強とは

• TEDで面白そうな動画を見る。
• 自分が好きな海外ドラマを英語で見る。

机に向かう元気が無い時は上記の方法を選んでいます。

TEDの動画であれば長くて15分くらいなので、そこまでのエネルギーはかけずに見ることが出来ます。

海外ドラマはこれを1話から見ています。

www.suits-tv.jp

登場人物がエリート揃いの設定なので、スラングが飛び交ってばかりの会話になることもないです。法廷ドラマなので、銃撃戦で人が死ぬこともなく精神衛生上優しいということもあり、他人にオススメしやすいです。

まとめ

自分なりの勉強法を纏めてみました。「これが最強の勉強法」だと言うわけではなく、あくまで自分に合っていそうな勉強方法を模索した結果を書いてみた次第です。

「英語の勉強、続かねえ〜〜／(^o^)＼」という方のとっかかりになれば幸いです〜。

西日本応援プロジェクト 真夏の大LT大会！に行ってきました

techplay.jp

最近外部のイベントにあまり行っていなかったし、西日本の様子をニュースで見る度にしんみりしてて「寄付くらいしてみるか」という気持ちにもなっていたりしたので、ﾊﾟﾊﾟｯと申し込んで行ってきました。

行ってきた感想

1000円寄付した程度で聞いていいのか不安になるほどの豪華な内容で、「最高」以外の言葉がないイベントでした。チャリティコンサートに行ってきたのと同じくらいの楽しさがあったと感じています。頭の中でぐるぐる回っている感想を書き出すと、以下のようになりました。

• メガネ型のウェアラブルデバイスが全盲のユーザに目の前の様子を音声で教えてる動画を見て、凄くドキドキした。

• 自分の身内が西日本にいるわけではないんだけど、被災地の動画を見てると言葉が何も出てこなくなった。

  • IT DARTのTwitterでボランティアの募集状況とかを周知してるのは全然知らなかったので、広く知られて欲しいと思う。

• 自分の昔のブログやHPを今見たら、確実に悶絶死すると思った（遠い目）。「当時はこれがカッコいいと思ってた」みたいのは誰しもが通る道ですよね。

• 緊急地震速報のChrome拡張の存在を初めて知った。

  • 身近な友人が被災していた出来事だったはずなのに、7年前の地震の記憶が自分の中で風化しつつあるのを実感した。

• VP of Engineeringを受け持つくらいの人は色んな経験をしていた。

  • キャリア相談をしてくれて、1相談ごとに1000円を寄付するという謎企画があるそう。

• カンファレンスの開催はお金がかかる。正直予想以上だった。1万円とかで参加できるなら安いもんだと感じてしまった。

• Railsを支えている@kamipoさんの偉大さを知る。

• 有益（今日から使えるとは言っていない）なPHP情報は個人的に一番ツボだった。

• 出版業界の大変さを知る。実はWEB+DBに寄稿するのは個人的な夢なので、いつか書いてみたい。

• ネットワークがダイヤルアップからADSLに変わる辺りでこの世界に首を突っ込み始めたので、昔話は完全に俺得状態で面白かった。

酪農の話が個人的に凄く気になっていたのですが、尿意に負けて聞けなかったのが残念・・(´・ω・｀)。

資料のURLや当日の様子はTwitterのハッシュタグを遡ればOKだと思います。

#midsummer_lt - Twitter Search

まとめ

肩肘張らずに楽しく寄付が出来るのは凄く素敵な事だと思うので、主催してくれた方々に感謝です！ありがとうございました！

builderscon tokyo 2018にCFPを出してみた。

builderscon.io

タイトルの通り、CFPというものを生まれて初めて出してみました。

日頃からアウトプットが足りない自覚はあったし、身近な人にそこを窘められる事も多々あったので「いい加減やっていかねば！」という気持ちで行動を起こしてみてます。

シェア数なども採択の考慮に入るという情報を完全に見落としていたので、ブログでも情報発信してみようと思います。（ちょっと図々しいですかね？）

どんな話をするのか

フロントエンド領域で3年近く働き、制作会社や事業会社の仕事も経験する中で試行錯誤してきたことを掻い摘んで話していきます。

• セマンティックなHTMLって一体何だよ。
• CSSの設計・運用つらい。
• jQuery使ってまともな設計するの無理じゃない？
• WordPress分からん。
• SEOの正解が分からん。
• Webアクセシビリティは何をすればいいのか分からん。

...といった具合に、フロントエンド領域の人間が考えないといけない事はたくさんある中で、 自分がどういったアプローチを取ってきたのかを共有できたら良いなと思っています。

しない話

「React vs Angular vs Vue」みたいなフレームワーク談義はしません。

• 自分がしっかり使い込んだことがあるのがReactしかないので、他については言及できない。
• 僕よりも詳しい人たくさんいると思うので、自分が話す必要性を感じない。

という理由があるので、僕は泥臭さ全快の話に振り切るつもりです。

まとめ

採択されるかは不明ではあるものの、既にネタは練り始めています！ もし興味を持っていただけたら、SNSでのシェアをして頂ければ幸いです。よろしくお願いしますー！！

「第69回 HTML5とか勉強会」に参加してきた

最近は外部のイベントに参加してなかったので、久々に「HTML5とか勉強会」に参加してきた。

1年以上開催されてなくて「もうやらないのかな・・」と内心思っていたので、今回復活してくれて個人的にとっても嬉しいです。

内容

今回はフロントエンドのUIフレームワークがテーマ。

• Angular: 「Angular Ivyとその先」
• Vue: 「vue-cli-v3」
• React: 「Suspense」

といった流れで、それぞれのフレームワークの最前線の話が色々聞けた。

Angular Ivyとその先

Angular Ivyとその先

Angularは1系の頃に結構触った後、4系のチュートリアルを一周したくらいの知識しかないので「今のAngularはこういう感じなのか・・！」という感想。

IvyはAngularにあるrendererをより小さく、早く、シンプルにしようというプロジェクトらしい。Angular Elements（Angular上のCustom Elements）がbundleされたものを軽量化しようという目論見がある、という話が個人的には興味深かった。

最近個人的興味でAngularの近況を追う事が多かったので、Angularの進化を知れて非常に良かった。ドキュメントの日本語翻訳も盛んだし、頑張ってほしい・・！

vue-cli-v3

Vue CLI v3 - Speaker Deck

Vueは完全に趣味で30時間くらい触っただけなので、完全な初心者目線で聞いてた。

雑に言うと「CLIをGUIで操作できるツールが、ロードマップにも無かったのに爆誕した」という話だった。Vue界隈のコミュニティはよく知らないですが、なかなかファンキーですね。

@kazu_ponさんのデモを見ていたが、僕が想像していたよりもちゃんとしてて、必要な事は大体やれる印象を受けた。設定を分けてのbuildをGUI上でやれたり、設定そのものを弄れたりと、なかなかに便利そう。

「作者の人が飽きちゃって、メンテナンスされなくなったりしないのかなー・・」という不安は個人的にありつつも、Vueに対しては親しみやすさを持ちました。

Suspense

React Suspense - Speaker Deck

Reactはv15.4くらいの頃に消耗してたり、Reduxの正解が見えなくなったりしてたのが1年ちょい前。最近はプロダクトで触ることがなかったので、近況がどうなってるのかは正直気になってた（キャッチアップはサボってました）。

雑に言うと、「これまでは成功、失敗などの各状態をstateで持って頑張っていたPromiseの依存を解決する仕組み」らしい。

「画面に存在するコンポーネントの数だけ、ReduxでいうところのStateが増えていく流れを止めることが出来るのか・・。Promiseの状態管理とか、コンポーネントのキャッシュ管理が仕組み化されるのは嬉しい。」というのが個人的な感想。

v17から入るそうな。

パネルディスカッション

色んな話が上がってました。

• コントリビュートは仕事中にしてる。
• コントリビュートのチャンスは、ドキュメントの整備を狙うといい。
• サードパーティのライブラリのメンテも狙い目。
• Angularはコアメンバーがすぐに対応しちゃうので、本体はコントリビュートのチャンスがあまり無い。
• Angularあんまりいじめないで。

辺りの件が強く印象に残ってたけど、他は忘れてしまったので動画を見直します・・(ヽ´ω`)。

まとめ

久々の「HTML5とか勉強会」でしたが、非常にワクワク出来て楽しかったです！ 今後はWeb技術全体を俯瞰出来る会になるそうなので、今後の展開に期待ですねー。

会社に掛け合って会場を貸し出したり、運営のお手伝いとかやってみたい気持ちはあるんですが、どこで声をあげればいいのだろうか・・。

anime.jsを導入する

「なんかこう・・ｼｭｯって感じでスクロールアニメーションさせたい」

随分前にReact/Reduxの開発をやっていた時期にも同じ台詞を聞いたのですが、この台詞を再度聞く事になるとは思いませんでした。

自分が関わっているプロダクトではjQuery2系が余裕で現役です。手早く実装しようとすると「animateメソッドで特定の箇所までbodyを動かす」という実装に走りがちなのですが・・案の定パフォーマンス上で問題が生じたので対策を考えることにしました。

考えた対策

• requestAnimationFrameを駆使して、自力で実装。
• Web Animations API導入ワンチャン・・？
• いい感じのライブラリを探す。

思い浮かんだのはこの3つです。

タイトルで言っちゃってますが、結果的には3つ目の方法を選択しました。 とはいえ、せっかくなので他の2つにも触れようと思います。

requestAnimationFrameで自力実装

僕は基本的に自力フルスクラッチを好む人間なので、まず自力実装を検討してみました。しかし、今回は自力実装はしない方針にしました。理由は以下の通りです。

動きのバリエーションを増やすのが大変

今回実現したい要件として「イージングをつけたスクロールをしたい」があります。

イージングの動きを自力で実装するのはなかなか大変です。多くの人が一度は耳にした事があるであろうベジェ曲線との戦いは避けられません。イージングの種類を増やしたいという要望が増えれば、自力実装は雪だるま式に増えていく未来が今から見えています。

メンテしていくのも面倒だし、他の誰かにそれをメンテナンスさせるのも嫌だったので、今回は自力実装はしない方針にしました。

※余談ですが、ベジェ曲線に入門したい方は以下のリンクがおすすめです。

blog.sigbus.info

Web Animations API

個人的興味はあったんですが、これも早々に諦めました。ブラウザ互換性がまだまだで、Safariの対応が無かったことが大きな理由です。

弊社プロダクトのユーザの半分がiPhone、つまりSafariユーザなのでPolyfillは絶対に必要です。Polyfill併用の運用もなかなかに手間だと考え、導入は見送りました。

いい感じのライブラリを探す

選んだ手段はこれでした。選定基準は以下の通り。

• ブラウザサポートがそこそこ。
  • Android > 4.4、iOS Safari > 9を満たせてればOK。
  • IE11で動けばベター。
• ドキュメントがある程度整っている。
• ライブラリ本体が軽量である。
• ライセンスはなるべくMIT。
  • プロダクト内で使う範囲を広げた時、ライセンスが足枷にならないようにするのが目的。

この辺りを踏まえつつ、↓のリンクを参考に選定したのがanime.jsでした。

The Top 9 Animation Libraries for UI Designers in 2017 — SitePoint

実装例のサンプルがやけに充実しているので、興味のある方は是非に。

animejs.com

デモ

ボタンを押すと画面最上部まで戻るだけのデモです。

codepen.io

jQueryに依存しないコードを書いたら、古めのChromeやSafariで動かない地雷を踏み抜いたので、その辺の対応が入っています。

「動かなくない？？」という方がいれば、コメントして頂ければ幸いです。

参考にしたリンク

新しいChromeでスクロールが取れない？ scrollingElement？ | Ginpen.com

古めのChromeやSafariで動かなかった時に参考にしました。

結局のところ、比較的新しいのモバイル環境であれば「scrollingElement」をつかうで良いと思います。PCの場合がIE11を想定した分岐処理が必要にはなるでしょう。

ServiceWorker導入を一旦諦めようと思った話

自分が関わっているプロダクトにServiceWorkerを入れる試みを4月中盤からやっていたのですが、直近でやり切るのは無理そうな気がしてきたので一旦諦めました。（完全に諦めるわけではなく、地道に研究は続けます。）

その過程で検討した事を記録に書いておくことにします。

やり始めた経緯

社内で技術投資枠（業務時間の10％を使い、実業務に活きるチャレンジングな事をする仕組み）を設ける取り組みが始まったので、前から興味があったServiceWorkerを試してみたくなったのがきっかけです。

「Safariで使えないしなー」という言い訳も通用しなくなりつつあるので、本格的に触らなければと思っていたのも理由の一つです。

入れようとしたプロダクトはどんなもの？

僕は今、リブセンスという会社でアルバイトを探すサービスの開発を担当しているのですが、ユーザの行動は以下の3つに絞れると思っています。

• アルバイトの求人情報を探す。
• アルバイトの求人情報の詳細を見る。
• アルバイトに応募する。

ユーザに応募してもらわないことにはお金が生まれないビジネスモデルなので、応募率をいかに増やすかを考えなければなりません。

ということで、応募に辿り着くまでの体験を良くするためにServiceWorkerを活用する余地はあるかどうかを検討していきました。

実際に試してみる

検討したものは以下の通り

• 静的リソースのキャッシュ
• ページそのもののキャッシュ
• プッシュ通知

静的リソースのキャッシュ

これはそこまで難しい話ではありません。

• 何のファイルをいつキャッシュするか？
• 運用フローをどうするか？

決めるのはこれくらいです。

ServiceWorkerのインストール成功時に、更新頻度の少ないファイルを選択してキャッシュしておく・・くらいの事なら楽にやれると思います。

とはいえ、今回の場合はキャッシュできるファイルが存外少なく、大した効果が見込めないことがわかりました。（手早くキャッシュに回せるのはロゴのが画像や、フォントファイルくらい）

リソースの更新が発生した場合のServiceWorkerの更新が煩雑になるだけな気がしたので、今回は一旦見送っています。

ページそのもののキャッシュ

どのページをキャッシュして、そのキャッシュをいつ破棄するのかが難題だなと感じています。

ニュースサイトやブログサービスであれば、TOP画面に出ている直近のコンテンツを幾つかキャッシュしておくのは良さそうと思っているのですが、今回の場合はどうすべきなのか非常に悩みました。（やたらとキャッシュしまくって通信料を食いすぎたら意味がないですし）

アイデアベースで今回考えられたのは、以下の2つくらいでした。

• 求人情報にレコメンドされて表示される求人をいくつかキャッシュ
• 「後で読む」的な機能が存在するので、それに追加された求人情報をキャッシュ

アイデアとしては悪くない気がするものの、一人で先走って実装するのは早計なので周りへの相談が必須かなというところに落ち着いています。

（ここ半年、一人で先走って失敗した経験があるので大分慎重になっています・・）

プッシュ通知

悪名高いアレです。

ページを初訪問した途端、「ども！！自分、通知いいすか？？」と許可を求めてくるサービスも多く、辟易している方も少なくないと思います。

Rebuild.fmのように配信を通知してくれる使い方は素敵だと思うので、ああいうユーザ体験が増えるといいのですが・・。

というわけで、本番運用するまでの準備は相当慎重に運ぶ事に留意しつつ、アイデアを練ってみました。

「後で読む」している求人の掲載期限が切れそうになったら通知を飛ばす

弊社サービスでは「キープ」と呼んでいる機能があります。

「気になるし、とりあえず保存しておくか」という時に使う機能ですね。 キープしている求人の掲載期限が終わりそうになったら、キープしているユーザにお知らせ通知を飛ばそうという話です。

自分はTwitterの「いいね」を「後で読む」と同じような使い方で使っているのですが、自分でいいねした事を忘れてしまうことがよくあります。 （毎週末、整理するようにはしているのですが）

これと同じ話で、「キープ」されただけで応募されずに埋もれてしまっている求人は多いんじゃないかなーと、個人的に思うわけです。 （書いてる内に気になってきたので、分析したくなりました）

自分一人で進められる話でもないので、これも周りとの相談が必須ですけどね。

試してみた感想

技術的にも興味深い領域で面白くもあり、導入の検討を進める内にプロダクトへの理解も深まったのでやってよかったと思いました。

事業会社に転職して8ヶ月ほど経ちましたが、事業そのものへの理解を深める事への重要性を再認識しました。

「成果を爆速でリリース！」といかなかったのが残念ではありますが、地道にやっていこうと思います。

※手元のメモが消えていたので、参考にしたサイトのURLなどは後で発掘して書きます。

余談

PWAの研究も並行して進めていたのですが、manifest.jsonでフルスクリーン指定にする場合はUIをアプリと親しい構造にしないと逆に使いづらくなるという知見がありました。

Google I/Oのセッションは全然チェックしてないのですが、PWAのセッションはあるんですかね・・？