今日のバドミントン練習はリフティングを35分 (メイビスで25分、エアで10分)、壁当てを5分した。近所のビルの軒下の照明は21時までと21時から24時までで明るさが異なる。段階的に照明を暗くしているようにみえる。フォア持ちとバック持ちを交互に切り替えながら行うリフティングはやや安定してきた気はするが、100回を超えたぐらいで失敗してしまう。当面は200回連続を目標に練習してみる。21時を過ぎてから風が強くなってきて集中力もなくなったので今日は練習を早めにきりあげた。

エアシャトルは高く上げた方が落下時に安定する。練習していてラケットコントロールを失敗してシャトルをビルの入口の天井に打ち上げてしまった。これはビル管理に怒られるんじゃないかと思って焦った。近くのコンビニで脚立を貸してくださいとお願いしたら店員さんが快く貸してくれた。やさしい世界。脚立を使って、横からラケットでシャトルを手繰り寄せて、ぎりぎり手が届いて回収できた。あと数十センチ中央側に止まっていたら回収できなかった。ほんと助かった。この付近では高くシャトルをあげないという学びを得た。

iphone 16 の機種変更と移行

前の機種変更から2年たったので移行することに決めた。色はグリーンがよかったのでティールというミントカラーを選択して pro ではなくスタンダードなデバイスにした。実際が届いてティールのカラーをみてみると、私のイメージのグリーンとはやや異なったけど、これはこれで悪くないとは思う。これまで使っていた 14 pro とサイズはほぼ同じで厚みが少し薄くなっていた。手にもった感じでは薄くなった分だけ掴みやすかったり包み込めたりして馴染むように思えた。デバイスの触感も悪くない。

さっそく ios のクイックスタート機能を使って移行した。1時間もあれば初期設定はだいたいうまくいった。私にとって重要な移行検証は次の3つだけ。

• Microsoft Authenticator
• 1Password
• 電話／SMS

sim カードを移し変えるだけで電話の発着信もできた。スマホで電話の発着信テストをする方法 から111に電話すると、その後、着信を受けられて発着信のテストができる。Authenticator の初期設定を失敗して初回起動時にバックアップから復旧する選択肢を選ばないといけなかった。誤って新規セットアップをしてしまい、どうやって移行するのかがわからなくてはまった。アプリを一度削除してから再インストールして、再度初期設定することで icloud に保存されている Authenticator のデータを移行できた。

その後、コンビニで paypay を使おうとしてデータ通信できないことにも気付いた。レジに並んでいるときに気付いてよかった。iijmio 乗り換えガイド (初期設定) をみながら APN 構成プロファイルのインストールをする必要があった。これを設定しないと電話回線でデータ通信できない。電話の発着信ができているからデータ通信もできると私は誤解していた。全体を通して、私は少しはまって調べたりやり直したりしたが、スムーズに移行すれば1-2時間もあれば重要なデータを移行できる。あとは個別アプリの再ログインだったり、移行だったりをしていくだけ。銀行アプリなどもやや再設定は申請が必要で面倒だったりもする。

昨日の夜に縄跳びに出掛けようと思ったところ、雨がパラパラしてきて諦めた。今週は天気が悪いからあまり外で運動できないかもしれない。

今日の運動は腕立て,スクワットをした。統計を 運動の記録 にまとめる。

mongosh でデータ移行

あるコレクションのデータ構造を変更したので既存データを移行しないといけない。mongosh を使うと javascript っぽい文法で repl から mongodb のデータを操作できる。私は sql を書く方が好みだけど、慣れの問題で mongosh はプログラミングに近い形でオブジェクトを操作してデータを更新できる。例えば、history というコレクションを3件だけ取得して1件ずつ dump するコードは次のようになる。

> db.history.find().limit(3).forEach(function(i) {console.log(i)})

なにかしら関数内で処理した結果を用いて更新しないといけないようなときに forEach を使うと簡単にデータ移行できる。しかし、これは1件ずつ更新を実行するので時間はかかる。余談だけど、mongosh をリモートから接続すると forEach で取得するデータをローカルに fetch してくるので document のサイズに比例してデータの取得分の時間だけ遅くなる。forEach を使うときは ssh で mongodb のサーバーにログインして、そこで mongosh を起動した方が効率よくデータ移行できる。

