patorashのブログ

方向性はまだない

オープンセミナー岡山2018に参加してきた

5月12日（土）に開催されたオープンセミナー岡山2018に参加してきました。

okayama.open-seminar.org

今回のテーマは「エンジニアの生存戦略と働き方」で、どういう現場で働いている方であろうと参考になりそうなテーマです。

当日のツイートはtogetterに纏められています。

togetter.com

共通していると感じたこと

だいたいの講演者の方の生存戦略として共通していたことは、「自分を売り込むこと」をちゃんとしていることだったと思います。

ソニックガーデンの@jnchitoさんの場合は、「オブジェクト志向をやってます！」とアピールしたことで、そういう案件にアサインされたことや、転職の際に読んだ本のリストを作ってアピールすることで勉強熱心さを伝えていました。

NHN Japanの@S_O_F_Scienceさんの場合も、資格を取りまくってアピールし、他の社員と比較されたときに目立つ点を作っていたこと。

イーネットワークスの@maeponさんも「何か手伝いますよ」というところから登壇し、そこから「頼んだらやってくれる人」になっていったこと。

@llminatollさんの場合は、SNSでのテストマーケティング自体が調査だけでなく、自分を売り込むことにつながっています。

GitHubの@ikeike443さんの場合は、GitHubの求人が出たときに、日本の商習慣に詳しい自分は必ずGitHubに貢献できると、英語がしゃべれないけれど猛アピールして、英語が喋れないGithubberとしてジョインされたと言われていました。

農業を始めたひらさんも、他の農家さんと話すことでノウハウを得たり、土地を借りたり農業機械を譲ってもらったりというのは、売り込んだ結果だと思います。

ただアウトプットするだけでなく、戦略的に他者にそれを気づいてもらえるようにして、勝ち取っているわけです。

与えることで生まれる好循環

与えること（アウトプットすること）で何が生まれるか？それは信頼です。@maeponさんの言葉を借りると、「知ってもらうだけじゃダメ、『これを頼める人』になる」ということです。

「頼める人」になれば、そのコネクションを活かして仕事や執筆の依頼がくるようになるわけですね。@maeponさんや@llminatollさん、@jnchitoさんもそれが執筆につながったのだと思います。

生きろ！好きを守れ！

これもまた結構共通してたと思います。要はワークライフバランスとかの話ではあるかと思うのですが、自分というリソースを消費しすぎると体を壊しますし、家族やチームにも迷惑をかけることになりますし、なにより自分が楽しくない。優先順位をつけて、身の丈にあった継続性を守ることで、自分の「好き」を守りつつ取り組むことができます。ひらさんの話（農業）でも規模拡大をして様子を見た後、縮退することで身の丈を知ると言われてました。

@maeponさんは転職の際、元々はフリーランスになるつもりだったけれど、個人活動を認めてくれるという条件で入社したことで、「好き」を守りつつ、「好き」を仕事に活かしてます。

@llminatollさんはWebデザインと絵と教育に対する情熱とのスキルミックスで「好き」を活かす道を見つけてます。

@ikeike443さんは、ソフトウェア化している現代社会において、エンジニアのできることが広がっている=エンジニアには幅広い選択肢が広がっているといいます。ひらさんが言われていた、「仕事は嫌でなければなんでもいい。好きを守れ」というふうに考えると、いろんな業種への転職でも、エンジニアの経験はどこでも活用できるかと思います。

まずやってみる、の前に

やってみるという行動力は重要だけれど、その前にまず3C分析と言われていたのが@llminatollさん。勢いで記事にしてみたものの、思ったより反応が悪かったりしたので、3C分析とテストマーケティングをするようにしているそうです。

キャッチアップはどのくらいか？

記事を書くだけでなく、技術のキャッチアップにも同様のことが言えそうです。@jnchitoさんも、全ては追いきれないのでしばらくは様子を見る、楽しくないと続かないし身に付かないと言われてました。これは本当にそうだなと思います。とりあえずやってみた系のやつ、すぐ忘れてしまうので…。

