blog/9 | ikuma-t.com

Gemfileにある`require: false`ってなんでしたっけ？

2022/5/28

に公開

Gemfileで度々でてくるrequire: false。ざっくり理解はしているけど、ちゃんと公式ドキュメントを読んでいなかったので、思い出しついでに読んでいく。

まずrequire: falseのそもそもの意味はBundler: gemfile🔗に記載があって、

false to prevent any file from being autorequired.

つまり、自動でrequiredしないようにするには、require: falseと書くことになる。

Bundlerを使用していない場合、通常requireを各ファイルで各gemに対して書く必要があるが、Bundlerにはロードを行うパスの解決を行うBundler.setupとそこで指定されたGemを自動的にrequireするBundler.requireという機能があり、これによりGemfile記載のgemは全て自動でrequireされる。

これを無効にするのがrequire: falseである（デフォルトがtrue）

どういう場面で使用するかというと、「依存関係は管理したいが、アプリでは使用しない」といったケースで使用する。例えばRakeタスクで自動的にデータを取得するのに使用しているけれども、アプリで使うのはデータであって、そのgem自体は使用しない、みたいな場合にrequire: falseを指定してあげるといった例がある。

「Bundler.setupとかBundler.requireとかあまり使ったことないんだけど…」となるものそのはずで、Railsの場合はフレームワーク側でそれが組み込まれているので普段は意識しない。

Bundker.setupはconfig/boot.rbに記載されている。

ENV["BUNDLE_GEMFILE"] ||= File.expand_path("../Gemfile", __dir__)

require "bundler/setup" # Set up gems listed in the Gemfile.

Bundler.requireはconfig/application.rbに記載されている。

require_relative "boot"

require "rails/all"

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)
...

Gemfileにある`require: false`ってなんでしたっけ？

公開日: 2022/5/28

ブログ用のコマンド試作その2

2022/5/27

に公開

ブログ用のコマンド試作の続き。もはや保存した瞬間にデプロイしてしまって良いのではと思ったので、ただただgit pushするまでのコマンドを組み込んだ

#!/bin/bash

if [ -e ~/blog/_posts/$1.md ]; then
    vim ~/blog/_posts/$1.md
    cd ~/blog
    git add ~/blog/_posts/$1.md
    git commit -m "feat: update post"
    git push
    cd -
else
    cp ~/bin/template.md ~/blog/_posts/$1.md
    mkdir ~/blog/public/blog/$1
fi

画像とかを入れていきたい場合は微妙な感じがするけど、そういう場合はエディタちゃんと開いてやるし、ターミナルでささっと学習メモをあげるにはこれで十分なのでは？と思っていたりする。しばらくこれで運用してみます。

ブログ用のコマンド試作その2

公開日: 2022/5/27

ブログ用のコマンド試作その3

2022/5/27

に公開

初回作成時に2回コマンドを叩くのはめんどいだろうということで、if文を変えた。

#!/bin/bash

if [ ! -e ~/blog/_posts/$1.md ]; then
    cp ~/bin/template.md ~/blog/_posts/$1.md
    mkdir ~/blog/public/blog/$1
fi

vim ~/blog/_posts/$1.md
cd ~/blog
git add ~/blog/_posts/$1.md
git commit -m "feat: update post"
git push
cd -

これでblog hogeとすれば、その瞬間に記事を書くことができる。

ブログ用のコマンド試作その3

公開日: 2022/5/27

ブログ用のコマンド試作その1

2022/5/27

に公開

雑に投稿するためのコマンドを作ってみた。ファイルがなければmarkdownファイルと画像格納用のディレクトリを作成し、ファイルがあればmarkdownファイルを開く。

#!/bin/bash

if [ -e ~/blog/_posts/$1.md ]; then
    vim ~/blog/_posts/$1.md
else
    cp ~/bin/template.md ~/blog/_posts/$1.md
    mkdir ~/blog/public/blog/$1
fi

あまりにも雑すぎるけど、これでどこにいてもターミナル上でささっとブログがかける。