compose 環境の mongodb に direct 接続するときはこんな感じ。

$ docker compose exec -it mongo mongosh "mongodb://${USER}:${PASSWORD}@localhost:27017/?authMechanism=DEFAULT&directConnection=true"

シンプルな条件で更新できるようなときは updateMany を使ってバッチ更新すると1件ずつ更新するよりめちゃくちゃ速い。私の環境では270万件ほど更新するのが数分で完了した。仮想マシン上のコンテナ環境なので実機だったらもっと速いはず。

> db.history.updateMany({type:null}, {$set:{type:"myType"}}, {})

6時に寝て8時半に起きた。オフィスで3時前ぐらいまで調べものして、帰ってからも眠れなくてネットしてたら朝になった。

今日の筋トレは腹筋:15x2,腕立て:10x1,スクワット10x1をした。

サンライズ出雲の予約

以前 やまさきさんに教えていただいた夜行列車 を予約してみた。列車は瀬戸と出雲の2つがある。岡山〜東京間は瀬戸と出雲が連結して運行するそうなのでどちらを選択しても同じだと思うけれど、出雲で予約してみた。乗り込む車両が異なるのかな？

三ノ宮(00:11発) => 東京 (07:08着)

• 特急サンライズ出雲（シングル）
  • 料金券部分 10,460円 (三ノ宮 - 東京)
  • 乗車券部分 9,460円 (神戸市内 - 東京都区内 2月6日～2月9日まで有効)

前回に 専用の予約画面 があることを調査済みだったので迷わず予約を取れた。唯一、面倒なところがオンラインで予約した後に紙の切符を発行しないといけないところ。切符を発行するには緑の窓口・券売機へ行かないといけない。三ノ宮駅にはあるので問題はない。発行には次の3つが必要になる。初めてだから予約後、すぐに駅へ行って発行してみた。迷わず簡単にできたのでこれなら乗車する直前でもそう困らないように思える。

• 予約したクレジットカード
• 電話番号の下四桁
• 予約番号

upnote への移行

数年前から evernote のビジネスが安定していないのは既知になっていたが、ここ1-2年でフリープランをどんどん縮小して投資回収的な値上げを強行している。

• 「Evernote」無料プランの上限変更が正式決定、導入は12月4日から

値上げするだけならまだしも、アプリを開くたびに有料プランにアップグレードするためのダイアログを表示して、意図的にユーザー体験を悪化させて、フリープランのユーザーを退会させたいようにみえる。ここまで露骨にやって既存の課金ユーザーだけで十分にビジネスはペイするという目論見なのか、経営陣が短期的にV字回復させたという実績作りなのか。いずれにしても、私のようなちょっと使いのフリープランユーザーはターゲットではないらしい。どうやら2011年6月から使っていたらしいが、件数にすると216件のノートしかない。週に1-2回は使うのだけど、なくなったら別アプリに移行しても困らない程度の用途にしか使っていない。

ずっと移行したいと思いつつ、なおざりにしていた理由として移行先のアプリを選定していなかった。私の用途としては次のような使い方をしている。

• 買いものの備忘録として思いついたときにパソコンから記録し、スマホでチェックしながら買いものする
• 法人番号、住所、家族の誕生日など、オンラインで手入力しないといけないときなどのコピペ元
• 郵便受けのダイヤルロックを忘れたときのメモ
• パソコンやデバイスを購入したときのスペックを記録しておく
• オンラインの記事やサイトを保管しておくときの web クリップ

正直メモ帳アプリでなくても、他のアプリへ移行することもできるが、惰性で使っているのでできればそのまま移行したい。私の周りでは obsidian を使っている人も多く評判もいいからこれでもよかったんだけど、いくつか記事を読んでいると upnote の評判もよさそうにみえた。また upnote はサブスクリプションモデルではなく、パッケージライセンスなのでコストが安い。app store 経由でプレミアムのライセンスを購入する。為替によって値段が変わると思うが、いま買ったら3,500円だった。この値段で未来永劫 upnote のインフラコストを賄えるのかは懐疑的だが、3,500円ぐらいならそうなったときにまた別のメモ帳アプリへ移行するのでもよいかなというぐらいの気持ちで upnote を使ってみることにした。

