２つのMacで使っていて、特定条件だけ同期できなかった。
既存ファイルを両方のMacが持っている時はちゃんと同期できるが、
片方で新規にファイルを作った場合、そのファイルはもう片方に入らないという状況。

原因判明までかなり時間がかかったが、
クライアントソフトのコンピューター名が原因だった。

このMac２台は元々同じ内容のもので、新しくMacを買った方にデータを移行したものだった。
移行後に旧Macはすぐにコンピューター名は変更していたのだが、
クライアントソフトには最初のコンピューター名が残っていて、同じコンピューター名なので同期不要と判断されたものがあったよう。

クライアントソフトの設定で、「接続を編集」を選ぶと登録されているコンピューター名が表示されるので
それを編集し、パスワード欄もちゃんと入れて再設定をするとできた。

なぜか設定していない方のクライアントで「認証エラー」など表示されたが、
一時停止してつなぎ直したりしてたら正常に動いた。

数日前にルーターの電源を一度落としたからか、プリンターがつながらなくなった。
確認すると、WiFiに接続できていない。
タッチパネルから設定するも、パスワードは合っているはずなのに接続に失敗する。

いろいろ試した結果、
・蓋を開けた中にある差込口にUSBを指して、パソコンにつなぐ
（その状態のままだとWiFi接続中になるが、ケーブルを抜くとまた切れる）
・その状態のまま、本体のタッチパネルでWiFi接続する

これで再接続できた。
なんでこうなるのかはさっぱりわからない。

Officeを購入したあとで、どうしても不具合がなおらず困っていた。

購入した商品ページを見ると、「60日間のサポート付き」とあった。
とはいえサポート先がわからず、サポート用のフリーダイヤルを見つけたので電話してみると
「それとは別」と言われてしまった。

ただ、サポート先は教えてくれて

aka.ms/csjp

とのこと。アクセスしたら別URLに転送されたので、
電話で伝えるための短い転送用URLを準備しているのかなと思った。

ちなみにサポートを受ける前にこのサイトからのリンクで
不具合解決のヒントを発見して自己解決したので、結局サポートは受けなかった。

VS-codeにフルディスクアクセスの許可を追加

MacVimがチカチカなって使えなくなっていたので、設定から「Core Textレンダラを使用する」のチェック
↓
カーソルの表示部分がなんかおかしい気がするし、使っていたMacVim-KaoriYaが数年メンテナンスされていないこともあり素のMacVimに乗り換え。
brew install macvim
ln -s $(brew –prefix macvim)/MacVim.app /Applications

localhostがIt works!になる。
自動起動を確認
sudo launchctl list | grep httpd
Mac標準のapacheを自動起動しないよう設定
sudo launchctl stop /System/Library/LaunchDaemons/org.apache.httpd.plist

Finderにつけていた、「新規テキスト作成」「ターミナルを開く」が動かなくなっていたので再設定。
Automatorで作ったアプリをFinderのヘッダーバーに設定。
ついでにアイコンがBig Surに合うように作り直して、設定。（情報を見るの左上にあるアイコン画像をクリックしてクリップボードから貼り付け）

VeraCyptが動かない→設定からmacFUSEのアップデート→再起動→VeraCript→セキュリティで許可→再起動

MacをBig Surにしたら不具合発生。

VS-codeのtasks.jsonで設定していたphpunitが動かなくなった。

No tests executed!

と表示される。
このため、原因調査。

調べてみると、標準で入っているPHPが古いバージョンなのでエラーが出るとのこと。

vs-codeのphpは　/usr/bin/php にあるものだった。
これをterminalからリネームしようとしてもエラーでできない。
このディレクトリのものは変更できないとのこと。

vs-codeにパスを通そうと
terminal.integrated.env.osx
で設定しようとするも、反映されない。

echo $PATH をしてみると
/bin:/usr/local/bin:/usr/bin
となっているので、
/usr/local/bin に、現在の実行phpである
/usr/local/opt/php/bin/php
へのシンボリックリンクを作成し、そちらの方が先に読まれるようにしたら動いた。

今まで動いていたブラウザテストが動かなくなった。
テストのエラーではなく、そもそも起動しない。

原因はchromedriverのバージョン。

Macの場合は、chromeのバージョンを確認した上で

php artisan dusk:chrome-driver 92
などバージョン指定する。OSは自動的に認識してくれるので、
vendor/laravel/dusk/bin/chromedriver-mac-intel
などが更新される。