ただ、特定の技術で突出したい！ほとんどまたやっている人がいないからこれでテッペンをとるんだ！というときには（先行者利益を目指すということ）、分析してもしょうがないかなと思います。

@jnchitoさんのあのラジオのお便りコーナーみたいなの、面白かったのでまたやってもらいたいですね。いろんな人のバージョンで見てみたい（聞いてみたい？）です。

とはいえ、やってみるのも大事

謝罪ファーストでブログにできそうなら行動してしまうというClassMethodの@kongmingtrapさんの話も面白かったです。福岡からスターエンジニアを輩出したい！という目的でどんどんイベントを開催してエンジニア発掘の機会を作っているというアグレッシブさは見習いたいところです。

生存戦略の指標

@jnchitoさんが「基本戦略を考える」で言われていた「評価基準を社外に置く」で、

  • 社外でも通用するか
  • 5年後でもやっていけるか
  • いざというときにそれを証明できるか

というのは、エンジニアであれば意識しておきたいところです。

社内での評価のみだと「井の中の蛙」になりかねず、社外ばかりに目をやるのは組織の一員としてちゃんと会社とその顧客に貢献できているのか？という点においてよくないことだと思います。

スキルミックスを意識する

@llminatollさんと@ikeike443さんが言われていたスキルミックスにより希少価値を高めることは、そのまま自分の市場価値を高めることにつながっていること思います。生存戦略において、今のスキルでミックスできないか？を考えることと、5年後を見据えてスキルを身につけていくというのも戦略的に使えると思いました。

まとめ

生きろ！

現在、自分は育児休業中で、家事・育児をしつつ多少の仕事をするという日々を送っているので、@jnchitoさんの仕事と家族サービスのバランスを考えるというあたりの話は本当に共感でした。最近は自分も朝活するようにしています（時々二度寝しますが）。

今回は運良くじゃんけん大会で勝って、チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)をいただきました！読んで勉強したいと思います！

とてもいいセミナーで参考になりました。講演者の皆さま、そしてオープンセミナー岡山のスタッフの皆さま、ありがとうございました。 f:id:patorash:20180512181033j:plain

最後に

オープンセミナー岡山2018は、私が所属している株式会社リゾームがプラチナスポンサーをしていました。

www.rhizome-e.com

今回はスポンサーセッションで弊社代表の中山が講演しましたが、弊社は仲間を募集しております。私が所属しているグループはRuby on Railsで自社サービスの開発を行っていますが、講演でも言っていたようにMicrosoft系の技術を活用しているチームもありますので、もし弊社にご興味がある方は以下のGreenのサイトからご連絡ください！

https://www.green-japan.com/job/58045?case=login

もしくは、SNS経由で弊社の社員まで連絡してくださっても構いません。よろしくお願いします！

月毎の累計を行うクエリ

PostgreSQL SQL

先日、年毎の累計を行うクエリについての記事を書きました。

patorash.hatenablog.com

すると、「月毎のデータも欲しいです」と言われたため、そちらもやってみました。

集計関数を使うと月のデータが歯抜けになる問題

前回のクエリを改修すればすぐできるだろうと思っていたのですが、月毎で集計すると、データの登録が全くない月などもありまして、歯抜けのデータが作られました。以下のような感じ。

SELECT 
  date_trunc('month', created_at)::date AS "月",
  COUNT(*) AS "月間登録数"
FROM foos
GROUP BY date_trunc('month', created_at)::date
ORDER BY "月" ASC;
月 月間登録数
2013-06-01 10
2013-08-01 10
2013-09-01 10
2013-11-01 10
2013-12-01 10

2013-07-01と2013-10-01が抜けてます…。これでは欲しいデータになりません。

月データを生成する

Postgresqlには、generate_seriesという便利な関数があるので、これを利用して基準の月データを作ってみましょう。

SELECT
  generate_series('2013-06-01','2013-12-01', '1 month'::interval)::date AS month