1日1問、半年以内に習得シェル・ワンライナー160本ノック：書籍案内｜技術評論社🔗をみてシェルスクリプトに親しむか、もはやzxを使ってTypeScriptで書いた方がよさそう。

ブログ用のコマンド試作その1

公開日: 2022/5/27

ブログをNext.jsで作りました

2022/5/26

に公開

はてなブログのエディタをわざわざ開いて書いていくのが非常に面倒で、TypeScript→React→Nextの順で学んでNext.jsでブログを作ろうと思っていたけど、だいぶ時間がかかるので、ささっとtemplateを使って作りました（レイアウトだけ少し整えた）

Markdownをおいたら公開されるようにはなっているんですが、最小工数で記事公開まで持って行けるようにしたいので、コマンド一発で作業できるといいなあと思っています。

# これでmarkdownファイルと画像用のディレクトリが作成されて、適当にフロントマターを入れてくれる感じにしたい
$ blog sample-title

ブログをNext.jsで作りました

公開日: 2022/5/26

Google Meetで相手の画面やプレゼンテーションが見えないときの対処法

2022/4/18

に公開

Table of contents
相手が見えない…
結論
詳細
- バージョン
- 設定：受信時の解像度（最高）
終わりに

相手が見えない…

先日Google Meetでお話をする機会があったのですが、相手のプレゼンテーションやお顔がまったくみえないという事象に出くわしました…。

お相手の別の端末で会議に参加していただいたところ、すべて映っていたところから「これは自分側に問題があるぞ」と切り分けまでできたのですが、その時間では解決できず1時間音声+テキストで会話を続けました😅

終わってみて色々試してみたところ原因がわかったので、メモしておきます。

結論

設定 > 動画 > 受信時の解像度（最高）が「音声のみ」になっていると相手の動画全般が見えない。
「音声のみ」以外の選択肢に変更する

詳細

バージョン

確認したバージョンは以下の通りです。

OS：macOS Monetery バージョン 12.1
Chrome：100.0.4896.88（Official Build）（x86_64）

設定：受信時の解像度（最高）

原因はGoogle Meetの受信時の設定にありました。設定 > 動画 > 受信時の解像度（最高）を確認します。

相手の画面やカメラが見えていない時は、ここの設定が「音声のみ」になっていました。これにより音声しか受信しなくなるので、相手の動画はすべて見えないというカ$1リでした。

この設定は次回以降も保存されるそうなので、なにかの拍子にここを「音声のみ」にしてしまっていて、それが今回も引き継がれていたということになります。

終わりに

過去に「送信時の解像度（最高）」を高画質にしようとしたけど、カクツキすぎるので自動に戻したということがあって、おそらくその際に手が滑ったのでしょう…。

ネット上には「発信している側起因で見えない」ケースが結構転がっていますが、「受信する側起因で見えない」ケースはあまりなかったので、どなたかの参考になれば幸いです。

Google Meetで相手の画面やプレゼンテーションが見えないときの対処法

公開日: 2022/4/18

Vue3のReactivity TransformをJestでもコンパイルできるようにする

2022/3/15

に公開

要約

Reactivity Transformを使った$1をテストしていて、それが原因でJestが落ちるときは、@vue/[email protected]以上を導入しよう！

yarn add -D @vue/vue3-jest@latest

環境

※この記事は2022/03/15書いたものです。執筆時点ではReactivity Transform自体がExperimentalかつ、vue-jestのアルファ版でしか対応していないため下記のような対応が必要になりますが、しばらくすればここらへんは意識しなくても良くなるはずです。

Vue：3.2.26
Jest：27.5.1

前提：Reactivity Transformとは

Vue 3.2.25からExperimentalとして追加された$1ーマクロで、Vueが提供しているReactiveな値を.valueを経由せずに取得することができるようになります。

// 通常のrefimport { ref } from 'vue'const counter = ref(0)console.log(counter.value) // 0// Reactivity Transformconst counter = $ref(0)console.log(counter) // 0