DockerのLinux利用のchromedriverも更新する場合はそちらでも作業が必要。
Docker内で
php artisan dusk:chrome-driver
とする。バージョンを指定しないと、最新になる。これで
vendor/laravel/dusk/bin/chromedriver-linux
が更新される。

これらはgitでの管理ファイルではないので、他メンバーの環境は気にせず実行可能。

（追記）
Dockerで動かしているlinuxでは、chrome本体のバージョンがドライバーより古くなってしまうことがある。
その場合は、Dockerをもう一度ビルドすることで。chrome本体のバージョンが新しくなる

brew upgradeしたせいかと。

~/Library/LaunchAgentsにあるhomebrew.mxcl.mysql.plistのシンボリックリンクが古いパスになって切れていたので張り直した。

（参考）
AMAZON SES でのメール送信ログを表示する
https://blog.denet.co.jp/amazon-ses-log/

Amazon SES で E メール送信履歴を表示するにはどうすればよいですか ?
https://aws.amazon.com/jp/premiumsupport/knowledge-center/ses-email-sending-history/?nc1=h_ls

Amazon SES でメールの送信履歴を保存する方法を教えてください。

公式が準備している上記の通りに設定をすると、
SESのテスト送信にて作成したConfiguration setsを指定すると
ログが取れるところまではできた。

ただ、いくつか注意点があった。

1. Configuration setsを常に指定しておきたい。

テストメールや、プログラムからの送信の場合は
メールヘッダーにConfiguration setsを指定することでログ取得の対象となることがわかったが、
それ以外の場面（Gmailや既存のメール配信システム）でのログが取りたかった。

調べても見つからず、設定画面にもそれらしいものがなく、設定が無理なのかと思っていたが
SESのコンソールを新しいバージョンにしたら、設定箇所を発見。

メールアドレスごとの画面でデフォルトのConfiguration setsを設定できた。これで、システムだろうがGmailだろうが、SESを使って送信すればログが残るようになった。

2.高くなった

とりあえず動くことを目指して設定を色々といじっていて、なんとか動いたわけだが、それほど送信数も多くないし金額はたいしたことないと思っていた。稼働しはじめてから数日たってチェックしてみると、1日15ドル以上かかっていた。とりあえずのチェックくらいであれば、最小構成にするのがオススメ。

3.Kinbaへのアクセス

ログを見るにはElastic searchの画面でリンクが準備されているKinbaにアクセスする必要があるが、AWSのユーザーで認証をかけて見れるようにしようとあれこれ試したがうまくできず、結局IPアドレスでの許可しかできなかった。IPアドレスが違う環境や変わった時などは設定から変える必要があるので面倒。

たくさん管理しているワードプレスにアタックが多いので
wp-login.phpを無効にすべく
SiteGuard WP Pluginを入れて「ログインページ変更」を設定した。

ほとんどのサイトがうまく動いたけど、ひとつだけ
新しくできたログインページにアクセスしても404エラーがでてログインできない。
当然元のログインも無理。

調べたら.htaccessを消すとかって情報がたくさんあったけどなんか嫌なので
他の方法を模索。

データベースをチェックしてみると
wp_optionsの中に
option_name = siteguard_config
に設定項目を発見。

その中で、
“renamelogin_enable”;s:1:”1″
という項目を探して
“renamelogin_enable”;s:1:”0″
に変更すると、元のwp-login.phpでログインできた。

いつも送信しているメールを送ったら、下記のエラーメールが届いた。

535 Signature Version 2 is deprecated for use with SES from March 26, 2021. From that date on, we are progressively rejecting such requests. To resolve the issue, you must migrate to Signature Version 4. If you created your SMTP credentials in the SES Console, please create new credentials and replace the former ones. If you are deriving Signature Version 2 credentials from a IAM user, please start using the Signature Version 4 algorithm:

Google日本語翻訳をしたものが下記。

535署名バージョン2は、2021年3月26日からSESでの使用が非推奨になりました。その日以降、このような要求は段階的に拒否されます。 この問題を解決するには、署名バージョン4に移行する必要があります。SESコンソールでSMTP資格情報を作成した場合は、新しい資格情報を作成し、以前の資格情報を置き換えてください。 IAMユーザーからSignatureバージョン2の資格情報を取得する場合は、Signatureバージョン4アルゴリズムの使用を開始してください。

3月26日以後も送れてたんだけど、少し後のタイミングでエラー。
SES の SMTP Settings で新しいCredentialsを設定し、そのIDとPWでメール送信を再設定したら問題なく送信できた。