Mai Sukegawa @maisukegawa@fedibird.com

Googleドキュメントの匿名閲覧者リストって色々な動物がいるけど、Nyan Cat がいたとは知らなかったわね…
#fedibird

#JavaScript
今日新しく覚えたこと。

✍ シングルトンの作り方: 即時実行関数でシングルトンのインスタンスを返させる。
✍ Web Audio API の GainNode は、チャンネル数を超える数の入力があったらそれを自動的にミックスする機能がある (音声信号が単純に足される)。
✍ Webサイト上の音声の自動再生は、音声がミュート (またはボリュームが0) になっているか、ユーザによるサイトへのインタラクションがあれば許可される。ただし、Googleが推奨しているのは後者である。

これは絶対行くべきやつ…夏休み中だ！よし！チケット販売5月ね！
QT: https://mstdn.jp/@tinouye/109975684711285576 [参照]

確定申告を終わらせたぞ

管の中がどん詰まりになって波が返ってくるところはエネルギーが高い (＝音圧が最大になる)。
閉口部 (管を塞ぐ壁) は振動できないから、それに隣接する空気も振動しない。
というそれぞれの現象としては何となく想像できるけど、この二つが直結するものという理解ができないんだよね…

#音響学

文献の「音波は縦波であり，音圧が最大になるところは空気の振動速度が0となる」(※1) とか、「開口部における周囲の基準圧に等しくなければならないので，音圧は (中略) ゼロで固定される．しかし，閉口部では前進運動が不可能なため，音圧は累積されその最大値に到達する」(※2) というのを感覚として理解できないでいる。
そもそも音圧自体をよくわかってないのがよくなさそうなのだが、これは想像以上に険しいかもしれない…

