GitHub の新機能「Code review assignment」を使ってみた

この記事は マイナビ Advent Calendar 2019 8日目の記事となります.

前日は「チャットボットをもくもくして運用した1年間の軌跡」でした．このチャットボット，普段は結構クレイジーな発言が多いですが投げかけた言葉に対して的確に答えたり，盛り上げてくれるようなことをたまに言うので社内で結構人気です．一番スゲーと思ったシーンはこちら（内容は意味わからない感じですが笑笑）．

なので↑の記事も是非見てみてください🤖．

---

前置きはこの辺にして，今回は先日開催された「GitHubUniverse」で発表された「Code review assignment」という機能の使い方についてまとめようと思います．

この機能を設定すると，プルリクエストのコードレビューでチームメンバーからレビュアーを自動でアサインすることができるようになります．

github.blog

PRのコードレビューのアサインを自動で行えるようになります！アサインの方式はラウンドロビンとロードバランスの2つ。パブリックベータとして、すべてのOrganizationでお使いいただけます！ #GitHubUniverse pic.twitter.com/7NvXqcmCUN

— GitHub Japan (@GitHubJapan) 2019年11月13日

設定方法

公式のヘルプを見ながら設定していきます．

help.github.com

前提

「Teams」に設定する機能のため個人のリポジトリではなく，「Organizations」に所属しているリポジトリで設定できます．また，事前に Team を作成し「Code review assignment」を設定したいリポジトリに Team を追加する必要があります．

「Teams」の「Settings」で「Code review assignment」を設定する

「Teams」のページ（https://github.com/orgs/オーガニゼーション名/teams/リポジトリ名）にアクセスし，「Settings」を選択します．もし「Settings」が表示されない場合は権限が不足しているため管理者に自分のアカウントの権限を上げてもらうか，これから記載する内容を設定してもらうかを相談してみてください．

「Code review assignment」を選択します．

「Enable auto assignment」 にチェックを入れます．すると以下のように「How many team members should be assigned to review?」 （Teams のメンバー内でコードレビューにアサインする人数は何人に設定するか？）や「Routing algorithm」（アサインする時のアルゴリズム）などが表示されるため，設定します．

「Routing algorithm」は現在2つあります．1つ目の「Round robin」は各メンバーが今までアサインされたレビュー数に関係なく、チームメンバーが交互にアサインされるようにするアルゴリズムです．

2つ目の「Load balance」は各メンバーがアサインされたレビュー数に基づいてレビュアーを選択し，過去30日間で各メンバーがアサインされたレビュアー数が均等になるようにするアルゴリズムです．

他にもアサインの対象から除外するメンバーの設定やメンバーをアサインした時にチーム全体ではなく，アサインしたメンバーのみ通知するかどうかなどの設定があります．

今回は以下のように設定し，「Save Changes」を押して設定を保存します．

実際に使ってみる

さあ！実際に使ってみましょう！使い方は簡単で新規または既存のプルリクエストのページで「Reviewers」を選択し，「Code review assignment」を設定した Team を指定します．

※てっきりリポジトリに Team を設定すると「Reviewers」が指定されてないプルリクエストは自動でレビュアーをアサインをするものだと勘違いしていました😅

すると Team の中から1名のメンバーをレビュアーとしてアサインされました．これでもうレビュアーを誰にするか迷う必要は無くなりますね！！

まとめと所感

「Code review assignment」を使ってみました．設定で少し迷う（おそらく自分だけ...）ところはありましたが設定自体は簡単でした．

ちなみに業務では「Pull Panda」という GitHub Apps を使っています．GitHub が買収した企業のアプリで類似する機能がありますが，これからどんな差別化をしていくのか楽しみですね．

pullpanda.com

「GitHubUniverse」では他にも発表された機能があるので，利用可能になったタイミングで「良いな！！」って思った機能は使い方をまとめていこうと思います！！

マイナビ Tech Night #3 でチーム開発をする上でやってきたことについて話しました

この記事は，マイナビ Advent Calendar 2019 4日目の記事となります. 前日は「GCEインスタンスの起動/停止をローカルマシンと同期する」でした．ちょうど個人開発をやりたいと思っていて，課題だと思ったことを解決するヒントを貰えた記事でした．

---

先月「マイナビ Tech Night #3」でトーク枠で登壇しました．今年の1月から入社し，イベント当日までマイナビニュースでやってきたことを発表する内容となりました．

今回は登壇した資料についての補足や発表時にあまり話せていなかった内容を書いていこうと思います．

mynavi.connpass.com

登壇資料