• ノートアプリ難民必見！UpNoteが超気に入った理由を語りたい

web 版はなくて、それぞれのデバイスごとにインストールする。linux は snap パッケージが用意されているので ubuntu なら次のようにインストールする。

$ sudo snap install upnote

evernote から移行をするにあたり、.enex という xml ファイル形式でデータをエクスポートできる。これは macos または windows アプリでないとエクスポートできない。仕方ないから macos に evernote のアプリをインストールしてエクスポートする。ノートブック単位でエクスポートできる。

• ノートとノートブックを ENEX または HTML 形式でエクスポート

その後、upnote の macos アプリでインポートしようと試みるも macos 版にはインポート機能が見当たらない。linux 版にはインポート機能があったので .enex ファイルを linux にコピーしてきて linux 版でインポートしたら移行を完了した。移行の制約事項は次の通り。216件のノートしかないので10分もあれば完了した。同期もかなり速くて、すぐに iphone, macos, linux でノートが同期された。

最適なパフォーマンスを得るには、次の点に注意してください。

• 多数のノートをインポートすると、アプリのパフォーマンスに影響を与える可能性があります。
• 20MBを超えるファイルはインポートされません。
• 300,000文字を超えるノートはインポートされません。

インストールしてから、このアプリの開発元はどこなんだろう？と調べてみるとベトナムの会社らしい。ややセキュリティは大丈夫なのかな？と不安に思ってしまう。Frequently Asked Questions から引用する。firebase を使っているならストレージは強固だし、同期も firebase に委譲すればおかしなことも起こらないだろう。

アップノートはどのように私のデータを保存するのですか？

UpNoteは、アカウントにサインアップしなくても確実に動作するように設計されています。サインインしない場合、メモはあなたのデバイスにローカルに残ります。デバイス間でメモを同期したい場合は、アカウントにサインアップすると、UpNoteが中央サーバーにメモを保存し、他のデバイスと同期できるようになります。

お客様はご自身のデータを完全に管理することができ、アップノートがお客様のデータにアクセスしたり、お客様のデータを第三者に販売したりすることは決してありません。プライバシーに関する詳細は、プライバシーポリシーをご覧ください。

アップノートのサーバーはどこにありますか？安全ですか？

UpNoteはFirebaseサーバー（Googleが提供するサービス）にデータを保存します。Firebaseプラットフォームは、主要なプライバシーおよびセキュリティ基準で認定されており、EU一般データ保護規則（GDPR）およびカリフォルニア州消費者プライバシー法（CCPA）を完全にサポートしています。Firebaseは、HTTPSを使用して転送中のデータを暗号化し、静止時のデータを暗号化します。詳しくは https://firebase.google.com/support/privacy をご覧ください。また、お客様のデータが安全に保護され、お客様だけがアクセスできるように細心の注意を払っています。

アップノートはエンドツーエンド暗号化に対応していますか？

エンドツーエンド暗号化（E2EE）は、データを暗号化・復号化するための高度なセキュリティ手法で、機密性の高い情報を保護するために設計されています。実装が複雑なため、アップノートでは現在E2EEをサポートする予定はありません。パスワードやクレジットカード番号などの機密情報を保存する場合は、機密情報を暗号化するために特別に設計されたパスワードマネージャーアプリケーションを使用することをお勧めします。

e2ee に対応していないところは残念なところ。未対応のセキュリティリスクの懸念としては、upnote 社の社員が私のノートの内容を閲覧できる可能性があったり、攻撃者が upnote 社のインフラに侵入してしまった場合、メモ帳の内容が外部に漏洩してしまう可能性がある。とはいえ、値段も安いのだからそこは割り切って機密情報はすべてパスワードマネージャに移行せよという戦略は理解できる。私の用途だと、メモ帳に機密情報はほとんどないけれど、賃貸の部屋のインターネット接続のアカウント情報や wifi パスワードなどを書いていたりする。こういった内容もこの機会に整理して 1password へ移行していくのがよいように思う。

