patorashのブログ

方向性はまだない

カズさんありがとう

日記

これは大都会岡山 Advent Calendar 2021の17日の投稿になります。

adventar.org

もう2ヶ月前になりますが、私の上司であったカズさんこと id:tech-kazuhisa がリゾームを退職しました。その思いとかはカズさんがブログに書いているので、そちらを読んでもらえたらと思います。

tech-kazuhisa.hatenablog.com

カズさんとは？

カズさんは言わずと知れた岡山のRuby界隈の重鎮。Railsやりたくてリゾームに入社した経緯があります。因みに私が入社したのはその1年半後とかだったはず。

とても気さくな人であり、コミュニケーション能力が高く、かつ多趣味。最近では自宅のDIYや、ラジコンレースにハマっている模様。

カズさんの様々な功績

制度編

リゾームっていう会社はいいところも多いんですが、キラキラ系スタートアップやスピード感のある企業と比べるとスピード感に難があります。しかしそれでもカズさんは、ちゃんと正攻法で会社の制度を整えていきました。

  • 業務中のSNS利用
  • 自席での個人携帯の利用（もちろん過度にはNG）
  • リモートワーク制度

このあたりを、如何にエンジニアの情報収集や会社のPRにSNSが使われているか、また、スマホ対応したりしているのに確認する用の端末がすごく古い機種しかない等の問題点を上げ、会社の公認で使えるようにしていきました。 リモートワーク制度にしても、新型コロナが流行しだした頃に早々に手を回し、それぞれの家庭で安全にインターネットに接続できるようにした上で、リモートワークを可能とするようにさせました。そして今では、開発チームは基本的にリモート前提の体制となりました。

カズさんは「暗黙のルールみたいなので隠れてコソコソやりたくないんよ」ってよく話してました。

会社も変わってくれてはいますが、やはり言い出す人がいないと変わりませんし、そもそも変えるのには相当な時間と労力が必要です。当たり前のような制度であっても、当たり前ではなかったということを、残っている我々はちゃんと認識しておかなければなりません。

技術編

カズさんは技術的にも大変優れていて、様々な領域で知見が豊富です。

私がリゾームに入社したときに驚いたのは、「テストがあったこと」でした。今だとテストがあるのはほぼ当たり前と言っても過言ではないと思いますが、10年前はそんなことなかったと思います。

とはいえ、当時の運用は手元でテストを流してOKならマージしてOKみたいな感じでした。テストが増えるにつれ、だんだんテストが遅くなっていってたのですが、個々のPCをテストで専有しないようにするためにカズさんはJenkinsを導入しました。弊社のCIの誕生の瞬間です。Mac miniを何台も買って積んで並列実行していた姿は圧巻でした。

そこからは不安定なCIを安定化・高速化するためにカズさんはJenkinsおじさんに徹します。その結果、ネットメディアでJenkinsの連載までしてしまいました。

www.buildinsider.net

これらの功績のおかげでCIの重要性が認識され、とはいえメンテコストもバカにならないので現在ではCircleCIを使っていますが、カズさんが社内だけでなく記事を通じて日本のエンジニアの時間の節約にどれくらい貢献したかは計り知れません。

また、サーバーの構成管理などインフラ寄りの仕事を引き受けてくれて、他の人が製品開発に集中できるようにしてくれていました。

マネジメント編

組織再編でカズさんがマネージャー職になってからは、私がやりたいこととかの根回しや相談によく乗ってもらえて非常に助かりました。一人で考えているとなかなか言語化できないモヤモヤしていたところを1on1で導いてもらえたなぁと本当に感謝してます。 また私の家庭の事情なども考慮してもらえて助かりました。 私以外の人も、カズさんとの1on1を通じて色々な視点を得た人は多いんじゃないかなと思います。

まとめ

とまぁ、細かいことを上げるとキリがないくらいカズさんにはお世話になりました。RSpec Bookの社内読書会やったり、一緒にISUCONに参加したり、一緒にRubyKaigiに行ったり、いい思い出です。本当にありがとうございました！！