プルリクエストの情報が GitHub 上に無い😨

マイナビニュースで開発をする時，マイナビ側のエンジニアは GitHub *1 ，開発ベンダー側のエンジニアは GitLab というように Git のホスティングサービスが分かれていました．

これにより開発ベンダー側のプルリクエスト（GitLab で言うマージリクエスト）の情報が見ることができず，実装の意図を追うのが大変でした．また開発ベンダー側がリリース前にどのような開発プロセスを経ているのかをマイナビ側で細かく把握できなかったのも課題でした．

やったこと

まずは Git のホスティングサービスをマイナビの GitHub に統合するところから始めました．今までは開発ベンダーへ開発依頼をする時は，Redmine で依頼をしていたため，Redmine から移行し，マイナビの GitHub で開発する上での issueやプルリクエストの使い方についてなど開発フローを再整備しました．

マイナビ側で開発フローの案を出し，開発ベンダー側へフィードバックを貰いながら進めていきました．

次に CI 環境の構築です．マイナビの GitHub を開発ベンダーのエンジニアも使うということはマイナビの CI を使うことになります．しかし他のチームと共用で CircleCI を利用していたため，タダでさえ契約コンテナ数が少ない状態から CI を利用するエンジニアが増えるということになり，CI の実行待ちが増えることが容易に想像できました．

CircleCI の場合，現在では「PERFORMANCE プラン」に変更すると従量課金制になり， CI の実行待ちを気にする必要が無くなりますが，当時はすぐに何とかしないといけない課題であったため，マイナビニュースでは AWS CodeBuild で CI 環境を構築することにしました．

その時の登壇についてまだ記事を書いていないため近々書こうと思います．

追記(2019/12/15)

こちらの記事で詳細を書きました．

bake0937.hatenablog.com

え！誰が今どの環境でデプロイしてるの？😕

検証環境へのデプロイやリリース作業をした後，Slack で開発メンバーへ報告していました．

しかし，手動で報告していることや報告する途中で割り込みのタスクが入ったことで結果的に報告ができず，他のメンバーの作業が止まることが何回か目立ちました．

やったこと

Capistrano をデプロイツールとして採用していたこともあり，「capistrano-releases-notification」でデプロイ時に Slack で通知し，「capistrano-github-releases」で該当のプルリクエストに自動でリリース報告のコメントと Releases と Tags を自動生成するようにしました．Releases と Tags はリリースノートとして機能するので便利です．

それぞれの gem の使い方については，過去に記事を投稿したのでもし興味があれば見てもらえたらと思います．

bake0937.hatenablog.com

bake0937.hatenablog.com

リニューアル時の流れで使っている Git-flow

当時は develop ブランチを親ブランチとして開発をしていました．しかし切り戻しがあった時の作業の煩わしさや Git-Flow を続ける理由も現状の開発では特に無かったため GitHub フローにした方が効率が良さそうという思いが強くなっていきました．

やったこと

GitHub フローに変更しました．作業自体は develop ブランチと master ブランチに差分が無いことを確認した後に develop ブランチを削除するだけです．

後は開発フローが少し変更になるためそのメンテナンス作業すればOKでした．親ブランチを作りたい場合は，各自で適宜作成するようにしています．

どの改善でも共通で言えること

今振り返ると今回のイベントで発表したことは作業の難易度自体はそこまで難しくないものだと思いました．しかし，その中で苦労した点は改善に至るまでの議論です．

「○○にした方が良いんじゃね？」だけだと，改善を進めていくうちに生まれる懸念事項への解決が上手くできなかったり，開発メンバーが納得しないまま進めてします場合があります．

そのため改善を進めるには「そもそもの課題は何か」，「課題が解決されたらどんな状態になるのか」などを明確・整理することで懸念事項への解決や開発メンバーへの納得を得ながら進める必要があると感じました．

苦労した点と書きましたが，ここは時間を掛けて進めるべき内容だと思います．というかこの内容を発表の時にもっと話せば良かったと後悔してます😅．

まとめと所感

「マイナビ Tech Night #3」 で登壇しました．入社からイベント当日までの振り返りにもなったのでとても良かったです．完全ベンダーコントロールから内製開発への割合を増やすという段階なこともあり，GitHub の使い方や CI 環境の構築など今まで自分が Join したチームでは前提だったことをマイナビニュースでゼロから作り上げていくような経験をすることができました．

現在はスライドの後半にあるサーバーサイド，フロントエンド，インフラでやっていくことに取り組んでいるので，次回があればこれらの内容について発表できればと思っています．