ORDER BY month ASC;

結果は以下の通り。

月
2013-06-01
2013-07-01
2013-08-01
2013-09-01
2013-10-01
2013-11-01
2013-12-01

これに対して、JOINしていきます。

基準の月データに対してJOINする

あとは前回と同様、対象月以前のデータを連結するという条件でJOINします。

SELECT
  months.month AS "月",
  SUM(foos.created_count) AS "累計登録数"
FROM (
  SELECT
    generate_series('2013-06-01','2013-12-01', '1 month'::interval)::date AS month
) months
LEFT OUTER JOIN (
  SELECT 
    date_trunc('month', created_at)::date AS month,
    COUNT(*) AS created_count
  FROM foos
  GROUP BY date_trunc('month', created_at)::date
) foos ON months.month >= foos.month
GROUP BY months.month
ORDER BY months.month ASC

結果は以下の通り。

月 累計登録数
2013-06-01 10
2013-07-01 10
2013-08-01 20
2013-09-01 30
2013- 10-01 30
2013-11-01 40
2013-12-01 50

集計関数を使うと歯抜けになりがちなデータも、これでバッチリですね！

年毎の累計を行うクエリ

PostgreSQL SQL

担当しているサービスのマスタデータにて、年毎にどれ位の登録数が増えていっていたかを見たいと言われたのでSQLを組んでみたのだが、なかなか思いつかなかったのでメモを残しときます。

年毎の累計とは

以下のような感じで、年間登録数と、累計登録数を使いたいという場合の話です。

年 年間登録数 累計登録数
2013 100 100
2014 100 200
2015 100 300
2016 100 400
2017 100 500
2018 100 600

年毎の登録数を出す

年間登録数はサクッとGROUP BY date_part('year', created_at)で出せます。

SELECT 
  date_part('year', created_at) AS "年",
  COUNT(*) AS "年間登録数"
FROM foos
GROUP BY date_part('year', created_at)
ORDER BY "年" ASC;
年 年間登録数
2013 100
2014 100
2015 100
2016 100
2017 100
2018 100

ここで、累計どうすればええんや…と悩んでしまいました。

過去のデータをJOINせよ！

まずは、全く同じデータをLEFT OUTER JOINして、条件にA.year >= B.yearとします。 Postgresqlのgenerate_series関数を使って、年を生成し、そこに先ほどのデータをINNER JOINして、条件にA.year >= B.yearとします。

SELECT
  A.year AS "A.年",
  B.year AS "B.年",
  B.created_count AS "B.年間登録数",
FROM(
  SELECT generate_series(2013,2018) AS year
) A
INNER JOIN (
  SELECT 
    date_part('year', created_at) AS year,
    COUNT(*) AS created_count
  FROM foos
  GROUP BY date_part('year', created_at)
)  B ON A.year >= B.year
ORDER BY A.year ASC

すると、以下のような感じに…。

A.年 B.年 B.年間登録数
2013 2013 100
2014 2013 100
2014 2014 100
2015 2013 100
2015 2014 100
2015 2015 100
2016 2013 100
2016 2014 100
2016 2015 100
2016 2016 100
2017 2013 100
2017 2014 100
2017 2015 100
2017 2016 100
2017 2017 100
2018 2013 100
2018 2014 100
2018 2015 100
2018 2016 100
2018 2017 100
2018 2018 100

基準の年(A.year)以前の年のデータを全てINNER JOINで連結します。 あとは、GROUP BY A.yearを行い、B.年間登録数をSUMで集計すればOK！

以下が、完成形のSQLです。無駄なSELECTなどは削除してます。

SELECT
  A.year AS "年",
  SUM(B.created_count) AS "累計登録数"
FROM (
  SELECT generate_series(2013,2018) AS year
) A
INNER JOIN (
  SELECT 
    date_part('year', created_at) AS year,
    COUNT(*) AS created_count
  FROM foos
  GROUP BY date_part('year', created_at)
) B ON A.year >= B.year
GROUP BY A.year
ORDER BY A.year ASC