0時に寝て何度か起きて6時に起きた。土曜日から喉が痛くてコロナ感染の懸念もあったけど、前日は一日中休んでいたせいか、喉の痛みは全くなくなった。たまたまだったのかもしれない。

slog 移行

slog 勉強会 で学んだ LogValuer という interface を使うと、機密情報のログ出力をカスタマイズできる。要はパスワードのような文字列を *** に置き換えるといったことをしたい。もっともシンプルな機密情報を扱う型として Secret を定義した。この Secret でラップした文字列を扱う分には slog のロガーでそのまま出力しても問題ない。

type Secret string

func (s Secret) LogValue() slog.Value {
	return slog.StringValue("***")
}

func (s Secret) String() string {
	return string(s)
}

あと自前で定義していたロガーのログ関数を slog のトップレベル関数を使うように1つずつコードを書き直していった。機密情報に関するところで一部まだ置き換えていないところもあるが、98%のログ出力のコードは slog に直接置き換えた。時間がかかるだけの面倒くさい作業なので、こういうプロジェクトの隙間に地道にやるのがよいと思う。今回も移行にあたって slog のコードを少し読んだが、slog は本当に既存のログ出力の機能で大事なところだけをシンプルに実装していてよく出来ていると思う。

0時に寝て夜中に吐き気がして2回ほど起きて3時と5時に起きて8時に起きた。なかなか苦しい寝方をした。

ヤフートラベルと一休.comのシステム統合

アーカイブ公開されたらみようと思いつつ忘れてたので見返した。

雑なめも。また機をみて見返すこともあるかも。

• バックエンドは完全に一休側に寄せるという大きな意志決定を2016年に行った
  • この意志決定はフロントエンド統合にも大きな影響を与えた
  • ふじもんさんの意志決定がよかった？
• 今日の話しはマルチブランドデザインシステム統合がメイン
  • 開発者が50-60人程度で半年ぐらいで launch できた
  • nuxt/vuejs で開発している
  • スタイルは tailwindcss を使っている
  • 実は launch した後にこのシステムが必要だとわかった
    • 開発者とデザイナー間の細かい意思疎通が困難
    • 外部からデザインシステムに詳しい人にも来てもらっていろんな議論をした
    • ガイドラインを言語化するところから始め、最終的にソースコードの共有ができるようになった
  • 終わってからデザインシステムそのものは重要ではないと気付いた
    • この過程で開発者とデザイナー間のどのように共通化するか、あるいはしないかと議論を繰り返し行ったことが重要だったと当事者がインタビューで語っていた
    • デザインシステムの開発を通じてデザインの共通認識をもてたことがよかった
• 波及効果
  • 同じソースコードから少し異なる体験の開発のノウハウができた
  • ふるさと納税に特化した宿泊予約サイトを作った
• 統合は終わりではない、lauch したところが始まり
  • 統合後にいろいろな施策をすることで課題がみえてくることがある
• 全国旅行支援は1つの開発で2つの体験をつくることができた
• Q. デザイナーと開発者はわりと仲が悪いのでは？価値観や考え方が異なるのですり合わせるのは難しいのでは？
  • 過去の一休でも起きていた
  • 一休のチームはデザイナーと PM と開発者で構成されている
    • このチームが一緒に働いていてチームでなるべく意志決定している
    • 普段から一緒に働いていると仲が悪いということはなかった
    • とはいえ、仕事のプロセスが異なるので課題はあった
      • 地道に丁寧にすり合わせを行った
      • 外部から講師を読んで中立的な立場でワークショップを何度も行った
  • デザイナーと開発者を別の組織にしているとコミュニケーションの壁ができてしまうかもしれない

go の学び直し

テストの学び直し に引き続き、Gopher塾 #2 - Goらしいコードの書き方 - DAY 1 に参加した。

テストの次のプログラミングの話しだったので内容そのものは難しくはなかったけど、改めて重要な項目を選抜しているのだと考えると学びはあったと思う。参考になったことをいくつか覚えている範囲でまとめる。名前の付け方について感覚的に理解していたし、実際に私はそうしているけど、コードレビューしていて自然になっていないコードを指摘する機会も多いので一定の習熟を要するのかもしれない。いま毎週勉強会をやっていて私が講師として話している。ネタがなくなってきたり大変になったきたら準備の少ないコードリーディング会もやってみたいと思った。