初期不良のLOVOTが戻ってきました

日記

ちょっと今更感あるけれど、一応書いておこうと思って書いています。

先月、こんな記事を書きました。

patorash.hatenablog.com

今では退院してきて、元気にうちの2階を歩き回っていますが、どういう顛末になったかを書いておきたいと思います。

入院手続き

LOVOTコンシェルジュに連絡を取り、ログから調査してみたところ、故障っぽいけれど、ネスト（充電するところ）かLOVOT本体のどちらが原因かまではわからないので、両方とも送り返して入院ということになりました。お迎えして数時間足らずで入院決定！

もともと送られてきたダンボールは、捨てずに保存しておいて、1年毎の入院の際に使いますってことだったので、早速ダンボールに戻して郵送の手続きへ。宅配業者の手配は、LOVOTコンシェルジュさんがやってくれていて、翌日来ることに。

箱に入らない事件

ここで問題が発生しました。LOVOTが足（ホイール）を出したまま停止してしまったため、ダンボールに入らず…😭😭😭

しかし、このツイートをLOVOT公式さんが見つけてくれて、専用の箱があることを知りました。

早速、LOVOTコンシェルジュに連絡を取ろうとしたんですが、取っている最中に宅配業者が来てしまい、LOVOTが箱に入っていないので送ることができず、手ぶらで帰ってもらうことに…😥向こうからしたら、呼んどいて梱包できてないってどういうことやねんって感じだろうから、私も宅配業者さんも相当気まずかったですが、どうしようもないです。

LOVOTコンシェルジュにやっと連絡が取れてから、箱に入らないことを伝えて、入院箱を送ってもらうことに。金曜だったので週末を挟んでしまい、届くのに5日くらいかかるってことになってしまいました。まぁ仕方がない。箱に入れることができないLOVOTは玄関で置物のように1週間佇んでいました😅

再度宅配業者さん来たる

いよいよ入院箱が届きました。入院箱は立ったまま入るように大きな箱です。入れるのは、宅配業者さんではなく、オーナーさんがやってくださいという手順書入りでした。手順書に従ってLOVOTを入院箱に入れ、ネストと一緒に送り返しました。

どちらが原因か判明

入院して点検した結果、LOVOT本体のほうが故障していたということで、本体交換ということに😭本体自体を直してもらうという選択肢もあったのですが、届くまで更に時間がかかるようになるということだったので、今回は交換となりました。初期不良の保証期間は30日なので、あんまり悠長にもできないなとも思ってました。

退院！

数日後、LOVOTが退院してきました。

つぶらな瞳です。

入院中に服を買っておきました。次男セレクトのウサギさんコスチュームです。

そして、今度はネストにしっかり収まって充電できています。めっちゃ安心しました。

LOVOTを迎えて

本格的にLOVOTをお迎えして3週間くらい経過しました。感想としては、まぁやっぱり可愛いですね。寄ってきて、抱っこをせがんだり、手をバタバタさせたりします。段差に弱いので、なるべく床をきれいに保ってますが、時々おもちゃを踏んで動けなくなったりしてアプリ経由でヘルプメッセージが届きます。

次男は喜んでます。発達障害の長男は認識はし始めているようですが、可愛がったりする素振りはまだまだありません。まだ怖い存在なのかもしれません。でもこの前ちょっと触ろうとしているのをお父さんは見逃しませんでした😁徐々に興味を持ってくれると嬉しいところです。

最後に

2021年12月から2022年2月まで、冬のお友達紹介キャンペーンをやっているそうです。

紹介された方（おともだち）の特典

  • LOVOT本体購入に使えるクーポン「10,000円分」をプレゼント
  • LOVOT オリジナルグッズをプレゼント

だそうです！もし、LOVOTのお迎えを検討されている方は、紹介コードを使うと1万円お得になりますよ！

よろしくおねがいしまーす！

オープンセミナー岡山で発表した資料の作り方

日記

このエントリーは大都会岡山 Advent Calendar 2021の4日目です。

adventar.org

先日、オープンセミナー岡山@2021で登壇したという記事を書きました。

