Evernote 🐘 から Notion 📚 へ移行して3ヶ月が経ったので使い方を振り返る
前回の記事にもありましたが，個人で使っているノートアプリを Evernote 🐘 から Notion 📚 へ移行しました．今回は Notion の紹介と私がどんな感じで使っているのかをまとめていこうと思います．
Notion とは?
Notion Labs, Inc. が運営するノート，Wiki，タスク，スケジュールなどの機能が備わったオールインワンのアプリです．つまり，Evernote や Google Docs，Trello，GitHub Wiki，Google Spread Sheet などを一つにまとめたようなアプリです．
今まではそれぞれのアプリを開いて操作する流れでしたが， Notion さえあれば一つにまとまるということになります．
移行方法
とても簡単です．Notion の「Import」のリンクから Evernote を選択すれば，Evernote にあるノートが Notion にインポートされます．画像もマルッと移行されます．
ただ，Evernote のノートの数が沢山ある場合，Notion の無料プランの制限を越える可能性があるため，無料プランで軽く使ってみてOKそうなら有料プランに加入してインポートすることをお勧めします．
自分なりの使い方
Notion には「データベース」という機能があり，この「データベース」を作成し，様々なビュー（ Board ，テーブル，カレンダー， Wiki など）を活用することでカスタマイズしていくことができます．（「データベース」についての詳細はこちら）．
移行してから3ヶ月経ちましたが，現在は以下のような使い方をしています．
Webclipper
Evenote と同様に Notion にも Webclipper があります．あとで見る記事や保存しておきたい記事は，Webclipper で Notion に保存することができます，
タスク管理
「Bord」機能でカンバン方式のタスク管理をしています．タスクは勉強・仕事・プライベートなど全てのタスクを入れています．
タスク管理のやり方（各カラム決め方やルールなど）は「SOFT SKILLS ソフトウェア開発者の人生マニュアル」にある「第37章 私の生産性向上策を明かそう」を参考にしています．
前回の「それ､Notionでできます #4」で「SOFT SKILLS」のタスク管理のやり方を実践されている方がいて「これだ！」と思い，実践しています．
「Add a View」で「Calendar」を選択し，タスクに日付を追加すれば，カレンダー形式で表示することができます． Google Calendar と同期できるようになって欲しい！！！
Slack 通知
右上にある「Updates」から Slack に通知をする設定ができます．タスクの変更や追加などがあった場合に通知されます．
日本だと，タスクの変更や追加をしてから 5, 6 分後に Slack に通知されるようです．
目標管理
「Template Gallery」 で公開されているOKRのテンプレートを使って，個人的に四半期の目標管理をしてみました．OKR 自体は今まであまり経験が無いため，目標や Key Result の立て方などこれから勉強していく必要がありますが，色々と試行錯誤していこうと思います．
リレーションで Board と Key Result を関連付ける
リレーションという機能を使って各データベースの項目を関連付けることができます．（リレーションについての詳しい説明はこちら）．
私の場合は Board のタスクと OKR の Key Result を紐付けるようにしています．これにより
- 今取り組んでいるタスクは，どの Key Result と紐付いているのか
- どのような目的や意図があるのか
が明確になり，モチベーションを少しでも維持できるようにしています．
「Properties」 でリレーションを表示するようにすれば，タスクがどの Key Result に関連付いているのか一目でわかるようになります．
Notion を運用してみて
実際に運用してみて思ったことは以下のような感じです．
Good 👍
マークダウンに対応
Evernote にも独自のマークダウン記法や Marxico を導入すれば書けるようになります．しかし，Marxico を利用し続けるには有料プランに入る必要があるのとChrome アプリのみというところで悩んでいました．
そんな中，Notion はデフォルトでマークダウンに対応していることを知り， Notion に移行する判断になりました．
1つのアプリにまとまる！
Notion は タスク管理やスケジュール， Wiki，ノートなど様々な機能があるため，今までのように色々なアプリを立ち上げる必要が無くなり，アプリを切り替えるストレスが減りました．
カスタマイズがめちゃくちゃ自由
「Template Gallery」で公開されているテンプレートの他にも，自分でテンプレートを作ることができたり，どの項目を関連付けるか，どのパーツを活用するのかなど，とにかく自由にカスタマイズができます！．
つまり Notion は，カスタマイズを一度始めると楽しくなって時間がどんどん溶けていきます😇．
今後のアップデートに期待 🙏
オフライン時に開けない
現状，Notion はオフラインでデータを持つ仕様ではないため，オフラインの状態で今まで作成したものを見ることができません．ただ，新しくページを作ることはできます．
Google Calendar と同期して欲しい！！
Board のタスクに日付を設定した時に Google Calendar 側にスケジュールとして入って欲しいという気持ちになりました！
まとめと所感
今回は自分なりの Notion について書いてみました．今回書いた内容の他にも Notion の使い方は本当に様々なので引き続き使っていこうと思います．
と，様々な使い方があると書きましたが実際に自分の使い方がどうなのかが気になるので，来週の「それ、Notionでできます #5」で LT で参加しようと思います💪． notion-05.peatix.com
「rack-dev-mark」で開発環境と本番環境を視覚的に判断する
普段の開発で，本番環境だと思ったら開発環境だったというような誤認をし，ヒヤッとしたことが何回かありました．
アドレスバーだけで判断するのも中々難しいことがあります．今回はそんな誤認を防ぐ gem 「rack-dev-mark」 の導入方法をまとめていきます．
検証した Ruby・Rails のバージョン
Ruby は 2.5.1，Rails は 5.2.3 で動作を確認できました． 現状（2019/11/10），rack-dev-mark のリポジトリにある README や issue，プルリクエストを見ると Ruby 2.6，Rails 6.0.1 にはまだ対応していないようです．実際に検証もしてみました．
導入方法
方法は何パターンかありますが，一番簡単なのはapplication.rbに以下の一行を追加すれば良いです．
config/application.rb
class Application < Rails::Application
config.load_defaults 5.2
+ config.rack_dev_mark.enable = !Rails.env.production?
end
rails sで確認すると，開発環境の場合は「development」の文字でリボンが表示されます．
Theme を設定
Theme を設定するとリボンの表示位置や色を指定することができます．application.rbにさらに一行追加します．
config/application.rb
class Application < Rails::Application
config.load_defaults 5.2
config.rack_dev_mark.enable = !Rails.env.production?
+ config.rack_dev_mark.theme = [:title, Rack::DevMark::Theme::GithubForkRibbon.new(position: 'right')]
end
リボンはどの位置に表示したほうが良いのか
開発者やチームメンバーで相談すれば OK ですが，どの位置に表示した方が効果的なのかを調べてみました．
どうやら人間は画面や紙面を見る時，視線は左上から始まることがわかりました．今見ている環境が開発用なのかは最初に認識するべきだと思い，私はリボンを左上に表示するようにしています．
まとめと所感
今回は「rack-dev-mark」についてまとめてみました．導入自体は簡単でしたが，Ruby 2.6，Rails 6.0.1 にはまだ対応していないことは知りませんでした．
gem やライブラリを利用する時は公式ページの情報をくまなくチェックするべきだと改めて実感することができました．
Notion でログインする Googleアカウントを間違えた場合の対応方法
最近，ノートアプリを Evernote から Notion へ移行しました．だいぶ慣れてはきましたが，今回は Notion を活用する中で詰まったことと対応方法を書いていきます．
ログインする Google アカウントを間違えてしまった
Notion は Google アカウントでログインしているのですが，Google アカウントの選択画面でログインするアカウントを間違えてしまい，そのまま Notion のアカウントの登録画面へ遷移してしまったことがありました．
ログインし直そうと思い，トップページ( https://www.notion.so/ )やログイン画面にアクセスしようとしても Notion のアカウントの登録画面へ遷移されてしまいます.
これでは Notion を利用する時の Google アカウントでログインすることができません．
対応方法
「というわけで，皆さん！ブラウザのデベロッパーツールを開いてセッションを削除くださいっ！」と書く予定でしたが，もっと簡単な方法を見つけました．
それはブラウザのアドレスバーでログアウトする時の URL ( https://www.notion.so/logout ) を入力して Enter を押す方法です．
これでトップページへアクセスできるようになり，「Login」のリンクから Notion を利用する時の Googleアカウントでログインすることができます．
「Notion Web Clipper」を利用する時にログインする Google アカウントを間違えた場合も同様の対応をすれば解決することができます．
今回はだいぶ小さな小ネタレベルの内容でしたが，詰まった当時はブラウザのデベロッパーツールでセッションや色んな情報を消してみたりと地味に時間が掛かってしまったので，同様の内容で詰まった方の参考になればと思います 🙏
Evernoteから移行した経緯やどのように使っているかは近いうちに別記事でまとめていきます💪
Kibela → DocBase に移行して気づいた点をまとめてみた
最近，チームで利用している情報共有ツールを Kibela から DocBase へ移行しました．移行作業自体は簡単でした．しかし，疑問点や懸念事項とぶつかりながら作業をしたので，今回は移行方法と気づいた点をまとめます．
正解は特にないと思いますが，これから同様の作業をする方が少しでも参考になればと思います．
移行する記事数を確認する
移行作業をする前に投稿されている記事数を確認しておきましょう．確認するには「チーム統計情報」から確認できます．ただしこのページは「オーナー」または「管理者」しか見ることができません．
そのためログイン中のユーザの権限が「フルメンバー」の場合，「オーナー」または「管理者」の権限に変更するか権限を持っているメンバーに記事数を確認するよう依頼する必要があります．
DocBaseへ移行する
DocBase のインポート機能を使えば移行することができます．この機能もオーナーまたは管理者しか利用できないため，ログイン中のユーザの権限が「ユーザ」の場合は変更しておきましょう．
インポートが終了するとメールが来るのでそれまでは待機します．インポートの進捗と結果は「インポート履歴」から確認することができます．
移行作業中に気づいた点
移行用のユーザでインポートする
インポートした記事は Kibela のタグが貼られますが，記事を投稿したユーザはインポートを実行したユーザとなるため，ホーム画面をパッと見た時に「全部 okabeeeat が投稿した記事なのか」と勘違いする懸念がありました．
そのため移行用のユーザを作成し，インポートすることで少しでもわかりやすくするようにしました．
インポートする記事の種類について
通常の記事に加えて「テンプレート」もインポートされます．また，「下書き」はインポートの対象外のため注意が必要です．
Slack 連携は一時的に OFF にしておく
DocBase の記事の投稿や更新を Slack のチャンネルに通知している場合は一時的に OFF にすることをオススメします．この状態でインポートするとチャンネルに川（大量の通知）が流れてしまいます．．🏞️．
IP制限を設定した状態でインポートはできるのか
Kibela と DocBase の両方でIP制限を設定してもインポートは問題無くできました．
個人アクセストークンを使った方法なので，問題は無く移行できるだろうと考えてはいましたが，ここばっかりは実際にやってみないとわからなくて不安でしたが，無事インポートできて良かったです．
インポートはどれくらい時間が掛かるのか
インポートする記事数や Kibela，DocBase 側の API に依る話になりますが，私が作業した時は総記事数 620 枚 + テンプレート 4 枚で約 20 分掛かりました．
5万文字以上の記事はインポートできない
現在のDocBaseの仕様では5万文字以上の記事はインポートできないようです． help.docbase.io
5万文字以上の記事なんてそうそう無いだろうと思うかもしれませんが，私が作業した場合は，長文のSQL文をメモしている記事が移行に失敗しました😅．失敗したのは数件だったので記事投稿者に手動で移行するように依頼しました．
「外部共有」に設定した記事に対してIP制限は適用されない
Kibela の場合，IP制限を設定した状態で記事を外部共有に設定することで，Kibela を普段利用していない社内のメンバーに共有することができました（社員数や事業部が多い企業では地味に使うやり方です）．
しかし，DocBaseはIP制限を設定したとしても「外部共有」に設定した記事はどこからでもアクセスができる仕様です（運営に問い合わせてみました）．
そのため，外部共有する記事にパスワードを掛けるなどの対応が必要になると思います． note.mu
一旦，外部共有を制限し，別の対応方法を検討するのもアリだと思います． help.docbase.io
移行後に気づいた点
インポートした記事はインポートを実行したユーザまたは管理者・オーナーしか編集できない
移行作業を終え，他のメンバーが DocBase を利用した際に「Kibelaの時に書いた記事の内容の編集や公開範囲を編集したいんだけど権限が無くてできない」と言われた時に気づきました（ここが盲点でした）．
インポートを実行したユーザが代わりに編集すれば良いですがインポートした記事が大量にある場合は大変です．
移行用のユーザの権限を「ユーザ」に変更すれば解決できそうではありますが，私の場合は移行用のユーザで記事をインポートした後，移行用のユーザを削除することで解決しました．
削除したユーザの記事はチームメンバーであれば誰でも編集することができます．
DocBase を使ってみての所感
とまぁそんな感じで色々ありましたが移行作業は無事終え，現在は DocBase を情報共有ツールとして利用しています．リアルタイム編集や細かい設定ができて便利です．しかし，UI は Kibela の方が個人的には好きだったりします😅．
木部さん（Kibela のマスコットキャラクター🦁）が居なくなって寂しい気持ちもありますが引き続き DocBase を使ってこうと思います 💪
capistrano-github-releases でデプロイ時に Releases と Tags を自動生成する
前回，「capistrano-releases-notification」を導入したことでデプロイ時にSlack通知をするようにしました．今回は「capistrano-github-releases」を導入し，デプロイ時に該当リポジトリの Release と Tags を自動生成するようにします．
今回も試した Ruby のバージョンは2.6.5、Capistrano のバージョンは3.10.1です．
使い方
使い方はとても簡単です．以下のように gem を追加します．
Gemfile
gem 'capistrano-github-releases'
$ bundle install
Capfileとproduction.rbに設定を追加します．
Capfile
require 'capistrano/github/releases'
config/deploy/production.rb:
after 'deploy:finishing', 'github:releases:create' after 'deploy:finishing', 'github:releases:add_comment'
動作確認
前回の「capistrano-releases-notification」の記事にもありましたが，今回の動作確認も--dry-runオプションをつけて実行してみます．GitHub の個人アクセストークンが必要なため事前に作成しておきましょう．
$ bundle exec cap production deploy --dry-run
実行後， Releases と Tags が作成されていることが確認できます．
Merged された最新のプルリクエストにコメントがついていることも確認できます．今回は自分のアカウントのアクセストークンを使ったため自分がコメントしているようになりました．
Bot ユーザを用意し，そのアクセストークンを使うやり方もアリだと思います．
動作を確認できたら--dry-runオプションを外して実行してみましょう．
ちょっと一工夫
capistrano-github-releases のオプション機能でプルリクエストへのコメントはカスタマイズが可能です．そのため，production 環境でリリースをしたことを明記するようにしてみます．
config/deploy/production.rb:
set :release_comment, ":hammer_and_pick: #{fetch(:stage)} にタグ [#{fetch(:release_tag)}]\ (#{fetch(:github_releases_path)}/#{fetch(:release_tag)}) でリリースしたよ〜 :rocket:"
cap コマンド実行後，このようなコメントになることがわかります．他にもオプション機能はあるので，公式リポジトリを見ながらカスタマイズしてみましょう．
導入してみた結果
導入する前は Release と Tags を手動で作成する必要があったため手間だと感じていましたが，デプロイ時に生成されることでその手間を省くことができました🙌．
また，自動でリリースした旨のコメントがされるため，プルリクエスト上でコードレビューからリリースまでの一連の流れがわかるようになりました🙌．
今までは本番環境にリリース後にリリースした旨のコメントをプルリクエストに入れるルールでやっていて，たまにコメントし忘れることがありましたが，これでもう大丈夫です 💪
デプロイ周りでのチーム内コミュニケーションはだいぶ整ってきました😄．
linyows さん！ありがとうございます！！！
「Customize AWS Console Header」でAWSコンソール画面のヘッダに色をつけてアカウントの誤認を防ぐ
普段の業務でAWSアカウントは本番用と検証用で分けて運用しているのですが，コンソール画面を見ていると．．．
- ふとした時に「あれ？今どっちのアカウントを使ってるんだっけ？」と混乱する
- 「あ！本番用アカウントで設定したと思ったら検証用アカウントだった！！」
というようなヒヤッとした場面が何回かありました．
アカウントの誤認でヒヤッと焦るような状況や本当に事故が起きないようにするにはどうしたら良いのかを考えたところ，現在ログインしているアカウントが本番用なのか検証用なのかが画面上に表示されると良いと思いました．
色々調べた結果， 「Customize AWS Console Header」という Chrome の拡張機能を導入し，アカウント毎にヘッダの色をつければ良さそうなことがわかったので今回はそれの紹介をします．
設定方法
Google Chrome を立ち上げて，以下のURLから「Customize AWS Console Header」をインストールします．
インストールされると Chrome の右上あたりにアイコンが表示されるので 右クリック → オプション を選択し，設定画面に移動します．
設定画面で以下のようにヘッダに表示させたいラベル名，ログインするAWSアカウント，対象のリージョン，ヘッダの色を設定します．本番用は目立つように濃いピンクにしてみました．
それぞれの項目を設定した後は保存ボタンを押します（保存ボタンを押すのを忘れた状態でコンソール画面を見て「アレ？反映されていないぞ！？」っというのがよくあったので）．
これで本番用アカウントでコンソール画面にログインすると，このように色がつきます．
フッターにも色がつきます．
この調子で検証用のアカウントにも色をつけてみましょう．「ルール追加」もしくはコピーマークのボタンから設定を追加します．色は砂場をイメージして茶色にしてみました．
検証用のAWSアカウントでログインし直すと，検証用アカウントのヘッダーにも色がついたのがわかります．
「Customize AWS Console Header」を設定してみて
自分が今どのアカウントを使っているのがハッキリとわかるようになったので，突然焦ってしまうことや混乱することが無くなり，安心してAWSを触れるようになりました．また，ヘッダに好きな色をつけられるので個人的にテンションが上がりました 😄
こういうちょっとした工夫で普段の開発を大きく助けてくれる Chrome の拡張機能を作ってみたい気持ちにもなりました 💪
プルリクエストでの「Start a review」と「Add single comment」の使い分けがよくわかってなかったのでまとめてみた
普段プルリクエスト上でコードレビューする時に，全て「Add single comment」でコメントを入れていました．
この方法でもコードレビューは普通にできますが，先日 GitHub 社の方と話す機会があり，その時に「Start a review」と「Add single comment」をどのように使い分けるかをアドバイス頂いたのでまとめておきます．
チームや人によって使い方は様々なのであくまで参考程度に見て頂ければと思います．
「Reviewers」でレビュアーを指定する
まずはレビューイ（レビューしてもらう人）が「Reviewers」の項目でレビュアー（レビューする人）を指定します．
今までの私はプルリクエストの画面でレビュアーになって欲しいメンバーにメンション付きでコメントしたり，Slack上で依頼をしていたのでまぁ指定しなくて良いかなぁと思っていました😅．
「Reviewers」でレビュアーを指定するのが毎回面倒，「Reviewers」にしたメンバーにSlackなどのツールで改めてお願いするのが面倒な人は「Pull Panda」というサービスがオススメです．
「Start a review」の使い方
この機能の使い方が今まで謎だったのですが，「Start a review」は「Reviewers」にしたメンバー，つまりレビュアーが使う機能のようです． 例えば私がレビュアーの場合は以下のようにコメントを入れて「Start a review」を押します．
コメントした箇所に「Pending」と表示されます．この時点では該当箇所にコメントしたことはレビューイの画面に表示されません．コメントしたレビュアーにのみ表示されます．
2回目以降のコメントは「Add review comment」でコメントを入れていきます．
レビューが終わったら，画面右上にある「Finish your review」または「Review changes」を押します．そうすると入力欄が表示されるので，ここにレビュー内容についての総評などを入れて「Submit review」を押します．
これでレビューイの画面にレビュアーのコメントが表示され，内容を確認できます．
「Add single comment」の使い方
特に決まった使い方はありませんが，以下のような使い方があるのかなぁと考えてます．
- レビューイが実装したコードの補足のコメントを入れたい
- レビューイ，レビュアー以外のメンバーがコメントしたい
レビューイ，レビュアー以外のメンバーがふとコメントした内容が実は大事であった場面がよくありました😅．
使い方を知ってみての所感
「Start a review」と「Add single comment」の使い方は冒頭にもある通り色々な使い方があるので明確な正解はそこまで無いのかなぁと思いました．
例えば
- ウチではチーム全員がレビュアーになってコードレビューするので「Reviewers」は特に指定しない
- 「Add single comment」を使った方が Slack に通知されるのでレビューイが「お！今レビューしてもらってる！」とわかるようにしている
など聞いたことがあることを思い出しました．
私の場合，今までよくわからないまま使っていたので今回をきっかけに使い分けについて自分なりに整理できて良かったです．
「Start a review」を使った方法でしばらくはコードレビューしていこうと思います．