今回のイベントや登壇資料がこれから内製・半内製開発をする上でどんなことが必要になるのかを検討している方達へ少しでも参考になればと思います（「内製開発へのシフト」がテーマのイベントがあったら登壇してみたい機運が高まりました）．

追記（2019/12/16）

「Geekroid」にてイベントレポートが公開されました．

mynavi-agent.jp

*1:github.comです．

Watchman が原因で Jest でテストを実行しても動かない場合の対応方法

この記事は，マイナビ Advent Calendar 2019 1日目の記事となります.

前回，Jest と Puppeteer に入門するという記事を書いたが，その記事を書く過程でテストが上手く動かず，詰まってしまったのでどう対応したのかをまとめておく．

bake0937.hatenablog.com

Jest でテストを実行しても動かない

作った E2Eテストを jest コマンドを実行したところ，Determining test suites to run...の表示で止まってしまい，テストが終わらない現象が発生した．

$ jest ./sum.test.js                                                                  
Determining test suites to run...

原因

公式リポジトリの issues を色々見てみたところ（結構奥深くまで見たので大変だった...） ，自分の PC に「Watchman」というライブラリがインストールされていることが原因で Jest が動かないという issue を見つけた．

github.com

「インストールした覚えが無いので，流石にこれではないだろう」と思いながらコマンドを確認してみた所，実はインストールされていたことがわかった．

$ which watchman
/usr/local/bin/watchman

解決方法

解決方法は簡単で，brew uninstall watchman を実行し，Watchman を削除すれば， jest コマンドが動くようになった．