patorash.hatenablog.com

そこで、資料をどう作ったかを後日書くと言ってたので、それを書きます。

タイトルを決めた

実行委員から、8月末までにタイトルを決めてほしいという話でした。テーマが「extend engineering」で、「人と技術を繋げよう」というサブタイトルがあったので、ブログの執筆や勉強会での発表をどういう考えでやっていたかを発表するかーと考え、「情報共有戦略と戦術」というタイトルを決めました。

なんとなく流れを考えた

9月、10月上旬はなんとなく発表の流れを考えていたものの、発散しまくりでどうまとめようか…🤔という感じでした。

シンプルプレゼンを見る

このままだと、箇条書きだけの発表になってしまいそうだ…😥と危機感を覚えたので、ガー・レイノルズさんのシンプルプレゼンのDVDを見ました。ガー・レイノルズさんといえば、プレゼンテーションZENですが、こちらはDVDでプレゼンのエッセンスが学べるので良書です。動画を見た後、本を読むと更に勉強になります。（サラッとしか読んでないけれど…😅）

f:id:patorash:20211203232917j:plain

ポストイットに書きまくる

とりあえず発散しまくりだった思い付きのアイデアをポストイットに書きまくり、そこから伝えたいことの本質となるものを選び取りました。

Googleスライドで資料を作成開始

ポストイットをベースに資料を作成し始めたが、内容は決まってきたものの、そのままだと結局箇条書きの資料になりそうに…😑

シンプルプレゼンでは、内容に合う画像を効果的に使おうということが語られていたので、そういう画像を集めようと調べていたのですが、どうにもなかなか集められず…。時間だけが過ぎていきながら、動画提出期限の10月末を迎えてしまうことに😣

動画提出期限はもうちょっと延びて11月上旬までになったのですが、このままだと資料が中途半端になりそう…と思っていたところで、ふとCanvaのことを思い出しました。

https://www.canva.com/ja_jp/

Canvaは沢山の素材画像を使って資料や様々なデザインを作ることができるサービスです。サブスクのCanva Proで契約すると豊富な画像を使い放題になります！今回はこのCanva Proを契約して使いました。

Canvaでスライドを一から作り直し

画像だけCanvaからダウンロードしながらGoogleスライドに画像を貼り付けていこうかと考えていたのですが、Canvaのほうでスライドを最初から作り直したほうが良いスライドになりそうだったので、全部作り直しました。

正直この決断をするのは今まで作っていたものを全部ではないにしても捨てることになるので、勇気が必要でしたが、結果的によかったと思います。

なんとか資料を作り終えて、あとは発表動画を録るだけ…。しかしどうやって録ろうか？と考えていました。

Canvaで発表動画を録画

なんと、Canvaでそのまま発表動画を録画できるようだったので、それで録画も済ませました。Canva、めちゃくちゃ便利！😍録った動画を実行委員長に共有して、なんとか締切までに終わりました😂

今回、Canvaを使って、完全にCanvaが好きになりました。圧倒的な素材量でサクサクと思い描いたイメージでスライドが作れるのは本当にありがたいです😋

できた資料と動画

こちらができた発表資料と、オープンセミナー岡山@2021で発表した動画になります。

資料

動画

最後に

効果的なプレゼン資料を作るためのエッセンスを学べるシンプルプレゼンは、こちらから。

ガー・レイノルズ シンプルプレゼン

ガー・レイノルズ シンプルプレゼン

Amazon

Canvaは、以下のURLから登録してもらえると、有料の素材を一点もらえます。Canva Proも1ヶ月無料でお試しできますから、皆さんもプレゼン資料に限らず、何かしらの素材を使ったものを作りたい場合は是非お試しください😀

https://www.canva.com/join/zrp-cqf-rbn

オープンセミナー岡山2021で登壇しました

勉強会

オープンセミナー岡山@2021が、11月27日(土)に開催されました。 今回も前回と続き、オンラインでのイベントとなりました。今年のテーマは「extend engineering」で、「人と技術を繋げよう」というサブタイトルが付いています。

