以前は Übersicht で simple-bar というウィジェットツールを使っていた。

このウィジェットを使っていた主な目的としては、 yabai というウィンドウマネージャを使っている中で、どのデスクトップにどのアプリケーションを置いているかなどが可視化されていると嬉しいというのが最も大きい。
このウィジェットツールは Mac の標準のメニューバーを代替することを想定しているものなので、日時に表示はもちろん、個人的には Spotify のステータス表示および再生・停止を行うウィジェットを便利に使ったり、自分でカスタマイズして MeetingBar の表示および次のミーティングへの参加ができるウィジェットを用意して、普段は OS が用意しているメニューバーを必要としない状態にしていた。

が、いくつか問題があって代替を探していた。

主な問題は何かというと、

• 時折、負荷がかかっていそうな気配を感じさせる
  • CPU 使用率が跳ねたり、ファンが全力で稼働している音がしていた
• ローディング状態が続く
  • 各ウィジェットが shell を定期実行してその結果を表示、という挙動をしているのだが、細かく大量にコマンドを実行しているためか、おそらく待ち行列が発生してローディング状態になって何も情報が得られない、という状態に結構なっていた

あたりで、特に後者はメニューバーの代替としての価値をほとんど失ってしまっているので時間を見つけて解消したいと思っていた。

simple-bar の代わりになりそうなものを探して、以下の２つのどちらかをためそうと考えた。

• simple-bar-lite
• SketchyBar

前者は simple-bar の軽量版ということで、導入コストが低そうなのが魅力だった。
が、問題の根本がもし Übersicht なのであれば、 simple-bar-lite を導入しても問題が解消しない可能性があった。

ということで、 SketchyBar を試すことにした。

実は SketchyBar の導入は Übersicht を導入したときにも検討をしていた。のだけど、調べてみたところ結構導入が大変そうだったので、一度見送ったという背景があった。

とはいえ、今回はもう腹をくくってこれを導入しよう、ということで、 Share your setups · FelixKratz/SketchyBar · Discussion #47 · GitHub から様々なセットアップを探して、ひとまずこれにしよう、というものを決めてそれを元に自分用にカスタマイズをした。

まずは、各デスクトップで開いているアプリケーションの表示部分をカスタマイズ。 4K などのモニタを使っているときは良いが、 FullHD のモニタではデスクトップ数が多いと横幅を広く取りすぎるので、アプリケーションがないデスクトップの表示をコンパクトにして、代わりに今アクティブなデスクトップのアプリケーションアイコンを省略しないようにした。

Spotify の表示についても参考にしたものでかなり整っていたが、再生・停止等の操作はポップアップメニュー経由で行う前提になっていたのと、再生していないときには表示領域に何もでなくなってしまうので、アイコンを常時表示にして、アイコンをクリックするだけで再生と停止を行えるようにした。

MeetingBar については自分で実装してワンクリックで次のミーティングのページを開けるようにした。これについては simple-bar 用に自分で用意したスクリプトをそのまま流用できたのでそんなに大変じゃなかった。

SketchyBar を導入して Übersicht を使っていたときの問題は解消したかというと、今のところ解消していそうな気配を感じている。
ファンが唸ることはなくなったし、ローディング状態にもならない。
さらに、 Übersicht から SketchyBar に置き換えたことが直接的な要因かは定かではないが、バッテリーの持ちが大幅に改善した。最近、長時間のオフラインミーティングなどで、途中でバッテリーが尽きてしまう問題を抱えていたが、かなり持つようになったことでこの問題が解決したことは副次的効果としては非常に嬉しかった。

これは Übersicht も同様だが、導入に際してどういう仕組みであるかを理解するまでのコストが高い。一方で、仕組みを理解してしまえばカスタマイズは容易といえる。
ということで、自分のやりたいことができるようになってきたところなので、時間に余裕ができたらもう少しカスタマイズしたいな、と思っている。
とはいえ、どんなカスタマイズをすると便利かの鮮明なイメージはまだ持っていないので、使いながら色々と考えてみようと思う。

参加するまで

僕の中では YAPC は Perl のカンファレンスではあるので、「最近 Perl 書いてないしな」というのと「勤め先では Perl を使ってないからスポンサーにはならないだろうし、そうすると宿泊費も交通費も自腹だろうから、まとまったお金を捻出できるかわからないしな」などと考えて迷ってはいた。
まあ結局、「行かないで後悔するよりは、行って後悔した方がいいな」と判断してお金をかき集めて行くことにしたのだけど。