これで、累計データが取れました。

年 累計登録数
2013 100
2014 200
2015 300
2016 400
2017 500
2018 600

晩御飯を食べてる時に、妻に相談したら、ヒントになる話が得られたので、助かりました。

2018-05-11 追記

Postgresqlのgenerate_seriesで年を生成すると、万が一その年のデータが存在しない場合にも歯抜けにならなくて済むのでそうしました。

1回の熟読より適当に何度も読み返すほうがよさそう

読書

Kindleの積ん読があるにも関わらず、GWのブックオフの20%オフセールに釣られてまた本を増やしてしまった私。今回はテレビでも見たことがあった7回読み勉強法についての本を読んでみた。

東大首席弁護士が教える超速「7回読み」勉強法

東大首席弁護士が教える超速「7回読み」勉強法

著者の経歴

著者の山口真由さんは、東大を首席で卒業、東大在学中に司法試験に合格と、国家公務員試験に合格して財務省に入った後、弁護士になったという方である。

この本では、東大に入るまでの勉強法、入った後の勉強法、司法試験の勉強にどう取り組んだか、社会人になってからの勉強についてや、息抜きやモチベーションの維持などについて書かれていた。

勉強は苦痛なことでもある

「勉強が好きなんですね」とよく言われていたというが、そんなことはなくてむしろ苦痛なこともあるけれど、勉強していた結果、あとで報われる快があるということをちゃんと書いていてくれているので読み始めから好感が持てた。勉強や努力という言葉を嫌う傾向が最近の世の中にあると思うのだけれど、やりたいことの中には、往々にして多少のやりたくないことも含まれているので、そこをどう折り合いをつけていくかってのが大事で、そこを乗り越えるのに勉強や努力のパワーが要ると個人的には思っている。最初は苦痛だけれど、わかるようになったら楽しくなった、ということを表現してくれているのは、とてもいいな思った。

最初の苦痛を乗り越えるための方法論が7回読み

つまりは、苦痛を減らして数をこなしているうちに楽しくなるところまでもっていくのが7回読み勉強法である、と感じた。7回読むことを勉強のルーティーンにしてしまおう、ということだ。最初から7回読むと決めてかかって、3回くらいまでは内容がわからなくてもとりあえずどんどん読んでいくのを繰り返す。その間に、その本を読むための土台が作られていく。それ以降に詳細部分を理解していくように詰めていくという感じだ（詳細は本を読んでほしい）。

3回を超えたあたりで、多少はわかるようになってくるので楽しくなってくるんだと思う。

7回解きも有効

数学など、理論の問題は読むだけでなく、7回解いてみるのだという。これは自分が高校3年生の秋頃に知った勉強法と似ている（マジでもっと早く知りたかったやつ）。といっても私が知った勉強法は7回解くではなく、「問題集の回答を丸々書き移していくのを何度も周回する」というものだった。こんなことをして応用力がつくのか？と思われるかもしれないが、基本がわかっていないと応用もできないので、当初は疑心暗鬼ながらこれをやってみたら急激に理解力が上がった。が、丸々写していくのは時間がかかる作業で、全範囲を書き写していくのは受験に間に合わなかったので、もっと早く知りたかったのだった…。しかし、赤点を取るほど足を引っ張っていた数学が平均点以上取れるようになったときは嬉しかったのは今でも覚えている。

話が自分の過去の経験に脱線してしまったが、この体験を元に資格試験の勉強のときにも同じようなことをやったりしているので、7回解きの有効性はとても同意できる。

戦略的な勉強法

著者が一番伝えたいことは、「努力をするんなら戦略的な勉強法でいこう」ということだなと思った。闇雲に頑張る、努力する、というのは、無駄な努力になってしまう可能性が高まり、なおかつ自分が疲弊してしまうし、卑屈になる（こんなに頑張ってるのに！と）。