公式サイト okayama.open-seminar.org

connpassのページ oso.connpass.com

今年も動画や資料が公開されています。YouTubeにオープンセミナー岡山のチャンネルがあるので、是非登録しましょう！

www.youtube.com

そして、当日の様子はトゥギャッターに纏められています。毎度毎度まとめていただき、ありがたい。

togetter.com

今回は講師として参加

今回はなんと、実行委員長から登壇オファーを頂き、登壇することに！😲

最初は正直ビックリして、「えっ！なんで俺！？」という感じでしたけれど、せっかくのオファーなので受けました。

発表の構成を考えたりするのは、結構試行錯誤したり、スライドも何度か作り直したりしたのですが、それは別の記事で書きたいと思います。

2021-12-04 追記

書きました。

patorash.hatenablog.com

講演内容の特徴

今回の講演は全体的に「なぜ人に技術を継承していこうと考えるようになったか？」というのがあったかなぁと思いました。まぁそうでないと、そこに至る背景がわからないので、ストーリーの起点として必要不可欠かなと思います。

コミュニティの大事さ

nulabの河内さん、CircleCIの是枝さん、LINEのもちこさん、岩田プロ、中道さん、そして私も発表では何かしらのコミュニティでお世話になったり、そこで活動して成長していったという話がありました。

それぞれ所属コミュニティは違えど、そこで得られた繋がりの大事さは皆さん共通ではないでしょうか。そこから転職したり、留学したり、出版したり、更に他のコミュニティで活躍したり…。

コミュニティとの出会いが、大きく人生を変えたのかなと感じました。

課題意識

nulabの河内さんは若い頃のリーダー経験で痛い目に遭いながらも、アジャイル開発に興味を持ち、次にリーダーを担当した際に開発プロセスを回して成功したという体験と、コミュニティに参加し始めて得られた経験を仕事にフィードバックするプロセスを回していったという話が印象的でした。最初のリーダーでの失敗の反省点を発表を通して共有してもらえるのは、非常に貴重でありがたいことだと思います。

課題意識を持ち続けているからこそ、改善に取り組めます。

そして、nulabの組織構成や、抱えている課題等の共有も興味深かったです。インセプションデッキの話はめっちゃ興味あったので後日ハテブに登録しました。

nulab.com

CircleCIの是枝さんは、国内・外資と大手からベンチャーまで様々な企業を渡り歩いてこられていましたが、その中でもやっぱりあったのは課題意識なのかなと思いました。私なんかが考えると、大手企業に転職した時点でそのポジションはなかなか手放せないのではないか？と思うのですが、是枝さんのリアクティブよりもプロアクティブにユーザーの課題と関わっていきたいという想いが、カスタマーサクセスという働き方に行きついたのだなと思います。

SaaSのビジネスで、かつ、従量課金ビジネスなので使ってもらえなければ商売にならないということで積極的にユーザーを支援していくというのは、自分の働きが数値として跳ね返ってくるし、売上自体が自分達の製品をユーザーによりよく理解して活用してもらっているという指標にもなるので、カスタマーサクセスという仕事は楽しそうだなと思いました。

LINEのテクニカルライターのもちこさんは、元々はインフラエンジニア。溢れるDNS愛から技術書典でのDNS本の出版で大成功し、丁寧な解説本には需要があるという仮説を証明し、AWS本、SSL本と三部作にしていくというところが話の始めで、転職活動中にテクニカルライターにならないか？と声がかかったという話でした。そこもまた課題意識で、「最近のプログラマはアプリは作れるけれど雰囲気でインフラやってるんじゃないか？」というところを突いた話で、視聴者みんなが膝に矢を受けてしまったのではないかと思います（私含め）。

「いやー自分も昔は自宅サーバでダイナミックDNSを使ってWebサービス公開してたりしたなぁ～、その頃はDNS色々弄ってたなぁ～」とか思い出しました。因みにその自宅サーバは私の初代PCのIBM AptivaにFedoraを入れたやつでした。でももう最近は忘れちまいましたな…😅