宿は早めに取っておこうと1ヶ月前に確保。
移動は新幹線で、いい席へのこだわりとかあったわけでもないので1週間ちょっと前に予約。
ただ今回は普段と比較して新幹線に乗っている時間が思った以上に長かったので、快適な席をとった方が良かったな、と思う。とはいえ行きは快適だったし、帰りに快適でなかったのは隣の席の人のいびきが酷いことに起因しているので、いい席を確保するとかそういう話ではないが……。

準備

流行り病の影響でこの手のイベントが開催されなくなっていた時期、仕事も在宅が中心になったりと環境の変化が大きかったため、手元にいろんなものがない状況だった。

このイベントのためというわけではないけど、実は天候に左右されずに履ける靴がなかった。
持っていたのは全く防水性のないウォーキングシューズと、完全にフォーマル向けの革靴のみ。
ここ数年、梅雨の時期なども引きこもることによってしのいできたが、出社の頻度も徐々に増えてきており、このままではまずいということで昨年末頃に雨や雪の日も履ける靴を一足調達した。
当日の天候がどうなるかわからなかったので念のためこの靴を使用し、広島にいる間は雨に見舞われることもなく順調だったが、帰りに駅から自宅までの移動のタイミングで雨が降っていたので結果的にこの靴を用意しておいてよかったと言える。

鞄も別件で昨年末頃に新調しており、今回の2泊3日もこれに助けられた。
以前使っていた鞄は PC と着替え両方を詰め込むにはスペースが足りず、1つにまとめられずにいたが、新調した鞄は2泊3日分くらいであれば余裕を持って受け入れられる大きさだったため、宿泊を伴う旅行としてはとても久しぶりとなる鞄1つでの参加ができた。

在宅勤務が中心となったタイミングで携帯電話周りを見直しており、現在は iPhone 12 mini を使っている。
もう3年以上使っているということもあるが、やはり小さい端末はバッテリーも小さく、今回は特にバッテリーが全く持たなくて困った。
イベント当日は PC も iPhone も夕方頃には完全にバッテリーが尽きてしまっており、これは準備不足だったと言わざるを得ない。
会場での給電は基本的に NG だと考えている（運営が OK 出した場合を除く）ので、これについては自分で解決策を用意しておくべきだった。
普段あまりにも出かけないのでモバイルバッテリーを用意することを完全に失念していた。

また、回線契約も同じタイミングで見直しており、普段は Wi-Fi で事足りるため提供されるデータ通信量の少ないプランに乗り換えていた。
この手のプランは非常に安く助かっているが、用意されているデータ量を超えるとただちにそれなりの金額が加算されてしまうため、外出が多い月などはデータの残量を気にする必要がある。
これに対しては、少し前に別件でモバイルでのデータ通信が必要な機会があり、その際に加入した povo に助けられた。
povo は「テザリング可能」で「24時間使い放題」が330円という、普段全く使わないがある1日だけめちゃくちゃ使うというユースケースに対して非常に刺さるプランを用意しており、今回もこれに助けられた。
このプランは驚くべきことに、現在は まだ 24時間といいつつ、 翌日の23:59まで 使い放題であるため、今回はイベント当日の朝にプランを購入して、翌日のアフターイベントから帰宅までを24時間（をオーバーしているが）の範囲でカバーすることができる。
（注：公式でもこの私用については 当面の間は と表現しており、これが正規の仕様ではない。参考： https://povo.jp/spec/topping/24/ ）

ちなみにカメラを忘れたので、ほぼ写真を取らず、ここにも画像は一切掲載されません。

イベント当日

前夜祭、当日とまあ魅力的なトークが多かった印象だった。
最初に書いたように自分は YAPC に対して Perl のカンファレンスというイメージを未だに持ってはいるものの、実際にはもっと広い範囲のテーマを許容していることは理解しており、そういう意味でも1日開催なのがもったいないくらいに様々なトークが用意されていたと思う。
（とはいえ、スケジュール調整の問題も体力の問題もあるので1日開催の方が個人的にはありがたいわけだが）