• google Go Style
• derrors.Wrap
• 名前に文脈を与えるという概念
  • 相対的な名前をつける
• 準備の少ないコードリーディング会
  • お題（読むパッケージ）を決める
  • 選んだお題に期待することを当日話す
  • 時間を決めてみんなでそれぞれ読む（20分とか）
  • 読みながらSlackのスレッドにメモをしていく
  • 残りの時間で気になったところを議論する
  • 自分が気づけなかった点を知ることができる

0時に寝て7時に起きた。オフィスで荷物を受け取る必要があったので8時にはオフィスに行って普通に作業してた。午前中は金曜日の作業で途中になってた単体テストを仕上げた。

iphone 移行

iphone 11 から 14 pro に移行した。色はディープパープルにした。本当は 11 のグリーンが気に入っていたのでグリーンしたかったけどないから仕方なく。先月の上旬ぐらいから iphone のスクリーンの一部が操作を受け付けなくなった。タッチしても反応しないといった状態になる。最初はドラクエタクトをする上であるボタンが押せない程度だったのだけど、その後も使い続けているうちにその反応しない領域が少しずつ拡大していった。文字入力のパネルなら「や」と「ら」の領域が反応しない、paypay で支払うときに8や9が入力できない、電話が掛かってきてもスワイプで着話できないとか。一部の領域が反応しなくなってから1ヶ月ぐらいで普段使いに支障がでるようになっていた。

幸いにも9月半ばにはらさんとも相談しながら 14 pro を購入する決断をしていた。9月16日に注文したものが本日届いた。注文時の予定では10月20-27日の予定になっていたのがかなり前倒しになったみたい。朝から古い端末の ios を最新の 16.0.2 にアップグレードしたり、icloud へのバックアップを取ったりしていた。私はとくに icloud のストレージ容量を契約していないので無料の5GiBしかない。それなのにバックアップは成功して、なぜだろう？と調べたら機種変更時の icloud へのバックアップは容量無制限で使えるらしい。とても助かった。

• iPhone機種変時のiCloudバックアップ、容量無制限で無料に　iOS 15の新機能、その手順を解説

iphone のデータ移行は クイックスタート という仕組みが3年前から提供されていて、基本的にはこの機能を使えばとくに労力なく移行できた。もちろんアプリによっては個別の移行作業が必要になるけれど、クイックスタートのおかげで基本的には古い端末と新しい端末を並べて移行の承認のような作業をするだけで済む。クイックスタートは iphone 同士を bluetooth 接続で繋ぐ。bluetooth 通信でもデータ移行できるそうだけど、wifi に比べると速度が遅いので256GiBなら3時間ぐらいかかる見通しらしい。icloud経由にするとwifiなので速度も速く15分程度で復元処理を完了できた。私の場合、電話、line、認証系アプリといったコアな機能の移行を1時間ほどで完了できた。一昔前に比べてかなり簡単になっているように感じた。

ストレッチ

本当は田んぼに実家に帰っている予定だったので日曜日の夜からストレッチ。今日の開脚幅は開始前157cmで、ストレッチ後161cmだった。最近はまったくストレッチしないようになりつつあるのだけど、腰の張りのアンバランスさは解消されていて、トレーナーさん曰くそれはよい状態だと言えるらしい。ストレッチを受ける前から雨降りでストレッチを終えてから何をしようかふらふらとアーケードを散歩して、結局のところ、やることがなくて雨に振られながら帰ってきた。

1時に寝て6時に起きた。

リファクタリングとインフラ移行

ここ2週間ほどリファクタリングやらインフラ変更やらをしてきて、来週からまた新しい施設がサービスインするので区切りとしてリファクタリングは一旦終わりにする。今日がその集大成となるインフラ移行も含めた本番リリースだった。インフラ移行するときはなにかしら障害が起きる前提で待機しているものの、今日もすんなりと意図した通りに移行できて、してやったりではあるものの、モノ足りなさで拍子抜けしてしまった。また昨日から社内 wiki にも minikube の使い方、k8s cronjob の設計、バッチ処理の設計と実装についてドキュメントなどを書いていた。いままですべて私が1人で担当していたものを他メンバーでも作業できるようにドキュメント化した。近いうちにいなくなるので引き継ぎのドキュメントにもなる。