戦略は攻略対象によって都度考える必要があるとは思う。なにしろ、締め切りはあるのか、難易度はどうなのかなど、考慮する点がそれぞれ違うからだ。とはいえ、戦略の1つに7回読み勉強法を加えるのは有効だと思う。時間をかけて勉強することになるとなおさらだ。

反復と網羅性

7回読みのいいところは、何度も読むことで頭に定着しやすいことと、とりあえず全部読むことで全体をなんとなくでも網羅できることである。試験の場合によく「ヤマを張る」ということがあったかと思うけれど、ヤマが外れたときのダメージは相当大きいので、リスクが高い。無視していいことは教科書には載ってないので、とりあえずでも全体的に掴んでおくことは、後々に効いてくるのだという。 たしかに、予想問題集をいくらこなしても本試験だと見たこともないような問題は出てくるものだ。

一番心に響いた言葉

とても勉強になった本書であるが、最後に、一番心に響いた言葉を載せておく。

「できないのがいけないのではなく、できないままでいることがいけない」

積ん読が増えているので、頑張って消化します！

PDCAは試行錯誤のフレームワークだと認識した

読書

自分を劇的に成長させる! PDCAノート

自分を劇的に成長させる! PDCAノート

本屋で表紙を見てなんか気になったので買って読んでみた。

読む目的

日々の業務や生活の改善は行われているものの、なんか漠然と進んでいる感を感じられないので、参考になるメソッドはないかなと思ったため。あと、ノートにToDoを書いてそれらを倒していくという方式をとっているのだが、振り返りがあまり行えていないかも…と思い、それにPDCAを取り入れたかった。

なぜPDCAが回らないのか？

これは以前に読んだ本にも書いてあったことだが、行動レベルまで落とし込めてないからだ。

patorash.hatenablog.com

本を読んだにもかかわらず、行動レベルに落とし込むのがまだ苦手である。結果がすぐに見えるものに関しては、動けるのだが。ということは、結果がすぐに見えるようにすれば、行動レベルにまで落とし込めるのではないか？という考えに至った。

ふと、OSS-DB Silverを取得したときのことを振り返ると、Study Plusを使って、参考書の進捗を管理していた。あれも勉強時間の見える化と、本を読むという作業の進捗管理なわけで、前に進んでいるというポジティブ思考になれたので、参考書を読み進めるのにはStudy Plusを使うのがよさそうだ。

大事なのは「フレーム」

学校の授業もフレームなのだが、型に嵌めると習慣化しやすい。逆にフレームがないと、何をしたらいいかわからなくて何もできずに過ごしてしまう、ということになりがちであるということが書かれていた。無意識で動けることはだいたいフレームの力。通勤通学などもそう。考えなくても動ける「いつも通り」にすることで省エネルギーになり、決断疲れを起こさなくて済むようになる。

そして、「PDCAノートは、PDCAを回すためのフレームである」と書かれている。確かにPDCAと思っても、とっかかりがないのでズルズルいくと思うので、フレーム化してあると、書くかーという気持ちになりやすいのではないか。

色々なPDCAノート

PDCAノートは

  • 毎日のPDCAノート
  • プロジェクトPDCAノート
  • 商談PDCAノート

など、色んなパターンに落とし込んで使うことができる。

当面は毎日のPDCAノートとプロジェクトPDCAノートを使ってみようかと思う（商談は自分の場合は少ないので）

PDCAは速く回せ

「振り返りの回数が多ければ多いほど、間違ったゴールに着く可能性は低くなる」という趣旨のことが書いてあった。そして、「軌道修正のコストも少なくて済む」とも。手戻りが少なくて済むというのは、やる気を持続するためにもよさそうに思える。どこかでコストが閾値を超えると、途端に面倒臭くなって、やりたくなくなることって多い。

毎日のPDCAノートっていっても、別に改善案が出ない日もあるだろうけれど、ログとして残しておくことで、後日役に立つこともある。

気づき