最初のトークセッションの一つである『コミュニティと共に生きる』は共感できる部分もあれば、それは生存バイアスというか幸運によって成り立っている部分もあるよな、と思ったりもしたけれど、今回の YAPC の参加者の半数以上は YAPC 初参加らしく、若い人たちには良い影響のある話かもなあ、と思ったりしました。
実際のところ、継続して同じコミュニティに居続けることに正解不正解なんてないと思うけれど、少なくともコミュニティって属しているだけじゃなくて、その中で自分が何かをやっていかないと意外と簡単に消滅してしまうので、そういった意味でも何かしらのコミュニティに積極的に関わっていく経験というのはしておいて損はないものだと思う。

個人的に最も印象に残っているのはパスキー認証の話で、今の自分の関心領域に近いこともあり、非常に興味深く楽しむことができた。また、ライブコーディングをしてくれたのも個人的には嬉しかった。
ただまあ、前提となる知識がそれなりに必要なジャンルではあるし、40分では物足りなかったかもしれない。

杜甫々さんのキーノートは、個人的には結構刺さったし、あれは刺さる人多かったと思う。
インターネットが普及していく中で、かなり初期の頃から変わらずコンテンツを育て続けている様子というのは、その裏側を意識すると圧倒的なものを感じてしまうけれど、こういったものも人の情熱や好み、そしてなにより継続する力によって支えられているんだなあ、というのをひしひしと感じました。
もちろん僕も WWW 入門にはお世話になりました。

LT は全体的に勢いがあって、「やっぱり LT はこうでなくちゃ」みたいな気持ちになった（けど実際のところそんなに LT はこうあるべき、みたいなのはないと思っている）。

他にも面白そうなトークいっぱいあって、枠被りで見れなかったものが多いので動画公開を楽しみにしています。

スポンサーブースは一通り回ろうと思ったが、1箇所での話が長くなってしまうことによって、結局全てのブースで話をするだけの時間がなくなってしまった。
コミュ力が皆無なので、話始めるのも難しいし、話を終えるのはもっと難しい。

懇親会では以前一緒に働いていた人の近況について色々聞けてとても懐かしい気持ちになった。
「◯◯さんも入社してもう8年目だけど〜」みたいなことを言われて「えっ」となったり。
（そんな昔でしたっけ……？　となって計算してみたらそんな昔でした）

イベント会場でのランチ等もそうだし懇親会もだけど、提供される食事の量が結構多そうで、非常に美味しいけどそんなにたくさんは食べられない……という気持ちにもなったり。
（そうはいっても食べようと思えば全然食べられたのだけど、美味しい食事はメインの目的ではなかったので、色んな人と話したりしていたら食事を摂る時間があまりとれなかった。それはそれでもったいないことをしたな、とも思う）

会場の椅子で宣伝されていた Perlbatross は非常に面白かったが、それに時間を割いてしまってはイベントに来た意味が薄れてしまうという感じだったので、現地ではほどほどにしてホテルに戻ってから楽しませてもらった。

周辺イベント

スポンサー企業が開催する懇親会的なイベントには参加しなかった。
これは体力的な問題に起因するもので、なるべくしっかり睡眠を取って、良い状態で YAPC に参加したかったからだ。
昔と比べて体力が衰えたというわけではなく、昔と比べて自分の体力への理解が深まったからとれた選択だと思う。 ただ、開催翌日の「オフラインだからできる話」はしっかり聴講してきた。こういう場所でしか話されないオフレコトークは総じて価値が高いと思っている。
残念ながら「オフラインだからできる話」なのでここにうっかり感想を書くこともはばかられるため、これ以上の言及は控える。

他の非公式なイベントには参加しなかったが、せっかく遠方まで来たのだからもう少し参加しても良かったかもしれない。

振り返り

前職の方と話す機会を得たり、過去の YAPC で親しくしていただいた方々と話せたりしたこともあり、同窓会的な意味でも十二分に楽しめたと思う。
遠方の（宿の確保が必要な距離での）カンファレンス参加自体は珍しいことではないが、業務外で自腹で、というのはとても久しぶりで、事前に懸念していたとおり、それなりの金額を使った。
今後も参加するためには、普段からこういうイベントのために予算を押さえておく必要がありそう。

しばらくオフラインのイベントから離れていたのだけど、今年に入ったあたりからまたそういうイベントに参加していこうという気持ちになっていたので、ちょうど良いタイミングで慣れ親しんだ（？） YAPC に参加できたのは非常にありがたかったです。