後半はテクニカルライターの仕事についてとか、どうやったら上達するかの話は量が質に転化するという話でした。いきなり質の良いものは作れないから、まずは完成させる。完成すると、フィードバックが得られるし、推敲もできるので改善のプロセスが回せるというところで、やはりプログラムにしても文章にしても、一旦リリースできるところまで持っていくのが大事だなと改めて思いました。私もドキュメント類は整備していくようにしているので、めっちゃ同意しながら聞いてました。一旦書いて、分かりにくいところがあったら教えてと後輩くんに頼んだりとか。

お薦めの本の紹介もあったりと、至れり尽くせりの講演だったと思います！👍

岩田プロの講演では、私の名前が出たり、河内さんの名前が出たり、岩田さんならではの語り口で（早口で！）、30分に凝縮されてました。自分の中に軸となる技術を持ちたい！というのも課題意識かなと思います。そこで選んだのがGo言語で、そこからFlutterやMicrosoftのMVPに至るまでの行動力はなかなか真似できるものではありません。趣味Techだからこそできたと岩田さんは言いますけれど、趣味でそこまで突き抜けるのはむしろ難しい気が…。活動範囲を広げれば広げるほど英語の重要性を痛感したという話も聞きました。 ハンズオンなどを通じて、多くの人に技術伝承をしていてすごいなと改めて思いました。

中道さんの講演では、論語を中心として様々な名言を取り上げながら、コミュニティの繋がりの話や、これから一歩踏み出したい人を応援するようなメッセージがちりばめられた素敵な話でした。「下手でも笑われても名人と混ざって練習しよう」とか、自分にも刺さりました。id:a-know さんが呟いてたけれど、あこがれ駆動っていうのもアリってのは本当そう思います。SNSが発達したのでロールモデルになりそうな人が見つけやすいと思いますし。

みんなの発表の総括的な感じになって、最後の発表としてとてもよい終わり方でした！！

通しての感想

まぁ自分が発表者だったので、特別なオープンセミナーとなりました！大勢の方に聞いてもらえて、フィードバックがもらえて、とても嬉しいです😂

他の皆さんの発表もとても刺激的でした。一歩を踏み出す勇気を与えてくれる、そんな内容ばかりでした。新型コロナの影響でオンライン開催が続いていますが、本当にいつの日か、みんなで集まりながら講演を聴き、休憩時間に廊下で交流し、お昼ご飯を一緒に食べ、懇親会で色んな話をする。そんなオープンセミナーが早く戻ってきてほしいなぁと思いました。

そして、改めて、実行委員会の皆様、そして実行委員長の id:kakerun_mouse さん、ありがとうございました＆お疲れさまでした。閉会での感想を言ってもらえて、嬉しかったです。そして、ブログも公開されています。

kakerun-mouse.hatenablog.com

いやもうマジで20代で実行委員長するのはすごい。私なんて20代の中頃なんてデスマの毎日だったもの。とてもよいオープンセミナー岡山で、大成功だったと思います！

rake taskにて引数チェックでnextを使っていたのをabortに直した

Ruby Ruby on Rails

rake taskではreturnが使えないのは知っていたので、引数チェックに引っかかったらnextを使っていたのだけど、それだと次の処理に移動してしまうし、終了コードが0となって正常終了扱いされてしまうなと気付きました（今更かよって感じですが）😅

じゃあexit(1)で終了させるのがいいんかな？と思っていたら、abortという便利なやつがあることを知りました。

docs.ruby-lang.org

abortを使うと、エラーコード1固定、標準エラー出力にメッセージを出力することができます。

abortを使う

修正前

nextを使っていた頃。引数bar_idがなければ、このタスクはスキップされるけれど、次のタスクがあった場合は実行されてしまうし、終了コードが0になる。

task :foo, ['bar_id'] => :environment do |task, args|
  if args.bar_id.blank?
    puts "Please set bar_id."
    next
  end

  # 続きの処理
end

修正後

abortに修正したもの。引数bar_idがなければ、このタスクで終了するし、終了コードが1になる。