$  brew uninstall watchman
Uninstalling /usr/local/Cellar/watchman/4.9.0_3... (23 files, 2MB)
$ jest ./sum.test.js
PASS  ./sum.test.js
  ✓ adds 1 + 2 to equal 3 (4ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.172s
Ran all test suites matching /.\/sum.test.js/i.

Watchman とは？

「さぁこれで解決解決〜」と思って終わりにしようとしたが，そもそも Watchman とはどんなライブラリなのかを軽く調べてみた．

Watchman とは Facebook が開発したファイル/フォルダ監視ツールで，指定したファイルが変更されたら，それをトリガーに何らかのアクションを設定できるツールであることがわかった．

facebook.github.io

www.moongift.jp

なぜ自分が Watchman をインストールしたのかを思い出してみたところ，過去に React Native を勉強してみようと思い，公式チュートリアルに沿って進めていたところ， Watchman をインストールする内容があり，その時にインストールしたことを思い出した．

facebook.github.io

今は React Native を触る機会が無いため Watchman をアンインストールをして解決したが，React Native のテストを Jest で書いている人は何らかの回避方法が必要であると思った．

この回避方法までは今回は調べないが今後 React Native を触る機会があれば検討する必要がある（すでに回避方法がありそうではあるが...）．

まとめと所感

今回は Jest でテストを実行したのに動かない場合の原因の一つについてまとめてみた．今回はそれらしいエラー文がコンソール上に表示されなかったので原因がわかるのに想定以上に時間が掛かった．

詰まったら，とりあえず公式のリポジトリを見に行く習慣はこの調子でやっていきたい．

第4回 転職透明化らぼ-技術ブランディング編 は個人・組織の技術ブランディングに必要なことが詰まった最高のイベントだった

現在私自身ブログに力を入れていて，技術ブランディングとして自分のブログをどのように活用すれば良いかのヒントが得られるかもと思い，「転職透明化らぼ」に参加しました．

rtlabo.connpass.com

当日の様子はこちら togetter.com

メディアから見た技術ブランディングに効くコンテンツ 〜企業編・個人編〜 @kondoyuko

• 本題に入る前に「ゆうこりん」と呼んでもらうコールアンドレスポンスは参加者と距離を縮めるためにやっている
• エンジニアが触れるメディアは書籍，商業Webメディア，オウンドメディア，ブログなど幅広い
  • アウトプットのストレッチ目標として商業誌での執筆を目指すのも良いかも
• ○万円のセミナーを担当できるエンジニアはステータスが高い印象
• ブログ・スライドがバズったことによる登壇依頼は普通にある

CodeZine 編集部 副編集長のゆうこりんさんの発表．わかりやすい話し方と復習しやすいスライド構成が印象的でした．今回のイベントで 18 回目の登壇であることにも驚きました．

私自身，メディア側がエンジニアのどのようなアウトプットに注目しているのかを知るのが初めてで，今回の発表を通して技術カンファレンスの登壇依頼や書籍・雑誌・Webメディアの執筆やインタビュー依頼がどのような流れで進められているのか，どんなマインドが必要なのかを知ることができる発表でした．

技術ブランディングやっていきの会社が考えるフェーズ別戦略 @ysk_118

• 技術ブランディングをなぜやるのか・なぜやりたいのかを考える
• 技術ブランディングはブログだけではなく，登壇・コミュニティへの還元・ OSS (プロダクトから作られる OSS )など様々
  • 事業活動から OSS を作っていく気持ちは大事！
• エンジニアブログは「個人的な記録」ではなく，ブランディングを意識しよう！
  • 若手のエンジニアは自信が無い内容では婉曲的な表現になりがちなため，ちゃんとキャッチアップをして自信を持って「です」で言い切ろう
• エンジニアブログへの記事の投稿を通して知見が高まると登壇の後押しができる
  • 1on1 などで各メンバーに「登壇してみない？」とタイミングを見て提案している
• 社内の「当たり前」にどうやって気づいて吸い上げていくのかが大事

「これから技術ブランディングをするぞ！」という意思決定をした企業がどのように技術ブランディングをしていけば良いのかのヒントが得られる内容でした．

特にエンジニアブログの運用方法についてや技術ブランディングをどのように継続していくかについては目からウロコでした．技術ブランディングを進めているけど，色々悩みがある企業に是非見てほしいと思いました．

プレイヤー目線の技術ブランディング @mottox2

• 今年で 4 冊の技術同人誌を出している
• 個人の技術ブランディングは「何ができる人なのかを発信し，対象に認知してもらうこと」が達成しているかが条件と言っても良さそう
  • 「○○といえばこの人！」など
• 「対象の人」は誰なのか？を考える
  • 特にフリーランスエンジニアの場合は「人事にも伝わる」ではなく，「現場のエンジニアに見てもらえる」発信が大事
• 「フリーランスエンジニアに憧れる」って言う人がよくいるけど，なること自体は役所で手続きすると 30 分くらいでなれるので，肩書きではなく「何をやってきたのか」というのが重要
• まずは，「自分の活動透明化」をはじめよう

「もっともーっとたけもっと」さんの発表です．「ゆうこりん」さんの時のようなコールアンドレスポンスで始まりました．差別化できる個人の技術ブランディングに必要なマインドや発信方法がわかる発表でした．

フリーランスエンジニアは技術ブランディングの戦略次第で仕事が取れるかどうかが決まるという印象もあり，より説得力がありました．個人の技術ブランディングはフリーランスエンジニアに関わらず，企業に属しているエンジニアにも重要で，個人の技術ブランディングが集合したものが組織の技術ブランディングに繋がっていくのだと感じました．

パネルディスカッション

最後は，@jumpei_ikegami と登壇者の皆さんによるパネルディスカッションでした．メモできた内容をまとめていきます．

技術ブランディングの担当は誰 or どの部門が担当しているのか？

• エンジニアチーム全員
  • チームの中での旗振り役は重要
• CTO 室やエンジニアの中で技術広報の役割を持った人が担当している

どうやってチームメンバーの協力を仰げば良いのか？(ブログの記事投稿など)

• ブログの場合は当番を決めたり，PV ・はてぶ数による表彰制度などの仕組みを作る
• 「バズるとスゲー！！」みたいな雰囲気を作る．
  • インドアな人は上手くそそのかして，カンファレンスや勉強会など色々な所に連れて行くようなステップを踏んでいく
• ブログを書いてもらう → 登壇してみない？というようにそそのかし，自己肯定感をくすぐっていく

ブランディングする自身がありません．どうやって自信をつけていますか？

• とにかく最初の一歩を踏み出そう
• 技術ブランディングに力を入れている企業に潜り込むのが良い
• 仕事で学んでいく

SIer における自社の技術ブランディングのやり方は？

• お客様の事例を直接出すのは難しいため，一般化が重要
• 幅広い案件を通して得たノウハウを出していこう

技術ブランディングの中で最も効果を出しているものは？

• ブログ
  • 面接で求職者に「ブログの記事に興味を持ったのがきっかけでエントリーしました」とよく言われる
• 広く知られるという観点では技術同人誌
• 仕事獲得の効果を出したのはやはり仕事

企業はブログやポートフォリオをどこまで見ているの？

• めちゃくちゃ見る
  • 見ることができる資料は全部見る．
• ブログやポートフォリオはその人が過去から積み上げてきたストーリーそのもので，過去から現在までくまなく見ていくことでその人のストーリーをチェックしている

実務経験は無くても技術ブランディングの対象になるのか

• 十分対象になる
• 新しい分野の獲得をするために必要
• 例として独学で自作のライブラリを作っている

Twitter に技術以外のことをどれくらいツイートして良いのか

• 特別気にはしないが強いていうなら，誰かをディスるツイートは印象が良くない

会社のブランドが広がっている指標とは？

• 定性的なものになるため，定量的には測れない
• 測るとしたら他者へ転職した元同僚にカンファレンスなどで会った時に，現在の自社がの印象についてチェックしている
• 技術ブログは「ただバズれば良い」に走らないようにするため， PV 数を取ることだけを目的にしていない

広く使われている技術はどういった差別化をしているのか？

• ライブラリやツールをまっさらな状態から導入するよりも，導入するハードルが高い環境でどのように試行錯誤したかの経験は差別化の一つになる
  • 例: モノリシックな Rails アプリにどう立ち向かっていくのか
  • レールから外れた Rails アプリをどうやってアップグレードしたのか

まとめと所感

「転職透明化らぼ」に参加しました．今回のテーマは転職するかしないか関係なく，これからブログを始める人やどうやって技術ブランディングをやっていくのか悩んでいる人にピッタリなイベントでした．

私の場合，好きな技術でのブログの記事や登壇の量をもっと増やしていこうという気持ちになりました．また，自社のエンジニアブログで持っている課題についての提案が何個か思いつくことが出来ました．

会場を出る前に，イベントで使用された参加者のネームプレートがとても素敵でどうやって作ったのかをスタッフの方に聞いたところ，「参加者の名は。」というアプリを教えて頂けたのも大きな収穫でした！！ 口頭で教えて頂いたので最初は「参加者の縄」って名前でググってしばらくヒットしなくて焦りましたが何とか見つけることが出来ました

yoshiko.hatenablog.jp www.moongift.jp

登壇者・参加者の皆さん，スポンサーの皆さんありがとうございました！

E2Eテストを導入するために Jest と Puppeteer に入門する

現在開発している Rails アプリにE2Eテストの導入を検討している．その方法の一つして Jest と Puppeteer の構成について検討することにしたため，学んだことをメモしていく．

いきなり Rails アプリには導入せず，まずは Jest の Getting Started を読みながら Jest と Puppeteer の使い方について学んでいく．今回はセットアップと Google.com へアクセスするテストコードを書いてみる．

jestjs.io

「RSpec + Capybara + Headless Chrome」の構成や System Spec を導入する事例をよく聞くが...

Rails アプリの E2Eテストは「RSpec + Capybara + selenium-webdriver」の構成をよく聞く．数年前までは poltergeist を使うのを良く聞いていたが， PhantomJS の 開発終了 に伴い，代わりとして Headless Chrome を使うようだ．また，rspec-rails 3.7 の System Spec も注目されている． さらに Ruby(Rails) を使えるため，Active Record を利用したテストデータも簡単に作ることができる．

しかし，開発中の Rails アプリのバージョンは 5.0 系で SystemTestCase が無いため，Rails のバージョンを上げる必要がある．また minitest から RSpec に移行する必要がある*1．移行に関しては，「RSpec + Capybara + Headless Chrome」の構成も同様．

このように色々と悩んでいると， Jest と Puppeteer によるE2Eテストの導入の事例を聞いたことで，Rails アプリの gem の移行やバージョンアップの作業から切り離すことができる，また VueCLI による単一ファイルコンポーネントを導入する上でフロントエンド用の Jest などのテスティングフレームワークも導入する必要があることも思い出し，思い切って入門することにした．

※Rails アプリの gem の移行やバージョンアップは，それはそれで別途対応していく

実際に使ってみる

試した時に作ったソースコードはこちら． github.com

Jest の導入

新しいディレクトリ（フォルダ）を作成し，Jest を導入する．なおパッケージマネージャーは yarn を使用する．

yarn の初期化と Jest をインストールする．

jest-puppeteer-sample » yarn init
jest-puppeteer-sample » yarn add --dev jest

確認用のコードと テストコード を用意する．

jest-puppeteer-sample/sum.js

function sum(a, b) {
  return a + b;
}
module.exports = sum;

jest-puppeteer-sample/sum.test.js

const sum = require('./sum');

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

package.jsonに以下のスクリプトを追加

jest-puppeteer-sample/package.json

--  }
++  },
++  "scripts": {
++    "test": "jest"
++  }