次回もあればなるべく（予算が許せば）参加したいと思っているので、今回の反省を活かせるようしっかり準備しておきたい。

Web で開発していると、様々なサービスのアカウントでログインする機能を作ったりとかその他諸々、 OAuth2 や OIDC のお世話になることがある。
で、そういったものを利用するソフトウェアの開発に関わっていると、試しにリクエストを行うことも多々あるわけで、その度にアクセストークンを手動で取りに行くのって面倒だな、と思っていた。

実際に開発が終わってしまえば、使う分にはアクセストークンを意識することはないが、底に至るまでの間にアクセストークンがほしいなというシーンがあり、そういうときに簡単にアクセストークンを取得したいな、ということでコマンド一発でアクセストークンを取れるツールを作ってみた。

give-me-accesstoken

とはいっても、これはあまり汎用的に使えるものではないと思うし、とりあえず自分や自分の周囲の同じようなことをしている人が使えればいいかな、ということでサポートしている範囲は最小限です。

クライアント認証方式としては client_secret_post と private_key_jwt をサポートし、 authorization code grant と client credentials grant の2種類に対応している。

authorization code grant の場合は普通、途中でブラウザに飛んでブラウザ上でログインをしてからツールに戻ってくるという手順になるので、そういった挙動には対応している。
ひとまず Google と GitHub では動作の確認をしている。
ただ、自分が使いたい対象の一つが、この手法では上手く動かないことがわかっており、どうも Cookie にセッション情報がないと認可リクエストを通せないようだったので、そのケースに対応している。
これはあまり正攻法ではないし、複数の問題を内包してしまう（パスワードを設定ファイルに直書きする必要があったり、 MFA に対応できなかったり）ため、これが使われることはあまり望んでいない。
（しかし自分が必要としているから対応しているので、当然自分は使う）

しばらくは自分で使ってみて、問題なさそうであれば自分の周囲の人たちに紹介してみようと思う。

Arc とはなにか

Arc from The Browser Company

Arc は2023年9月現在、 Mac OS や iOS に対応しているブラウザです。
Chromium エンジンを採用しているものの、見た目や使い方は大幅にカスタマイズされているため、ファーストインプレッションでは Chrome とは結構違うように思う方も多いのではないでしょうか。

Arc は2022年にベータ版としてリリースされ、 wait list に入っている人に順番に配布されてきました。
今年の7月25日にバージョン 1.0 として正式リリースされ、そのタイミングから誰でもダウンロードして使えるようになっています。

Arc の特徴

Arc はエンジンこそ Chromium を採用していますが、 Google Chrome などの同エンジンを採用しているブラウザとの違いもかなりあります。

縦型タブを採用

古来（？）、一部の Firefox や Chrome ユーザが拡張機能で実現してきた縦型タブが標準で採用されています。
現在のモニタは以前よりアスペクト比が高く横に長いものが多いため、縦型タブの方がスペースを有効活用できるケースが多そうです。

ブックマークがない

これは正確な表現ではなく、ブックマークに相当するものとして、 “Favorites” と “Pinned” があります。
“Favorites” はサイドバー上部にアイコンで表示され、同じプロファイルの全てのスペースに表示されるため、頻繁にアクセスするサイトを登録しておくと便利です。
対する “Pinned” は “Favorites” の下に表示され、タブ自体を閉じてもタブのリストに残り続けます。そして再びタブを選択するとそのサイトをロードしてくれます。
従来のブックマークに近いのは “Pinned” でしょうか。 “Pinned” にはフォルダも追加することができ、タブを分類して整理することも可能です。

タブが自動的にアーカイブされる

そして “Pinned” の下に通常のタブが表示されるのですが、これらは放っておくと勝手にアーカイブされます。
デフォルトでは12時間でアーカイブされる設定になっており、タブを開きすぎることを抑止してくれます。
タブがアーカイブされるまでの時間は12時間、24時間、7日間、30日間から選ぶことができます。
僕は自分の仕事におけるタブのライフサイクルに合う7日間を設定しています。
つまり1週間放置しているタブは勝手にアーカイブされるようにしています。
この設定だと、複数の調べごとをしているときなどタブが一時的に膨大な数になることはありますが、無限に放置されることはないため、気がつけば開いているタブが3桁を超えていた、という惨状を避けることができます。