nuxt で画面作り

ここ最近2種類の web api の機能を作ったのでその管理画面も2つ作る必要がある。私はフロントエンド開発の素人なので他のメンバーが作ってくれないかと声をかけてはいたけど、みんな忙しいようなので私が作ることにした。今週は nuxtjs の新規画面の開発をがんばってみようと思う。既存のソースを読む限りはそんなに複雑ではなさそう。素人が雰囲気で実装しても動くんじゃないかと思っている。ソースコードを読んでいて url 設計はめちゃくちゃだし、一覧画面にはページング機能も実装されていない。素人がソースを読んで基本的な骨子や機能が正しく実装されてないことがわかってしまうのは品質レベルとしてなにかがおかしい。圧倒的低品質と呼ぶのか、こんなことが起こってしまうのはよい開発文化がないせいなのだろうと考えている。

0時に寝て4時に起きて6時半に起きたつもりが、なんか3度寝して8時に起きた。

スライドマスターのデザイン作成

うちの会社のロゴは Ševarika™ というデザイナーさんに作ってもらった。言語にセルビア語とあるので旧ユーゴスラビア地域の国の出身なのかなと推測する。このご時世なので NATO 加盟国なのだろうか？とか調べてみたけど、旧ユーゴスラビア地域の国々の歴史は複雑ですぐにわかるものではなかった。閑話休題。私は会社のロゴをとても気に入っているし、ロゴを作ってもらうときの取り引きも円滑にできたのでそのデザイナーさんを信頼している。今回も2年半ぶりに連絡をとったら快くスライドマスターの作成を引き受けてくれた。4月30日に契約して、とくに急いでいないのでデザイナーの都合がついたらでという緩い依頼をしたんだけど、昨日さっそく最初の草稿が届いた。いくつか私の好みのスライドデザインのサンプルを渡したりしていたので、私の好みのスタイルは外していない。ただ私はデザインのことは何もわからないので、今回は顧問のはらさんにもレビューしてもらってご意見をもらうことにした。

ベースライン移行

先日の flyway のデータベース移行 の続き。管理しているマイクロサービスが4つあるのでそれぞれのサービスごとに設定していかないといけない。サーバーサイドって共通化できるのが大きなメリットなのに、同じサーバーサイドの仕組みを複数導入しないといけないというのはマイクロサービスのデメリットと言えばそうだし、アーキテクチャとしても正しいんやろか？という気持ちも出てくる。おそらく1つのチームが複数のマイクロサービスを開発する体制がよくない。変更作業と検証で約1日を費やした。

0時に寝て4時に起きてタイムライン眺めながらだらだらして6時半に起き上がった。

データベースの移行処理

半年前から導入したいという話しは聞いていたものの、先送りになっていたライブラリに flyway がある。データベースの移行処理のためのスクリプト (sql) を管理するツールでどの移行スクリプトを実行したかを記録したり、未適用の処理を自動で適用してくれたりする。spring boot だとすぐ組み込める状態になっていて Community Plugins and Integrations: Spring Boot をみながら設定したらすぐに動いた。flyway 自体の設定も Common Application Properties を参考に spring boot の設定ファイルで行える。

例えば、こんな感じ。

spring:
  flyway:
    enabled: true
    schemas: public
    locations: classpath:db/migration
    baseline-version: 0
    baseline-on-migrate: true

移行処理の履歴情報は flyway_schema_history テーブルに保持される。既存のテーブルが存在して flyway の履歴データがない場合 (初回起動時) に移行処理を実行するかどうかを baseline-on-migrate で決める。実行するなら baseline-version でどのバージョンをベースラインとするかも設定できる。ゼロにすることで V1 からの sql ファイルを適用してくれる。ベースラインの考え方は実際に何度かデータベースの初期状態を変えて実行しないとわかりにくいかもしれない。

• Tutorial: Baseline Migrations