テストを実行し，以下のような結果に慣れば OK👌

jest-puppeteer-sample - [master] » yarn test sum.test.js
yarn run v1.17.3
$ jest sum.test.js
 PASS  ./sum.test.js
  ✓ adds 1 + 2 to equal 3 (4ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.744s, estimated 2s
Ran all test suites matching /sum.test.js/i.
✨  Done in 2.32s.

Puppeteer を導入

以下を読みながら進めていく．

jestjs.io

Puppeteer と jest-puppeteer をインストールする． jest-puppeteer は JestとPuppeteer を連携させるためのツールだ．

jest-puppeteer-sample » yarn add --dev puppeteer 
jest-puppeteer-sample » yarn add --dev jest-puppeteer

Google.com へアクセスし，ページタイトルに「Google」という文字列が含まれているかを確認するテストコードを追加．

jest-puppeteer-sample/e2e.spec.js

describe('Google', () => {
  beforeAll(async () => {
    await page.goto('https://google.com');
  });

  it('should be titled "Google"', async () => {
    await expect(page.title()).resolves.toMatch('Google');
  });
});

テストコードを実行． 以下のような結果になれば OK👌

jest-puppeteer-sample - [master] » yarn test e2e.spec.js
yarn run v1.17.3
$ jest e2e.spec.js
 PASS  ./e2e.spec.js
  Google
    ✓ should be titled "Google" (7ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        3.002s, estimated 4s
Ran all test suites matching /e2e.spec.js/i.
✨  Done in 5.61s.

まとめと所感

• Jest と Puppeteer に入門した
• Rails アプリでよくあるE2Eテストの構成や事例と比較をしてみてた
• まだまだ序盤のため，引き続き Jest と Puppeteer で何ができるのかをキャッチアップしてくのと色々なE2Eテストを書いて知見を得ていく
• 技術メモも書いてく

github.com

*1:System Spec は SystemTestCase を Rspec で利用できるようにする機能

「それ，Notionでできます #5」で自分なりの Notion の使い方について LT をした

3日前に開催された「それ，Notionでできます #5」で LT で登壇しました．Notion のデータベースの使い方や参加者の皆さんの様々な使い方を知ることができました．

今回は

• 登壇した資料についての補足
• デモ中に話したこと
• 登壇してみての所感

などについてまとめていきます．

notion-05.peatix.com

発表資料

今回は「作成した Notion のページを発表する」が LT のテーマのため「Notion 📚 へ移行して 3ヶ月経った振り返り 〜 Notion 沼から少し抜け出した〜 」というタイトルで発表しました．

基本的な内容は先日書いたブログをベースに作成したので併せて見てもらえたらと思います．今回の LT で追加した内容はこれから補足していきます．

bake0937.hatenablog.com

Notion へ移行するに至った経緯

私は元々 Evernote を使っていたのですが， Webエンジニア に転向してからMarkdown を覚えたことで， Evernote でも Markdown を書きたいという欲求が強くなってきました．

Evernote も一部は Markdown をサポートしていたり，「Marxico」という Chrome アプリと連携すればできそうではありましたが，「もっと便利なアプリがあるはずだ！」と思い，新しいアプリを探すことになりました．

最終的には Notion と 「Quiver」と 「Inkdrop」（この記事書いている時に思い出しました😅）に絞られましたが，ノート以外の様々な機能があることに惹かれて Notion を使うことになりました．

chrome.google.com

happenapps.com inkdrop.app

移行はとても簡単だったが...

移行は Import 機能を使えば 1400 枚くらいのノートも 5,6 分で終わって最高だったのですが，サイドバーの「PRIVATE」に何十個のノートのスタックが並んでしまったので，移行後は少し整理が必要です🧹．

Notion 沼 をご存知だろうか

国内でも様々な Notion の使い方が各ブログやメディアで紹介されています．とても参考にはなりましたが，結局「自分はどんな使い方をしたいんだっけ？」と悩んでしまい，ただ時間が過ぎていく日が何日か続きました．

溶ける．．．Notionで時間が溶けていく．．．

— okabeeeat (@okabeeeat) 2019年11月4日

---

そんな中，前回開催された「それ，Notionでできます #4」に参加したことで Notion を使っている皆さんと質問や情報交換ができてとても助かりました．

現時点での使い方について

「All Task」という名前で仕事に限らず，プライベートも含めて「Board」でタスク管理をしています．各用途や役割ごとに「Board」を作っても良かったのですが管理が大変そうなので，この方法でやってみてます．

「技術ブログの進捗管理」と「個人的な目標管理」に関連するタスクは Notion のリレーション機能を使って「All Task」に子タスクとして追加しています．

「個人的な目標管理」の話で「OKRのテンプレートはどんなものを使ってるいるのか？」という質問が来ていたので，改めてこちらにも共有します．右上にある「Duplicate」をクリックすれば，自分の Notion アプリに取り込まれます．

OKRのテンプレート

他にも様々な Template Gallery があるので色々見てみると他に使ってみたいテンプレートが見つかるかもしれません．

Notion Template Gallery

3ヶ月運用してみて

今後に期待な所もありますが，今の所は快適に利用しています！1つのアプリにまとまるのが何より良いです．

公開API については近いうちにリリース予定とのことですが，有志の方が Notion のページをダウンロードする API を作っている話を聞いたのでリリースされるまではこの API を触ってみるのも面白いかと思いました．

presstige.io

発表中

会場はノースサンドさんの新オフィスだったのですがとてもオシャレな空間で，LT やトークをするのにとてもテンションが上がる空間でした！...と言いつつ少し緊張しながら LT をしました．

沼、なるの、分かります。共感しかない。#Notion部 pic.twitter.com/cLmsHTcWKO

— きょん (@kyon_hcj) 2019年11月19日

イベント内容のまとめ

当日のイベント内容や写真はこちらです．

[#5] 11/19(火) 19:30-21:00

まとめと所感

「それ，Notionでできます #5」に LT で登壇しました．LT の準備を通して自分なりの Notion の使い方についての整理ができてとても良かったです．この「LT の準備」について本当はもっと書きたかったのですが，また別の記事に託そうと思います．

さらに，登壇者には Notion 特製トートバッグのプレゼントというサプライズがあって「LT やって本当に良かった！」という気持ちがさらに上がりました😄．

最後は Notion Labs, Inc. からのビデオメッセージのセッションもあり，今後の Notion について少し知ることができた充実したイベントでした！！！

「銀座Rails#15」に参加して Rails の設計と貢献方法についてのヒントを得た

「銀座Rails#15」 に参加してきました．今までにも何回か参加したことがありますが，ふと「そういえば最近，イベントレポート書いてないぞ！」と思い，イベント内容の復習も兼ねてイベント内容と感想をまとめていきます．

ginza-rails.connpass.com

出張！Railsウォッチ in 銀座Rails @morimorihoge

• 11/5 に Rails 6.0.1 がリリース
• 11/7-8 RubyWorld Conference 2019 が開催
  • Ruby Prize で糸柳さんが受賞
    • スピーチがとても良い話
• production? development? staging? の意味がややこしい
  • これらの用語はプロジェクトによって
    • アプリケーションの動作モード
      • Rails における「RAILS_ENV」
    • deploy 先のサーバー環境
    • Git のブランチ・タグ名

  など様々な意味合いが含むことがあることで，チームメンバーが混乱すること・想定外なオペレーションミスが起きる要因の一つになる．

  • 混乱を防ぐために用語のルールを設ける
    • 「RAILS_ENV」を指す場合は「モード」をつける
    • サーバー環境を指す場合は「サーバー」をつけたり，別の単語を使う
    • Git のブランチ・タグ名を指す場合はブランチ・タグ名であることを明示する

今回が 4 回目となる「出張！Railsウォッチ」は雑多なテーマを取り上げた内容でした．「production? development? staging?」の内容は，私が経験してきた開発の中では特段大きな混乱や事故などはありませんでしたが，言われてみると確かに開発をする上で混乱のもとになるケースの一つだと思いました．

Slack などのチャットでのコミュニケーションはスピードを求められることがあります．その場面でも省略化せず，明確な用語でコミュニケーションを取る必要があると感じました．

「公開つっつき会」が毎月第一木曜日に開催しているとのことなので，参加してみたいと思いました． techplay.jp

Service クラスと Form Object をやめよう。サブクラスを使おう @yalab

• そもそも service クラスとは？
• PoEAA や DDD などの service レイヤーからの出自だと思われるが，プロジェクトや人によって定義が曖昧なケースが多い
• 乱用が多く，コードレビューがし辛い
• service クラスはそもそも fat model を何とかするために使うようになった
• model を分割して責任範囲を分割したいならサブクラスで分割しよう
• 責務からコードの振る舞いを定義しよう

開発するプロダクトの規模が大きくなるにつれて，どのチームでも直面する話だと思いました．service クラス．．．私もこのクラスとの向き合い方は普段から悩まされています．

サブクラスを使うというやり方については賛否両論がある雰囲気でしたが，個人的には「あ！そういうやり方があるんだ！！」と素直に参考になりました．

どの方法がベストかや銀の弾丸になるかを決めるのではなく，開発するプロダクトやチームメンバーによって，どの方法を取り入れることで fat model を何とかできそうなのかを考えることが大事であると思いました．

serviceクラスをやめようサブクラスを使おう from よしだ あつし

個人アプリをRails 6.0.0rc2に上げたらバグを踏んだのでRailsにIssueを投げた話 @shiroemons

• Rails 6.0.0rc2 に Issue を投げた話
• 「Rails 6 リリースするか？ Party」への参加をきっかけに個人アプリの Rails のバージョンを上げることに
• Active Model の COUNT のエイリアスのアンダースコアが 2 つになっているを発見
  • 例: count__articles_id
• 「Rails ガイド」の「Ruby on Rails に貢献する方法」を参考に再現コードを作成． railsguides.jp
• Issue のタイトルで悩んでいたので「ruby-jp」コミュニティの「#rails」で質問・相談
  • 再現コードのエラーをタイトルにすることに
• Rails に Issue を投げることができた！バグも無事に修正された！
• Issue を投げる時は再現コードのあるリグレッション報告をするのが最強
• @kamipo さんはすごい人

「Rails 6 リリースするか？ Party」をきっかけに，個人アプリの Rails のバージョンを 4.2 から 6.0.1 に怒涛の勢いで上げた @shiroemons さんの発表．個人アプリへのプロダクト愛もとても伝わった内容でした．

私は「rc のバージョンは開発中だからあまり触らないでおこう」というような考え方をしていましたが， Rails へ何かしら貢献したい気持ちがあるなら，むしろ rc をどんどん触っていくのが良いことがよくわかりました．

私も過去に「OSS Gate」のイベントに参加した時に 「RubyGems」に Issue を出したことがあります．「ruby-jp」コミュニティと併用するとさらに良さそうだと思いました．

今度はプルリクエストを出すのも挑戦していくぞ！！

oss-gate.doorkeeper.jp

@kamipo さん と @yahonda さんのフリートーク

• @kamipo さんの Rails のプルリクエストを皆で見ていく内容
• 本当にほぼノープランだったのか？と思うくらいの @yahonda さんの進行の上手さ
• プルリクエストはまずテストケースを見ていく
• 紹介されたプルリクエスト
  • Maintain eager loading joining order as before by kamipo · Pull Request #37235 · rails/rails · GitHub
  • commit 成功されるのに rollback されちゃう
    • Rollback in `after_commit` should not rollback state that already been succeeded by kamipo · Pull Request #37251 · rails/rails · GitHub
  • Fix new instance creation on association relation to respect unscope by kamipo · Pull Request #37511 · rails/rails · GitHub
  • Fixed performance regression introduced MySQL 8.0 by alpaca-tc · Pull Request #37465 · rails/rails · GitHub
  • @kamipo さん の最初のプルリクエスト
    • Use `SchemaStatements#initialize_schema_migrations_table` instead of `ActiveRecord::SchemaMigration.create_table`. by kamipo · Pull Request #12962 · rails/rails · GitHub
  • Only use BINARY for mysql case sensitive uniqueness check when column has a case insensitive collation. by kamipo · Pull Request #13040 · rails/rails · GitHub
• これから Rails に貢献していきたい人は「good first issue」を見てみよう
  • 内容が「good first」ではない場合もある😅
• プルリクエストを作る時は，解決したい現象を必ず解明しよう
  • 現象を解明しないと大抵はマージされない
  • 現象が解明されていて必要十分なプルリクエストは，コードレビューで質問することが無いため，ほぼ無言でマージされることがある
  • 見本となるプルリクエスト
    • Don't recursive call for value local variable that type is Array in `ActiveSupport::ParameterFilter::CompiledFilter#value_for_key` by kamillle · Pull Request #37689 · rails/rails · GitHub

時間が許す限りで @kamipo さんが作成してきたプルリクエストを皆で見ていきました．特に「commit 成功されるのに rollback されちゃう」のを解決したプルリクエストは盛り上がりました．

「再現コードは必ず作る」，「@kamipo さんでも Rails に初めて貢献した時があった」などのエピソードはこれから Rails に貢献したい人の肩を押してくれるとても良い内容でした．

まとめと所感

• 「銀座Rails#15」に参加してきました
• 開発をする上で，用語は明確化することと fat model を解決するための一つの解決策・ Rails への貢献方法の事例を学びました
• 普段の開発で思っていることと共感する内容が沢山あった
• 登壇者・参加者の皆さん，スポンサーの Forkwell・SONY さん ありがとうございました！