タブに自由に名前をつけられる

通常は開いているページのタイトルが表示されているタブのラベルですが、リネームできます。
短期的に閉じられるタブでは特に使いませんが、 “Pinned” のタブでは非常に便利です。
（下の方で実際の使用例も記載しています）

1ウィンドウで複数プロファイルを扱える

Google Chrome を使っていたときは、個人用プロファイルと仕事用プロファイルを別で開いて使っており、複数の会社の仕事などしているとプロファイルが3つ以上になることもありました。
Chrome では異なるプロファイルで開いたタブを1つのウィンドウにまとめることはできないため、最低でもプロファイルの数だけウィンドウを開く必要がありました。
僕はタイル型ウィンドウマネージャを使っており、ウィンドウの数が増えると1つあたりのウィンドウの領域が狭くなっていくため、ウィンドウの数が増えることは僕にとって好ましくありませんでした。
Arc はスペースという概念を持っており、これがいわば従来のブラウザにおけるウィンドウみたいなものになるのですが、アプリケーションとしてのウィンドウは1つのままでどのスペースをアクティブにするかを選択することができます。
また、スペースごとにプロファイルを選択できるため、1つのウィンドウの中に全てのプロファイルをまとめることができます。
僕の場合は、普段は個人用プロファイルと仕事用プロファイルで1つずつスペースを用意しており、1つの仕事をちょっとペンディングして別の大掛かりな仕事に手を付けるときなどは仕事用プロファイルのスペースを追加する、という運用をしています。

分割ビューに対応している

Arc はなるべく1つのウィンドウで完結するように工夫されているのか、1ウィンドウの中で2つのページを開くことができます。
左右あるいは上下に分割して、片方のページを参照しながらもう片方のページで何かしらの操作をする、といったことが1つのウィンドウの中でできます。

Chrome 拡張が利用できる

先に書いたように Chromium エンジンを採用しており、 Google Chrome の偉大な資産である Chrome 拡張を使うことができます。
Chrome 拡張は Google Chrome の価値を高める存在であり、これを利用できることは新興ブラウザにとっては大幅なアドバンテージでしょう。
僕はプロファイルごとに Google アカウントでログインしているので、それぞれのプロファイルで Chrome を使っていたときにインストールしていた Chrome 拡張を引き継げました。

個人的に便利に思っていること

一部のサイトはカーソルホバーで情報を閲覧、選択できる

これはあまり対応しているサイトが多くないのでそこまで便利かというと、という気持ちもありますが対応しているサイトに関しては非常に便利なので紹介します。

たとえば Google Calendar を “Favorites” か “Pinned” に入れておくと、対象のアイコンもしくはタブにカーソルを合わせるだけで現在時刻から直後5時間程度の予定がバルーンで表示されます。

他には GitHub のプルリクエストのページを “Favorites” か “Pinned” に入れておくと、カーソルを合わせるだけで unread PRs の一覧をバルーンに出してくれます。
これは数が少々多くてもスクロールでき、なおかつ選択することでそのプルリクエストのページを開くことができます。

“Pinned” のタブは閉じても残るため、何度もアクセスするページを登録しておくと便利

僕の場合は仕事で関わっているリポジトリの Issue/PR の一覧ページを3つに分けて登録しています。

• my Issues: https://github.com/{org}/{repo}/issues/assigned/risou
• my PRs: https://github.com/{org}/{repo}/pulls/risou
• review tasks: https://github.com/{org}/{repo}/pulls?q=is%3Apr+is%3Aopen+user-review-requested%3A%40me

これで自分が担当している Issue、自分の作った PR、自分のレビューを待っている PR を漏れなく確認することができます。
そしてこれらのタブにはそれぞれわかりやすいように my Issues, my PRs, review tasks というラベルをつけています。

“Favorites” や “Pinned” に分割ビューをそのまま保存できる

分割ビューは例えばマニュアルを見ながら操作をする、といったときなど使いどころの多い便利な機能ですが、 Arc はこの分割ビューをそのまま “Favorites” や “Pinned” に入れることができます。
つまり「マニュアルページ」「操作画面」を左右に並べた状態でブックマークができるようなものです。

Note/Easel という独自機能がちょっとしたメモ代わりに便利