※1: 小泉 宣夫著 『基礎音響・オーディオ学』(2005)
※2: 周波数領域における音響学 | Wolfram (https://reference.wolfram.com/language/PDEModels/tutorial/Acoustics/AcousticsFrequencyDomain.html.ja?source=footer)
QT: https://fedibird.com/@maisukegawa/109969790858450459 [参照]

#音響学

音圧をちゃんと理解しようと掘り進めたら、偏微分にあたってしまった…数学II/Bで止まっている自分にとって大学数学の沼は粘り気が強すぎる…

日記やログ、目標、タスクなどを有効に書き残すにはどうしたらいいかとノート術やら手帳術やらを色々試してきたが、ここ1年ほどでは Notion にバレットジャーナルの手法で1日1ページ作成する形で安定している。

具体的な手順と構成は以下の四つ。
1. 【日付タイトル】毎日日付をタイトルとしたページを作成する。
2. 【ログ】ページの前半にはやったことを書き入れる2列のテーブルを用意する。右のカラムには行ったこと、左のカラムにはそれを行った時間を書く。
3. 【ToDo】ページの後半にはタスクのToDoを書く。前の日のリストで完了しているものはそのまま、完了していないものは今日のリストに切り取り＆貼り付け。
4. 【日記】特別に書き残したいその日の出来事などがあれば、ログの下に自由な文章で書いておく。

タスクリストを別で作っても結局見ないので、仕事でもプライベートでも「近いうちに終わらせるべきToDo」は一旦ここにすべて投げ込むという形にしたのは有効だった。
すべてのタスクをその日に終わらせる必要もなく、完了したものだけ残して、あとは全部次の日にコピペするというのを繰り返していく。これはバレットジャーナルのアイディアを借りた。
単純で続けやすく、書く場所にも迷わないので取りこぼすこともほぼなくなった。

改めてちゃんと音のことを理解しようと思い、音響学をやり直している。
最近、議事録をまとめる仕事を多く任されているおかげか、もとの文献にある文言を自分の言葉に一回表し直してまとめる速度が上がった感覚がある。
またこの表し直すという作業は、ただ読むよりずっと高い理解度が得られるので、時間はかかっても信用している勉強方法である。
おそらくトータルで見れば、理解できていないために本を何度も読み直すよりも効率は良いように思う。

ひとに仕事を依頼するときに心得たいこと。

✍ 修正点があるとき、具体的に何ページのどこをどう直したのか文章でわかりやすくまとめる。
✍ 最終版として出した以上、それ以降の修正を重ねない。一度だけ言われても、他の新しい案件だったら免除されるとか考えてはならない。
✍ 相手の仕事量をこちらが推し量らない。「これはすぐにできると思います」とか言わない。
✍ 連絡ツールを統一する。メール・メッセンジャー・TwitterのDMなどをルールもなく五月雨に連絡しない。
✍ 最終〆切を互いに確認する。メール1 通目で「○日まででお願いします」と伝えてそれに了承してもらったら、3通目あたりで数日早まった〆切日をしれっと書いたりしない。

(本トゥートの真意は、以上全てについて真逆のことをしてくるクライアントがいるという愚痴である。それも一人で全て網羅しているのだ。ミラクルだね…)

ノスタルジーと寂しさと高揚感とが入り混じったような複雑な感動を起こさせてくれる景色というのがある。
それは例えば、目の前に迫るほど大きく広がる山だったり、枯れた草原の中にどこまでも走っている小道だったりするのだが、久々にそのような景色に荒川沿いで見つけることができた。
#fedibird #特に着地点のない雑感

JavaScript の async/await をよくわからないまま適当にペタペタ貼り付けるのをやめたかったので、async/await をそれなりに理解するためのブログ記事を書いた。
https://audiovisualcoding.hatenablog.com/entry/2023/02/19/224744

特に await の機能がよくわかっておらず、Promise に対してつけるものだということも、await をつけることでその Promise を resolve させた値を直接使えるようになるということも今回やっとちゃんと理解した。

#ブログ

友人のコンサートを聴きに東京に来ている。
今日は仕事もお休みにしたので、とにかく歩き回って #Ingress して、美術館にも行こう。
東京での Ingress 旅、楽しすぎるな…
#fedibird

盛り上がって2時間近くに渡った会議を議事録にまとめる作業、やっと終わった…
A4ドキュメントにして優に6ページを超える内容になってしまった。
我ながら凝り性すぎるが、情報が散らかったまま放置する方が頭のメモリを食い続けるので、数時間とても苦しむか今後数週間うっすら苦しみ続けるかのトレードオフなのである (？

チョコレートをいただいた
#fedibird

人がそれぞれ抱えている感情って、互いにすぐ共感しあえるほど単純ではないと思っている。
だから安易に共感することは避けているし、人の代弁は絶対しないと決めている。
誰かが他人について「この人はこう思っている (に違いない)」と言いながら突き進んでいくと本当にろくなことが起こらないし、私自身も感情を代弁されるのがものすごく苦手だ。
だから会話Tipsでよくある「相手に積極的に共感しよう」は、やや危ういものではあると思う。
共感と、感情の先取り・決めつけは区別しないといけない。

ライトモードいいじゃないという話 #特に着地点のない雑感 #fedibird

ダークモードはスタイリッシュで好きなので、色々なアプリで長いこと使っていた。
だけどいつもひどく目が疲れていて、もしかしたらと思ってライトモードにしてみたところ、驚くほど目が楽になることに気づいてしまった。
そこから、泣く泣くダークモードは避けている。

とは言え VSCode はデフォルトのダークがかっこいいし文字色もわかりやすいし…とずっと粘っていたが、やはり目がものすごい疲れてしまうので、今日思い切ってライトにしてみることにした。
背景真っ白はプレーンテキスト感が強くてちょっと気が進まないなあと思いつつ探したら、「Quiet Light」なるモードがあった。
紙のような質感の背景色に、彩度抑えめの文字色。優しさに満ちている…
ダークとライトで気分も変わる気がするな。ダークでは心なしか な感じだけど、Quiet Light にしたら禅の心で仕事できるかもしれない。

一瞬だったけどヤマガラを観測。
#fedibird

【今週の目標】
1. ロラン・バルト「作者の死」の4ページめを読み込む。
2. Web Audio API を使って、ユーザがインタラクティブに音を操作できるシステムを作る。
3. Max/MSP のジェネレータとフィルタを復習する。