パルカワ2

最近はFlutterをやっています

Notionのウェブとデスクトップアプリの両方を使う

仕事ではNotionを使っているがウェブ版で文章を書いていると変にもたついたりすることがあった。なので書くときはデスクトップアプリを使いたい。

読むときもデスクトップアプリを使うつもりだったのだが、GoogleカレンダーからNotionのリンクを踏むとNotionアプリを開くかどうか聞かれてしまう。Always open Notionを選んでも毎回聞いてくる。我慢していたのだけど、さすがにめんどくさくなってきた。

そこでウェブを開いて、必要な時にショートカットでNotionアプリを開けばええやんと思ったのだが、ウェブのメニューを見る限りショートカットで開けなさそうだったので、RaycastのScript Commandで解決してみよう!ということでやってみた。

1. Create Script Command

#!/bin/bash

# Required parameters:
# @raycast.schemaVersion 1
# @raycast.title open-notion-app
# @raycast.mode silent

# Optional parameters:
# @raycast.icon 🤖

# Documentation:
# @raycast.author hisaichi5518
# @raycast.authorURL https://raycast.com/hisaichi5518

# Get URL from Arc
url=$(osascript -e 'tell application "Arc" to get URL of active tab of front window')

# Check if it's a Notion URL
if [[ $url == *"notion.so"* ]]; then
  # Convert to notion:// protocol
  notion_url=$(echo "$url" | sed 's|https://|notion://|')
  # Open in Notion app
  open "$notion_url"
  echo "Opened in Notion app"
else
  echo "Current tab is not a Notion page"
fi

2. ショートカット設定

自分の場合は、alt+nにした

3. Notionのウェブとデスクトップアプリ側の設定

ウェブは、「Open links in desktop app」を無効にした。

デスクトップアプリでは、「Open Notion links in browser」「Close redirecting browser tabs」を有効にした。

所感

AppleScript便利

DataviewからBasesに移行

自分のObsidiainのノートには、Index noteがある。

例えばDaily noteのindex noteは、Daily noteに関する説明とDaily note一覧が出るみたいな。今までnoteの一覧を出すのをDataviewでやっていたけど、そんな複雑なことやっていないし、やりたくもないのでBasesに置き換えた。

便利!Obsidianで一括置換の仕方がわからなかったからVSCodeでエイヤと置き換えた。Markdownで持っているとこういうことがしやすいのでいいですね。

あとObsidianのファイルエクスプローラーを表示していたけど実験的にやめてみた。こんな感じで左下にBasesを出している。

とはいえ、Index note自体ではなく別途Basesを用意しているので微妙だなというのと結局こういう一覧ってざっくりふりかえりたいときには見るけど、頻繁には見ないのでいらないかもしれないと気がしている。

リファクタリングは保守性が下がっているからする特別な仕事ではなく常に行われるもの

自分たちの仕事は、訂正をし続けることである。そして、訂正にはプロダクトの振る舞いの訂正と技術的な訂正がある。みんなだいすきMartin Fowlerはリファクタリング(第2版): 既存のコードを安全に改善するで、開発時には機能追加とリファクタリングという2つの帽子を頻繁にかぶり直す必要があるという話をしている。自分が言うプロダクトの振る舞いの訂正とは機能追加などであり、技術的な訂正とはリファクタリングなどのことである。

ソフトウェアを開発しているとき、 私は頻繁に二つの帽子をかぶり直しています。 新たな機能 を追加しようとしていると、 コードの構造を少し変えれば簡単に機能追加できることに気づきます。 そこでリファクタリングの帽子にかぶり直します。 (略) 重要なのは、 どちら の帽子をかぶっているのか、 およびそれにより生じるプログラミングの仕方のちょっとした違い を、 常に意識しておくことです。

Martin Fowler. リファクタリング 既存のコードを安全に改善する(第2版) (p.47). Kindle 版.