公式ドキュメントでは以下の章で紹介されていて、refだけでなく、computedも$computedとして使用することができます。

vuejs.org🔗

問題：JestがReactivity Transformを解釈できない

今開発しているアプリはWebpackを利用しているので（正確にはWebpacker…殺せっ！）、ドキュメントの通り、明示的に設定に追記することでこの機能を有効化することができます。

vuejs.org🔗

module.exports = {  test: /\.vue$/,  loader: 'vue-loader',  options: {    reactivityTransform: true  }}

これでアプリ実行時はうまくいくのですが、$1に使用しているJestではWebpackは関係ないため、この構文の解釈ができずにエラーになります。

node:internal/process/promises:265            triggerUncaughtException(err, true /* fromPromise */);            ^[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "ReferenceError: $computed is not defined".] {  code: 'ERR_UNHANDLED_REJECTION'}

今回はこれを解消します。

対処：@vue/[email protected]以上を導入する

yarn add -D @vue/[email protected]もしくは@vue/vue3-jest@latestを実行します。

2022/03/15時点ではalpha4が最新版なので、こう書いていますが27.0.0-alpha.3以上を導入すればOKです。

これによりテスト実行時のログに、webpackで実行したときと同じようにexperimentalに対するログが出るようになり、Reactivity Transformが正しく解釈されるようになります。

[@vue/ref-transform] Reactivity transform is an experimental feature.Experimental features may change behavior between patch versions.It is recommended to pin your vue dependencies to exact versions to avoid breakage.You can follow the proposal's status at https://github.com/vuejs/rfcs/discussions/369.

解説

Reactivity Transformのみならず、Vueの仕様についてはGitHub Discussionsにて議論されています。

この中でJestへの対応に関する質問がありました。

github.com🔗

VueとAngularのコントリビュータであるCédricさんが「vue3-jest」に新しいオプションを加えたよという話をしています。それがこのPRです。

github.com🔗

READMEにも同様の内容が書いてあるのですが、27.0.0-alpha3以降は以下のオプションでReactivity Transformを解釈できるようになります。

globals: {  'vue-jest': {    compilerOptions: {      refTransform: false    }  }}

デフォルトではこれがtrueだそうで、先に述べた通りalpha3以上を導入すれば自動的にReactivity Transformが解釈できるようになるわけです。

おわりに

これを解消したはいいんですけど、まだ私のJestはエラーを出力しています。やばいですねっ！

Vue3のReactivity TransformをJestでもコンパイルできるようにする

公開日: 2022/3/15

【Rails】collection_selectで表示するテキストには、Procを指定できる

2022/3/3

に公開

事の発端

自分で作ったGem「jp_local_gov」を使って、自作サービスを実装しています。

f:id:ikmbear:20220303082449p:plain

実装にあたって、市区町村名のセレクトボックスが必要でした。

jp_local_govではView Template🔗に記載の通り、collection_selectで使用する候補を返すことを目的の一つとしたJpLocalGov.allというAPIを実装しているので、一見以下の形式で目的は達成できそうです。

f.collection_select :local_gov_code, JpLocalGov.all, :code, :city

たしかにこれでも動作としては問題ないのですが、cityとしか指定していないので、「市区町村名」しか表示されません。

日本には「$1府県は異なるけど、市区町村名が同じ市区町村」がそこそこ存在します。