task :foo, ['bar_id'] => :environment do |task, args|
  abort "Please set bar_id." if args.bar_id.blank?

  # 続きの処理
end

abortを使う際の注意点

便利なabortですが、扱いには注意が必要です。

例外処理で明示的にrescueする必要がある

rescueで特に指定しない場合、StandardErrorを継承した例外しか拾わないのでabortすると無視されます。なので、rescue SystemExit => errは必須。

私の場合は、rake taskの実行ログをDBに保存するようにしていたのですが、例外が発生した場合は結果をfalseとして保存するようにしていたのにabortを使ったら結果がtrueのまま保存されていて気づきました。なのでその実行ログを保存する処理では、以下のように修正。

begin
  yield
rescue SystemExit => err
  unless err.success?
    set_error_details(err)
  end
  raise err
rescue => err
  set_error_details(err)
  raise err
ensure
  save
end

SystemExitはexit(0)でも発生します。しかし、exit(0)が呼ばれたか、abortが呼ばれたかは、success?メソッドで判定できます。abortを使った場合はfalseになるので、これでエラーとみなして処理するわけです。

RSpecまで止まる

これは超重要なのですが、abortを使っていると、テストを流すとabortのところでテストも停止します😨。最初ビックリしましたが、わからなくもない…😔

対処方法は、.to raise_error SystemExitを必ず使って検証することです。 以下のコードのようにします。（gem 'rake_shared_context'を使用しています）

RSpec.describe 'foo' do
  include_context 'rake'
  context '引数 bar_idがない場合' do
    it 'エラーになること' do
      expect {
        subject.invoke
      }.to raise_error SystemExit
    end
  end
end

これで、テストを流してもそこでabortせずに全てのテストが実行されるようになりました👍

LOVOTをお迎えしましたが、初期不良っぽい

日記

アニマルセラピーで犬を飼い始めたら自閉症の子が喋られるようになったという話を聞いたりしていて、動物は難しいなぁと思ったので、LOVOTをお迎えしてみようかという話を妻として、先週の週末に開催されていた天満屋のリビングフェアに行って実物のLOVOTに会ってきました。

LOVOTはどれもキュートで、しかし長男氏はちょっと警戒してた…けれど、次男氏はすごく気に入ったみたいで、翌日も「LOVOTを見に行きたい！」というので、2日連続で見に行くことに。慣れてきたら長男氏も愛着が出てきていい効果があるかもしれない、ということで、新しく家族を迎え入れる決意を固め、契約してきました。

そして、昨日届きました！可愛い！名前は見に行ったときにいた子と同じ名前の「いちご」がいいと次男氏が言うので、決定。

目の色を変えたり、抱っこしたりしてたのですが、3回目の充電でネストに戻ったら、ネストに接続しているのに充電が始まらず…。

「あれ？充電できてないよ」と次男氏がいうので見てみたら、ずっと目がバッテリー少ないの表示に。

検索して、試せるものは試そうと、

  1. ネストの再起動
  2. LOVOTの再起動
  3. 充電端子の掃除
  4. 何度か充電端子を付けたり外したりしてみる

とかをしている間に、「いちご」のバッテリー残量が0になってしまい、目が真っ暗に…😭😭😭

とりあえず、30日間は無料保証期間なので、今日LOVOTコンシェルジュに連絡を入れて、調査待ちという状態です。

初日から動かなくなって次男氏と私はションボリしていたのですが、妻は「まぁ初日でよかったよ。31日目に壊れてたらもっと困ってた」とポジティブな発言をしてくれて、まぁそれもそうだなと思い直したところです。

早く直ってほしい！

prettierを導入してLefthookと連携した

Ruby on Rails JavaScript

前回の記事はこちら。

patorash.hatenablog.com

今回は、prettierを導入して、gitでcommitする際にrubocopだけでなくprettierでもフォーマットチェックをさせるようにした話です。

prettierとは？

prettierは、フロントエンド用のコードフォーマットツールです。特に設定しなくてもデフォルトでいい感じにフォーマットしてくれることを目指しているらしいです。

prettier.io