タイトル通りなのだけれど、PDCAは試行錯誤のフレームワークであるという認識が浅かった。もっとカジュアルに「計画して実行して振り返って改善！」でいいのだけれど、計画をちゃんとしないとと思い過ぎていたのかもしれない。

あと、読んでいる途中で「これってアジャイルだよな」と思った。1日というイテレーションを回して振り返って改善するわけで、アジャイルはPDCAなんやなという当たり前のことに気づいた。

本には、PDCAノートを続けるためのメソッドや、GTDとの組み合わせなども紹介されていたり、人生のビジョンの考え方についても言及されており、子供との接し方や仕事のやり方などのほうは特に「わかる〜」という気持ちになった。

とりあえずToDoを書いていくのは、PDCAノートに変えてみることにする。

RailsアプリにreCAPTCHAを導入した

Ruby on Rails

担当アプリのお問い合わせページが中国からのスパム投稿を行われるようになってしまったので、急遽IP制限を追加して一時的に凌ぐことにしたのですが、完全な対策ではないのでreCAPTCHAを導入することにしました。

reCAPTCHAとは？

reCAPTCHAは、Googleが提供している「人間かロボットか」を判断する仕組みです。最近よく見かけるようになったと思いますが、「私はロボットではありません」というチェックボックスにチェックを入れるだけでいいというやつです。

developers.google.com

人間かロボットかの判断をGoogle側に依存するようになるのですが、まぁ問題ないかと思います。

Railsアプリでの導入について

RailsアプリでのreCAPTCHAの導入は簡単です。recaptchaというgemがあります。

github.com

reCAPTCHAのキーの発行

まずは以下のリンクからGet reCAPTCHAボタンを押して、reCAPTCHAのキーを取得します。

www.google.com

次に、

  1. ラベルにわかりやすいものを設定します。（ドメイン名、何のページか等）
  2. reCAPTCHAのタイプを選択します。今回はreCAPTCHGA v2。
  3. ドメインを設定します。サブドメインも設定することと、開発環境で試す場合はlocalhostや127.0.0.1なども登録しておいたほうがいいでしょう。
  4. 利用規約に同意して登録します。

f:id:patorash:20180403163946p:plain

キーが発行されるので、それをRailsアプリに登録していきます。

Railsアプリでの設定

recaptchaのサイトに導入の仕方は書いてありますが、一応書きます。

gem recaptchaのインストール

Gemfileに以下を追加します。

gem 'recaptcha', require: "recaptcha/rails"

そして、bundle installを実行します。

環境変数の設定

環境変数にreCAPTCHAで発行されたキー類を登録しておきます。 開発環境でdotenvを使っている場合は、以下のようにしましょう。

RECAPTCHA_SITE_KEY = '発行されたサイトキーをここに設定'
RECAPTCHA_SECRET_KEY = '発行されたシークレットキーをここに設定'
ViewにreCAPTCHAを表示する

あとは、Viewのformタグの内側にreCAPTCHA用のタグを出力します。人として認証されたらJavaScriptのコールバック関数を呼ぶことができますので、それが成立したら送信ボタンを有効にする、なども可能です。コードはslimで書いていますのであしからず。

= form_for @foo do |f|
  # 他のタグ
  = recaptcha_tags callback: 'successRecaptchaVerified'
  # 他のタグ
Controller側でreCAPTCHAのチェック

最後に、Controllerでチェックします。

def create
  @foo = Foo.new(foo_params)
  if verify_recaptcha(model: @foo) && @foo.save
    redirect_to @foo
  else
    render 'new'
  end
end

これで完了です。が、みなさんテストを書いていますよね？その場合は追加が必要です。

テストでreCAPTCHAの認証をパスする

gem recaptchaはテストの際はverify_recaptchaの結果を常にtrueを返すようになっていますので、引数に環境を渡す必要があります。env: Rails.envを追加してください。

def create
  @foo = Foo.new(foo_params)
  if verify_recaptcha(model: @foo, env: Rails.env) && @foo.save
    redirect_to @foo
  else
    render 'new'
  end