いわばブラウザに備え付けられているテキストメモ機能とホワイトボード機能のようなものです。
Note は一時的なメモを残したり、文章を整えたりと非常に使い勝手が良いです。
Easel は Web ページを埋め込むことができます。複数の監視サービスのページを埋め込んでマイダッシュボードみたいなものを作ったりすることもできます。テキストや画像も入れることができるため、カスタマイズ性も十分です。

Little Arc がちょっとした用途に便利

Cmd+Option+N で開くことのできる Little Arc という一時的な別ウィンドウは、ここまで1つのウィンドウに全てを集約してきたが故の使い勝手の悪そうなイメージを払拭してくれると思います。
チャットツールに貼られたリンクをクリックする度に Arc に新しいタブが開かれることを望む人もいれば、そうでない人もいます。
Little Arc はちょっとページを開いて閲覧することはもちろん、そのまま Arc 本体にそのタブを開きたい場合にはボタン1つ（あるいはショートカット1つ）で Arc にマージすることができます。
また設定で Little Arc を経由せずに Arc で開くサイトを指定できたりする点も便利です。他のアプリケーションから開かれるページが全て Little Arc なのは逆に面倒だからです。

個人的にここは微妙と思っていること

Cmd+Shift+T で復元されるタブが直前に閉じたものではないときがある

閉じた直後にもう一度開きたい、となって Cmd+Shift+T を打つとしばらく前に閉じたタブが開かれたりする。
Archived Tabs を見に行けばあるのでそこから辿り着けるが、この挙動は復元されるタブが直感的にわからなくなってしまい不便。

Ctrl+N で新しい Note が開いてしまう（デフォルトのキーマップの場合）

キーマップを変更すれば良いだけではあるのですが、開いているページのテキストフォーム内でカーソルを下に移動するために Ctrl+N を押していると気づいたら New Note が “Pinned” に作られていたりします。
Mac OS の操作との重複なのでデフォルトで他のキーに割り当てられていてもいいのになあ、と思います。

Note でコードブロックが表現できない

Note は個人的には初期の Dropbox Paper のような使い勝手だと思っています。
見出しや太字・下線、リストなどに対応しているためちょっとしたドキュメントを作るのには便利です。
また、画像を差し込んだりリンクを設定することもできます。
一方で、テーブルやコードブロックを入れることはできません。
コードブロックとは言わないまでも、コードスニペットを貼り付けた際にその部分だけ等幅フォントに変えられると便利なのにな、と思っています。

“Pinned” が肥大化しがち

サイドバーには上から “Favorites” 、 “Pinned” 、そしてその他のタブという順に並んでいます。
タブが増えてくるとスクロールが発生しますが、 “Favorites” は常に最上部に残り続けます。
そのため “Favorites” は厳選しておくことが推奨されます。
“Favorites” が肥大化するとスクロールで表示される部分が狭くなってしまい、使いづらいためです。

そうするとブックマークしておきたいページのほとんどは “Pinned” に入ります。
“Pinned” はフォルダを置くこともできるのでうまく整理すればかなりの数を入れることはできます。
しかし Note や Easel は “Favorites” か “Pinned” にしか置けないため、ちょっとしたことで Note を作ったりしているとすぐに “Pinned” が肥大化します。
最終的にはその他のタブがスクロールしないと表示されない状態になり、これはあまり便利ではありません。
“Pinned” を整理しようにも、フォルダはフォルダで1つ分のスペースを使ってしまうので限界があります。 しかしまあ、これは使い方の問題もあるので Arc が良くない、という話ではないと思います。

Arc を使って何が変わったか

一番大きな変化としては、ブラウザウィンドウの乱立、タブの増殖が抑制されたことだと思います。

以前はブラウザが複数ウィンドウ、3桁以上のタブを開いている状態が常となっていました。
これが大幅に改善したことは非常に良い体験でした。
よくアクセスするページにはよりアクセスしやすくなりましたし、同じページを複数の異なるタブで開いてしまっているといったこともほぼなくなりました。

紹介しなかった機能たち

最後に、自分はあまり使っていない機能や使っているけど熱く語るほどではないものを箇条書きで列挙しておきます。
Arc は既に誰でもダウンロードできるようになっており、現在は Windows 版の開発が進んでいます（ Windows 版は wait list に登録できる状態になっています）。

• “Pinned” にあるフォルダにカーソルを合わせるとバルーンで中のリストを表示してくれる
  • さらにバルーン内で検索によって絞り込むことができる