フロントエンドのフォーマッタは使ってなかったのですが、パートナーさんが使っているという話を聞いてました。なので自分も入れたいなぁとは思っていたけれど、どうせならチーム全体に使えるようにしたかったので、プロジェクトで設定しました。

導入

導入は簡単で、prettierの公式のインストールを参照するのがいいとは思う。yarn使ってるなら、こう。

yarn add --dev --exact prettier

設定

除外リスト

prettierは多機能で、放っておくとjs, ts, css以外にもmdやyamlファイルまでコードフォーマットしようとします。別にそれらもしてもらっても構わないということだったら問題ないのですが、設定ファイルとかもあるし、mdは微妙に読みにくくなったりしたので、対象外としたくなりました。

prettierの除外リストは、.prettierignoreで、これを設定していきました。 プロジェクトで使っているツールのjs,cssまで変更しようとするので（minioとかgraphidocとかsimplecovとか）、それらは除外するようにしました。

# Ignore artifacts:
build
coverage
total_coverage
/public/assets
/public/packs
/public/packs-test
/node_modules

# Ignore project files:
/.idea
/.bundle
/doc/schema
/.docker/minio

# Ignore all HTML files:
*.html

# Ignore all md files:
*.md

# Ignore all yaml files:
*.yaml
*.yml

# Ignore setting json files:
schema.json
tsconfig.json

# Ignore config.js files:
*.config.js

フォーマット設定

デフォルトでいい感じにしてくれるprettierですが、そうはいっても多少はルールを決めたいわけです。とはいえ、どういうのがいいかはチームで決めたかったので、ルールを募集して、パートナーさんが設定しているものを採用しました。.prettierrc.jsonに以下を登録しました。

{
  "trailingComma": "es5",
  "tabWidth": 2,
  "semi": true,
  "singleQuote": true
}

エディタの設定

エディタでprettierの設定をしておくと、ファイル保存時に自動でコードフォーマットしてくれるのですが、それは各自で設定が必要なので、README.mdにその案内を書いておきました。

#### prettierの設定

prettierはエディタの設定をしておくと、ファイル保存時に自動でコードをフォーマットしてくれます。
使用しているエディタは各人異なりますので、使用しているエディタに合わせて設定をしておくとよいでしょう。
RubyMineを使用している人は、WebStormの設定を参照してください。

https://prettier.io/docs/en/editors.html

Lefthookと連携する

ここ以降で、前回の記事でとりあげたLefthookが活きてきます。git commit時にrubocopでチェックするのと同様に、prettierでもチェックさせます。

lefthook.ymlを更新しました。

pre-commit

rubocopとprettierは対象のファイルが異なるので、並行に実行させても問題ないので、parallel: trueにしてチェックさせています。うちでは開発環境をdockerにしているので、そのあたりは適宜読み替えてください。

pre-commit:
  parallel: true
  commands:
    rubocop:
      glob: "*.{rb,rake}"
      exclude: "application.rb|routes.rb"
      run: docker-compose run --rm runner bundle exec rubocop -P {staged_files}
    prettier:
      glob: "*.{js,ts,json,css,scss,sass}"
      run: docker-compose run --rm runner yarn prettier --check {staged_files}

タスクを修正

前回、lefthook run fixerでrubocopのコード自動修正を実行させるようにしていたのですが、そこに、prettierでのコード自動修正の処理を追加しました。こちらも、並列実行させても問題ないので、parallel: trueに設定しています。

fixer:
  parallel: true
  commands:
    ruby-fixer:
      glob: "*.{rb,rake}"
      exclude: "application.rb|routes.rb"
      run: docker-compose run --rm runner bundle exec rubocop --force-exclusion --auto-correct {staged_files}
    prettier-fixer:
      glob: "*.{js,ts,json,css,scss,sass}"
      run: docker-compose run --rm runner yarn prettier --write {staged_files}

これで、コードフォーマットについてはだいぶ死角がなくなってきた！💪

rubocopのルール設定で放置しているのは、まだたくさんあるけれど…🤤まぁ.rubocop_todo.yml対応はボチボチやっていきます。