end

これでOKです。

まとめ

reCAPTCHAの導入は比較的簡単で助かりました。ただ、ローカルで何度も実験しようとすると、すぐにロボット扱いされてしまって困りました。ブラウザを変えるなどして凌いだのですが、いい方法はないものか…。どなたかご存知であれば教えてください。

webpackerでfont-awesome5を使ってみた。

Ruby on Rails

Rails5.1.5で趣味アプリを作っていってるんですが、css frameworkはbootstrap4を使っているのですが、bootstrap4からはどうもアイコンフォントは別で準備されることになったっぽいので、安定のfont-awesome5を使うかーと思ったので入れてみました。

それにしても未だにNode.jsをちゃんと勉強したことがないのでrequireとimportとかがごっちゃになって参ります。まぁ自分のせいなんですが。

font-awesomeは5でどうなったのか？

Get Started | Font Awesome

Get startのページを確認したところ、JS版とCSS版とAdvanced Optionsと色々あります。本家のオススメはJS版のようです。Advanced Optionsは、npmでのインストールするパターンとか、ReactやVueで使うパターンのやつみたいです。

CSS版は、古いブラウザに対応するときはこちら、みたいにやや煽った表現になってますね…。

なんでJS版のほうがいいかは、CSSだと環境によってはフォントの読み込みのパスで悩むことが多かったと思うのですが、JS版だとsvgに変換して出力するので、そういう悩みから解放されるのとファイルサイズが小さくなるとか（ちゃんと調べてないけど）。あと、自分はやったことないのですが、Node.jsを使ったサーバサイドレンダリングが可能になるからとか。

今回はyarnでインストールして使ってみたかったので、そうしました。

font-awesomeをインストール

今回は無料版のみをインストールしました。 yarnでfont-awesome系を色々入れていきます。

yarn add @fortawesome/fontawesome @fortawesome/fontawesome-free-solid @fortawesome/fontawesome-free-regular @fortawesome/fontawesome-free-brands

webpackerで使う

webpacker経由で使うには、app/javascript/packs/application.jsにて読み込むようにします。

import fontawesome from '@fortawesome/fontawesome'
import faSolid from '@fortawesome/fontawesome-free-solid'
import faRegular from '@fortawesome/fontawesome-free-regular'
import faBrands from '@fortawesome/fontawesome-free-brands'

fontawesome.library.add(faSolid, faRegular, faBrands)

fontawesome.dom.i2svg()

yarnでインストールするときには、ググったやつをコピペして入れたので全然気づかなかったのですが、jsファイルにimportを書くときに、@fontawesome/fontawesomeと書いていたのですが、railsを起動してアクセスしてみたら読み込めないって怒られてしまって結構悩んでいたのですが、@fortawesome/fontawesomeなんですね。え、nじゃなくてr！？まじで？？？と思って本家のサイトを参照しにいったのですが、たしかに@fortawesome/fontawesomeと書いてありました。

fontawesome.dom.i2svg()メソッドで、iタグにつけたクラス名からsvgに変換してアイコンを表示してくれますので、我々はいつも通り<i class="fa fa-user"></i>みたいに使っていればいいようです。

一応、サンプルのhtml(erb)。

<h1><i class="fa fa-user"></i><%= user.name %></h1>

結果はこちら。

f:id:patorash:20180309015959p:plain

出ました！

turbolinksも併せて使う

turbolinksで使う場合は、turbolinks:loadイベントで呼び出せばいいかと思います。

import fontawesome from '@fortawesome/fontawesome'
import faSolid from '@fortawesome/fontawesome-free-solid'
import faRegular from '@fortawesome/fontawesome-free-regular'
import faBrands from '@fortawesome/fontawesome-free-brands'

fontawesome.library.add(faSolid, faRegular, faBrands)

document.addEventListener('turbolinks:load', () => {
  fontawesome.dom.i2svg()
})