• ブラウザ標準でスクリーンショットの機能を持っている
• Boost 機能という、ページのカラーやフォントをカスタマイズする機能を持っている
• Picture in Picture に対応している
  • Google Meet が対応しているので非常に助かっている

MeetingBar とは

https://github.com/leits/MeetingBar

Mac で仕事をしていて Google Meet や Zoom を使う際に便利なツール。
メニューバー上に現在もしくは次のミーティングのタイトルや開始までの残り時間が表示される他、クリックすれば今日一日（あるいは明日も）のミーティングを確認することができる。
さらにミーティングを選んでクリックすると対応するオンラインミーティングのページを開いてくれる。

オンラインミーティングのページに簡単に飛べることもそうだが、次のミーティングが何で、何分後（あるいは何時間後）に始まるのかがひと目でわかるという点が非常に便利で愛用している。

simple-bar とは

https://github.com/Jean-Tinland/simple-bar

一方の simple-bar は Übersicht という Mac で動くウィジェットアプリで利用できるウィジェットのひとつで yabai のステータスバーとしての機能をベースにメニューバーの代替を実現するものだ。
Übersicht および yabai についてはここでは説明を省略する。
興味のある人は以下のリンクから調べてみてほしい。

• Übersicht : http://tracesof.net/uebersicht/
• yabai : https://github.com/koekeishiya/yabai

僕は yabai を使っていることと、様々なアプリを活用していく中でメニューバーが乱雑になってしまっていることから simple-bar を導入した。
Mac の仕組み上、メニューバーを完全に消すことはできず、カーソルを最上部に持っていけば従来のメニューバーが出てくるため、クリックしてメニューから何かを選ぶといった操作については従来のメニューバーに任せ、 simple-bar では何かしらの作業をしながら目に入ると便利なものを表示するようにしている（おそらく simple-bar 自体がそういう用途を想定したアプリである）。
たとえば現在時刻やバッテリー残量、スピーカーの音量あたりはいつでも目視確認できると嬉しい。また最近は Spotify で BGM を流しながら作業することも多いので現在再生中の曲が見れるのも助かっている。

simple-bar に次のミーティングの情報を表示したい

操作が必要な事柄についてはメニューバーに任せ、普段の表示を簡素化できたという点では simple-bar に満足しているが、従来のメニューバーに表示されており simple-bar に表示されていないもののうち、これだけは外せないというものが1つある。それが次のミーティングの情報だ。
次のミーティングが何で、開始時刻がいつか、という情報は仕事を進める上で素早く確認できることが望ましい情報である。
しかし simple-bar には標準では次のミーティングを表示する機能は用意されていない。

ではどうするか。
simple-bar には User widgets という項目があり、コマンドやスクリプトを指定することができる。
これを使って MeetingBar の表示をそのまま再現することにした。

MeetingBar 自体の再発明をしたいわけではないので、既にメニューバーに存在している MeetingBar の表示内容をそのまま取得／表示できればよい。
どうやって実現するかというと AppleScript を使う。

AppleScript で “System Events” というアプリケーションを探し、その中の “MeetingBar” をとってくれば良い。 MeetingBar などがあるメニューバーの右側は “menu bar 2” に含まれているので以下のコードで MeetingBar の枠に表示されている文字列（＝現在開催中 or 次のミーティングのタイトルおよび残り時間）を取得できる。

name of menu bar item 1 of menu bar 2

ついでにクリックしたときに現在開催中 or 次のミーティングの Meet の画面を開けるようにした。
これはどうやるかというと、まずメニューバー上の MeetingBar をクリックして MeetingBar のメニューを開く。
次に「開催中のミーティングに参加する」もしくは「次のミーティングに参加」というラベルのアイテムをクリックさせれば良い。
この部分の表記に関しては日本語より英語でマッチングさせた方が確実だろうと思い、 MeetingBar の言語設定を英語にしてそれぞれ “Join current event meeting” と “Join next event meeting” でマッチングさせている。

これで simple-bar 上に現在開催中もしくは次のミーティングの情報を表示させることと、そのミーティングのページを開くことができるようになった。
クリックしてページを開く方は、 AppleScript でメニューバーを操作している都合上、動作が緩慢ではあるが、自分にとっては少ない労力で得たリターンとして十分だと考えている。