JpLocalGov.all.group_by(&:city).select { |k, v| v.size > 1 }.map { |k, v| { k => v.map(&:prefecture) }}=>[{"伊達市"=>["北海道", "福島県"]}, {"松前町"=>["北海道", "愛媛県"]}, {"森町"=>["北海道", "静岡県"]},...

そのため、$1府県と市区町村を合わせてテキストに表示したかったので、雑に以下のようにやってみたのですが動かず。

f.collection_select :local_gov_code, JpLocalGov.all, :code, "#{prefecture}#{:city}"

collection_selectで表示するvalueとtextにはProcを指定できる

api.rubyonrails.org🔗

困った時のAPI Dockというわけでチェックしてみると、

The :value_method and :text_method parameters are methods to be called on each member of collection. The return values are used as the value attribute and contents of each tag, respectively. They can also be any object that responds to call, such as a proc, that will be called for each member of the collection to retrieve the value/text.

要はcollection_selectの第1引数に指定したオブジェクトが対応できるメソッドを呼び出すことができ、それゆえにProcも呼び出せるようです。

結果として、

f.collection_select :local_gov_code, JpLocalGov.all, :code, ->(lg) { "#{lg.prefecture} #{lg.city}" }

こんな感じにProcを渡してあげると、JpLocaGov.allで取得されたすべての市区町村がイテレーションされてlgにわたり、それぞれの「都道府県名市区町村名」として表示できるわけです。

f:id:ikmbear:20220303085115p:plain

【Rails】collection_selectで表示するテキストには、Procを指定できる

公開日: 2022/3/3

Formオブジェクトのロケールファイルの定義方法（i18n）

2022/2/23

に公開

Formオブジェクトを利用した場合の翻訳キーはどれ？
要約
前提
- 対象バージョン
- サンプルケース
RailsがModelのi18nを探索する手順
- バリデーションメッセージ
- カラム（画面表示項目）

Formオブジェクトを利用した場合の翻訳キーはどれ？

通常DBに紐づくモデル、つまりActiveRecord::Baseを継承したクラスに対応するフォームを作成する場合、次のような$1ファイルを作成することで、バリデーションメッセージや表示される項目を多$1することができます。

ja:  activerecord: # activerecordをキーにする    attributes:      user:        name: 名前        password: パスワード

一方DBへの保存だけではなく、複雑な$1を実装する場合にはFormオブジェクトを作って対処します。例えばフォームから入力されたデータを用いて、メール送信を行うような場合です。

Formオブジェクトは複数のモデルを扱ったり、DB以外の操作が伴うため、基本的にはActiveModel::Modelをincludeした形で実装します。

また、form_withからの$1判定を行うために、to_modelをオーバーライドし、メインとなるModelクラスに向けることもあります。

…こうなってくると、i18n用のi18nファイルをどうやって書いたらいいのかよくわからなくなってきたので、Railsがどのようにi18nファイルを解釈しているのか調べました。

要約

ActiveModelとActiveRecordはそれぞれi18n_scopeを実装していて、これによりActiveRecordファイルのトッActiveRecordルの探索キーが決まる。
Formオブジェクト側で行っている処理（例：バリデーション）はactivemodelをキーにする
to_modelをオーバーライドしてActiveRecord::Baseを継承したモデルを参照している場合、それらの表示に対する翻訳はactiverecordをキーにする

前提

対象バージョン

ActiveRecord：~> 7.0.0
ActiveModel：~> 7.0.0

サンプルケース

モデル：User

class User < ApplicationRecordend

フォームオブジェクト：UserForm

class UserForm    include ActiveModel::Model  include ActiveModel::Attributes  attr_reader :user  def initialize(user = User.new, **attributes)    @user = user    attributes = default_attributes if attributes.empty?    super(attributes)  end  validates :name, presence: true  # バリデーションがいっぱい  attribute :name, :string  # カラム定義も様々  def save    # 実際の処理  end  def to_model    user  endend

RailsがModelのi18nを探索する手順

バリデーションメッセージ

バリデーション用のエラーメッセージの組み立ては、ActiveModel::Error.generata_messageで行われています。

https://github.com/rails/rails/blob/main/activemodel/lib/active_model/error.rb#L64🔗

def self.generate_message(attribute, type, base, options) # :nodoc:      type = options.delete(:message) if options[:message].is_a?(Symbol)      value = (attribute != :base ? base.read_attribute_for_validation(attribute) : nil)      options = {        model: base.model_name.human,        attribute: base.class.human_attribute_name(attribute, { base: base }),        value: value,        object: base      }.merge!(options)      if base.class.respond_to?(:i18n_scope)        i18n_scope = base.class.i18n_scope.to_s        attribute = attribute.to_s.remove(/\[\d+\]/)        defaults = base.class.lookup_ancestors.flat_map do |klass|          [ :"#{i18n_scope}.errors.models.#{klass.model_name.i18n_key}.attributes.#{attribute}.#{type}",            :"#{i18n_scope}.errors.models.#{klass.model_name.i18n_key}.#{type}" ]        end        defaults << :"#{i18n_scope}.errors.messages.#{type}"        catch(:exception) do          translation = I18n.translate(defaults.first, **options.merge(default: defaults.drop(1), throw: true))          return translation unless translation.nil?        end unless options[:message]      else        defaults = []      end      defaults << :"errors.attributes.#{attribute}.#{type}"      defaults << :"errors.messages.#{type}"      key = defaults.shift      defaults = options.delete(:message) if options[:message]      options[:default] = defaults      I18n.translate(key, **options)    end

https://api.rubyonrails.org/classes/ActiveModel/Errors.html#method-i-generate_message🔗

抜粋するとこんな感じです。

def self.generate_message(attribute, type, base, options) # :nodoc:    # 1： 対象のクラスについて、i18n_scopeを実行し、キーを取得する。  if base.class.respond_to?(:i18n_scope)    i18n_scope = base.class.i18n_scope.to_s    attribute = attribute.to_s.remove(/\[\d+\]/)    defaults = base.class.lookup_ancestors.flat_map do |klass|      [ :"#{i18n_scope}.errors.models.#{klass.model_name.i18n_key}.attributes.#{attribute}.#{type}",        :"#{i18n_scope}.errors.models.#{klass.model_name.i18n_key}.#{type}" ]    end    # 省略  end  # 2. 取得できた情報でデータを翻訳文を作成し、つっこむ  key = defaults.shift  defaults = options.delete(:message) if options[:message]  options[:default] = defaults  # 3. 2で作成されたデータで翻訳処理を行う（ロケールに応じたファイルを選択する）  I18n.translate(key, **options)end

ここで肝になるのはi18n_scopeというメソッドです。このメソッドにより、activerecordを見にいくのか、activemodelを見にいくのかが決まります。

ではその実装はどうなっているのかというと、ActiveModelの場合、次のようになっています。

# Returns the +i18n_scope+ for the class. Override if you want custom lookup.def i18n_scope  :activemodelend

https://github.com/rails/rails/blob/75a9e1be75769ae633a938d81d51e06852a69ea3/activemodel/lib/active_model/translation.rb#L26🔗

一方で、ActiveRecordでも同じメソッドがオーバーライドされており、次のように実装されています。

# Set the i18n scope to override ActiveModel.def i18n_scope # :nodoc:  :activerecordend

https://github.com/rails/rails/blob/75a9e1be75769ae633a938d81d51e06852a69ea3/activerecord/lib/active_record/translation.rb#L20🔗

これにより、翻訳対象のクラスが

ActiveModelの場合は、activemodel
ActiveRecordの場合は、activerecord

が翻訳キーとして採用されることになります。

ここで、バリデーションメッセージについては、Formオブジェクト、つまりActiveModelで実装されたものです。そのため、エラーメッセージの翻訳キーはactivemodel始まりになります。

ja:    activemodel:        user_form:            name: 名前            password: パスワード

カラム（画面表示項目）

カラム（画面表示項目）の翻訳についても先のi18n_scopeで説明がつきます。

form_withでフォームを作成する際に、to_modelによって、ActiveRecordであるUser側にクラス判定が向くため、ActiveRecordのi18n_scopeが採用されます。

そのため、以下のような$1ファイルを記述します。

ja:    activerecord:        user:            name: 名前            password: パスワード

なおUserモデルに含まれない項目をFormオブジェクトに定義した場合も、翻訳ファイルはactiverecord下に記述することに注意が必要です。

以上Formオブジェクトでの翻訳キーの参照先についての調査でした。

Formオブジェクトのロケールファイルの定義方法（i18n）

公開日: 2022/2/23

Slapdashを使って、瞬間で Notionにアイデアを追加する

2022/2/17

に公開

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220217/20220217080548.png🔗

f:id:ikmbear:20220217080548p:plain

Notionは情報を貯めるには便利だけど、開くのは面倒

Notionも「辛い」と言われるくらいに普及してきましたね。英語版だけだったり、無料ユーザーはブロック数に制限があったりした時代が懐かしいです。

f:id:ikmbear:20220217073348p:plain やっぱり1つの情報を複数の表示形式で閲覧することができるのは非常に画期的で、自分もブログネタを管理するのに使用しています（同じDBをボードとカレンダーで表示して、コンテンツの状況と締切を一覧している）。

こうやって溜まった情報を閲覧するにはすごい便利なんですが、問題はちょっとリッチ & ゆるすぎて、新しい情報を登録するためにわざわざNotionを開くのが面倒くさいんですよね。

特にブログ記事みたいなア$1は、他の作業をしている時にふっと思いつくものなので、Notionを開くことによる$1が発生するのがネックでした。

そこでSlapdashというコマンドランチャーの機能を使い、Notionへの登録を簡略化したのですが、これが結構よかったのでご紹介したいと思います。

Slapdashの使い方

Slapdashとは

Slapdashは各種Webアプリを統合し、まとめて操作できるランチャーアプリです。

TrelloやAsanaといったプロジェクト管理ツールから、GitHub、Figmaといったクリエイティブツールまで、このアプリから一括で検索、追加、編集を行うことができます（※：アプリによって、操作できる範囲は異なります）。

slapdash.com🔗

f:id:ikmbear:20220217073457g:plain

例えばGitHubを連携した場合、GIFのようにどこからでもコマンドパレットを立ち上げ、自分が関与しているGitHubのIssueを横断して検索することができます（ここからIssueを選択し、登録・編集操作が可能です）。

f:id:ikmbear:20220217073556p:plain

価格についてはBasic、Pro、Teamsの3つのプランがありますが、今回紹介する範囲はBasic、すなわち無料で使える範囲での機能紹介になります（私もBasic会員です）。

f:id:ikmbear:20220217073617g:plain

ランチャー画面とは別に起動画面があり、ここからアプリを連携したり、Spaceと呼ばれる空間にリンクを突っ込んだり、自分専用のコマンドを作成することができます。

Notionと連携する

f:id:ikmbear:20220217073649p:plain

SlapdashはNotionにも対応しており、操作としては

ページの新規作成（Not DB）
DBに新たにページを追加
既存のページに対してコンテンツを追加

の3つに対応しています。

f:id:ikmbear:20220217073713p:plain

Notionを連携する場合は、Slapdashを起動してから「Apps」を選択し、

f:id:ikmbear:20220217073728p:plain

「App Store」からNotionを選択します（私の場合は接続済になっているので表示が異なりますが、新規接続の場合はConnectというボタンが表示されているので、それを選択します）。

f:id:ikmbear:20220217073743p:plain

この接続を行った時点で存在するNotionのページやDBに対して、Slapdashへと編集の許可が降りるようになっています。そのため、接続後に新しくNotionページやDBを追加し、それらに対してSlapdashから操作を行いたい場合は、Notion側でAPIを許容する必要があります（Notion右上のShare → SlapdashをInviteする）。

Slapdashから実行できるNotionの操作

Notion内の検索を行う

f:id:ikmbear:20220217073814g:plain

「Notion」と入力し、「Filter by Notion」を選択することで、Notionのページを横断的に検索することができます。また「Notion」と入力しなくても検索ワードを直接入力してもページやDBにたどり着くことができます。

SlapdashからNotionのページを作成する

f:id:ikmbear:20220217073856p:plain

「Notion」→「Create New Notion Page」と進むことで、単一のページを作成することができます。作成する際には作成場所となる親のページを指定します。

作成する際にページタイトルやコンテンツは指定できません。あくまでページを作成するのみです。

SlapdashからNotionのデータベースにページを追加する

f:id:ikmbear:20220217073919p:plain

「Notion」→「Add to Notion Database」と進み、対象のDBを指定することで、そのDBに新しくページを追加することができます。

紙芝居でイメージをご紹介しましょう🐵🦀

f:id:ikmbear:20220217073934p:plain

例えば私の場合だと、このようなプロパティを持ったブログネタ管理用のDBがあります。ここに新しくページを追加します。

f:id:ikmbear:20220217080735p:plain

対象のDBとして「ブログ」にカーソルを合わせTab or Enterキーを押します。

f:id:ikmbear:20220217075722p:plain

するとこのDBのプロパティとコンテンツを入力するためのフォームが出てきます。各プロパティには、Notionであらかじめ指定しておいたフォーマットに合わせて入力を行うことができます（リストやカレンダーなど）。

f:id:ikmbear:20220217075130p:plain

「Add」を押すと、作成した記事に対するアクションを指定することができます。今回は「Open in Notion」で作成した情報をチェックしてみましょう。

f:id:ikmbear:20220217075145p:plain

先程入力した内容がNotionに追加されました。Markdownも正しく反映されています。

追加したNotionのページにコンテンツを追加する

先ほどはNotionにページを追加する操作でしたが、追加したページに内容を追記することもできます。

f:id:ikmbear:20220217080935p:plain

「Notion」→「Add to Notion Page」と進み、ページを指定することでコンテンツを追加することができます。こちらも紙芝居で動作をみていきましょう。先程追加した「新しいブログ記事」に対して追加を行っていきます。

f:id:ikmbear:20220217075228p:plain

ページを選択すると、コンテンツの入力フォームが表示されます。こちらもMarkdownで内容を記述することができます。

内容を追記したら「Add」を選択し、先程と同じように「Open in Notion」で作成した情報をチェックしてみます。

f:id:ikmbear:20220217075241p:plain

ページの最下部に今追加し内容が追記されました！

Tips：templateを作成する

「このDBにテーブルを追加することがほとんど」「新規作成時はこのステータスで登録する」といった具合に、具体的なケースがある場合はSlapdashのテンプレート機能を利用して効率化することができます。

f:id:ikmbear:20220217080843p:plain

Slapdashから「Create Command」→「Template」と進みます。

f:id:ikmbear:20220217075309p:plain

テンプレートは連携しているサービスに対してそれぞれ作成できるのですが、今回はNotionへのDB追加のテンプレートを作成するため、「Add to Notion Database」を指定します。

f:id:ikmbear:20220217075328p:plain

まずはNotionのテンプレートを指定します。ここで指定した項目がSlapdashからの登録時のデフォルト値になります。

f:id:ikmbear:20220217075350p:plain

Notion側の設定を終えたら、ページをスクロールしテンプレート自体の設定を行います。

Nameにはテンプレートの名前を、その他アイコンや説明を追記します。$1を設定しておくと、Slapdashのコマンドパレットにその$1を入力することで、テンプレートを呼び出すことができます。

設定が完了したら「Create Command」を押して、実際に試してみましょう！今回はwtという$1を貼ったので、これをキーに呼び出してみます。

f:id:ikmbear:20220217075428g:plain

呼び出した入力画面に、あらかじめ設定した内容が反映されていることが確認できました。

おわりに

というわけでSlapdashを使ったNotionの更新フローの紹介でした。

私はこれを使って、冒頭にも述べた通りブログネタを登録して思いついた時にア$1を追記したり、やりたいことリストを追加したりしています。

思いついた時に登録することでア$1を漏らさず、かつどこからでも登録できることで現在のタスクから大きく$1をすることもなく、快適に生活できています。

SlapdashはNotion以外のツールにも対応していますので、ぜひ試してみてください。

Slapdashを使って、瞬間で Notionにアイデアを追加する

公開日: 2022/2/17