プロダクトの振る舞いの訂正だけをとにかく積み重ねて後から技術的な訂正をすればいいと思うのかもしれないが、訂正はあとになればなるほどやりづらくなる。

なので、プロダクトの振る舞いの訂正と技術的な訂正の両方を漸進的に実施していくことが重要であると自分は信じている。

つまり、何が言いたいかというとリファクタリングは保守性が下がっているからする特別な仕事ではなく常に行われるものであるということですね。

EM終了!

3年ほどエンジニアリングマネージャーとして活動してきたが、自分がEMのチームと別のチームが合体し、そのチームのEMは別の人に任せることになったのでエンジニアリングマネージャーではなくなった。

自分が直近興味を持ってる労働のテーマが比較的マネジメント寄りのテーマだったのでどうしたもんかという感じだけど、自分が手を動かすことで解決する領域はあるしそこで得た知見を広げることはそこそこテーマに沿う活動かなと思うので、最近はいろんな実装を書き直したりDesign Docを書いたり資料を作ったりしています。

X-E5買った

買おうかな!うーん!やっぱ買わない!!と決めたはずが、触ったら欲しくなってしまい買ってしまった。散歩がかなり捗るようになった。冬はパジャマの上に羽織るだけで散歩に出れて便利

FUJI X Weeklyにある設定にするとバッキバキの写真になったりしておもしろい。

Design Docは読み手のことを考えて書く

最近Design Docを書いている。25年の6月にDesign Docのフォーマットを本部で見直してチームとしてもここに書きまくろう!と決めたのだが、そこから我々のチームだけで6ヶ月くらいで50本くらい書いている*1

そうしてDesign Docを書いたり読んだりしていて、Design Docは読み手のことを考えて書く必要があるなと思うようになった。

  • 結論は極力短くする
  • 結論は早めに見せる
  • 1つのDesign Docに1つのことを書く。多くなりそうだったら分割する
  • 調査のときに書いたメモはDesign Docからリンクするようにして、Design Doc自体には書かない
  • AIは書きまくるので、そのままコピペせずに必要な情報だけに添削する
  • 書き手向けのテンプレート文言は消す
  • 自分で「何も知らないフリ」をしながら読み返して添削する

まとめ

ドキュメントを書くのは、コードを書くのと同じだよね〜という話を同僚としていた。自分も完全に出来ている気はしないが気を付けてやりたいねという感じもコードと一緒ですね。

*1:とはいえ書いてる途中のものも多くある

画面のWidgetテストはなにをテストするべきか

最近はよくWidgetテストを書いている。Presentational Widget と Container Widgetに分けていて、Presentational Widgetは、Riverpodなどに依存せず、見た目のことにだけ集中出来て大変よい。テストも見た目のテストのことだけに集中できる。

zenn.dev

Container WidgetがPresentational Widgetを使うという関係性なのだが、Container WidgetのテストではPresentational Widgetでテストしたことはテストしない。小さくテスト出来るのであれば、Presentational Widget側でテストするべきだと思う。

一方で、Widgetは他のWidgetの影響を受けやすいように感じる。例えば、状態AのときにBとCの項目が表示されていて、状態Dのときは表示されていないとか。1つのWidgetで完結していればいいが、離れている場所にあるとかだと難しい。そのときはうまく連携しているのかのテストを書く。Presentational Widgetに変更が入るとContainer Widgetのテストもコケて正直めんどいが、変更が入ったことに気づけてどのように変化するのか見れるのは良いことだと思う。

加えて、妙に長いテキストが入ったときとか文字サイズが変わったときとか、Widget同士で干渉してRenderFlex Overflowが起きないかというのは見たいように思える。Presentational Widgetごとに確認しても、結局他Widgetとの関係が影響するように思うので、広めで見てもいいように思える。

このあたりはGolden testである必要はなく、ランダムの値を使ってProperty based testingのようにテストするというのも出来て面白いかもしれない。