0時に寝て3時半に起きて5時半に起きて8時に起きた。

ストレッチ

先週は実家に帰っていて通常とは異なる日程だったのでアラームを解除していた。ストレッチの時間のアラームを聞いてから出掛けていたので危うく遅刻するところだった。

今日はとくにどこも悪くなくて、可もなく不可もなくといった感じだった。 トレーナーさんによると、冬は寒くて丸くなってしまうせいか背中が硬くなりやすいという。背中のツボをあちこち押されて痛かった。たまたまトレーナーさんと物価の話しをしていて、いま物の値段がピークアウトしてサービスの値段が上がってきていて、よいインフレの傾向になっているといった記事の共有をした。

• 日本の値上げに構造変化

ストレッチもサービス業だから値上げしてトレーナーさんの給料も上がるとよいですねと。トレーナーさんによると、定期昇給といったものはなく、歩合給はあるもののそれほど大きくなく、給料をあげようと思ったら店長になるといった役職をつけないといけないらしい。あとトレーナーさんのスキルレベルによってお客さんが支払う金額も違う。昇給していくことが見込めないと、若い人しかトレーナーさんはできないのかな？という印象も受けた。スキルの高いプログラマは単価が上がっていくことが社会的に認識されているから将来に不安はないけれど、新しい職業や業態のキャリアモデルを作るのは難しいと思えた。今日の開脚幅は開始前155cmで、ストレッチ後157cmだった。

アクセシビリティの話し

以前からはらさんが登壇されるという話しは聞いていた。ちょうど法事で実家に帰っていた日にイベントがあったようだ。

• XR やクローラーについて話した次世代 Web カンファレンス A11y セッションが無事終了しました

1:31:00 ぐらいから A11y (Accessibility) のセッションが始まる。はらさんが登壇されているので一通りみた。アクセシビリティわからない人がみてもおもしろかった。

20代、30代、40代の登壇者がいてバランスがよいようにみえた。また全盲の登壇者が A11y について話しているのはかなりの説得力をもっている。多くの人にとってアクセシビリティはあまり関心がない分野であり、プログラマーだけが注意すればよい問題でもないという。プログラマー、デザイナー、組織、エンドユーザーといった、プロダクトに関係するすべての人の認識や意識を調整してアクセシビリティは成り立つ。そして、障害当事者と出会う機会があるということそのものがアクセシビリティを考えることについてのプラスになるのではないかと話していて共感できた。登壇者にとっては、目の不自由な方がスマホをどう使うのかの動画が sns でバズっているのをみて、一般の人たちは (その登壇者にとって当たり前のことを) こんなに驚くのかと驚いたという。

私はフロントエンドの画面の開発に関して、たまに手伝う程度なのでアクセシビリティを意識して作ることはあまりない。しかし、使いにくいものは使いにくいとはっきり言うので、仕様や規格に準拠しているからとか、こういったデザインが流行りだとか、そういった物差しに関係なく意見は言う。登壇者の中にも自分の頭で使いやすい・使いにくいといったことを考えてほしいというメッセージを発していた。

差し入れ

私は出掛けていたので参加する予定はなかったが、ブログJelly Vol.137 に三ノ宮.dev のメンバーが参加しているというのをみかけて差し入れしてきた。若い人はいろいろな経験を積んでどんどん挑戦してほしい。たまたま出先から帰ってきたのが19時前で デパ地下のお寿司 を買いに行った。割引になるのを待っていたら19時を過ぎると20%引きのラベルを付け始めた。それをみて、サーモン詰め合わせ、マグロ鉄火巻、握り盛り合わせの3折箱を購入した。3-4人でつまむ程度の量。20%割引で3395円だったから定価だと4244円となる。これまでは720ml (四合瓶) のお酒をもっていくことが多かった。お土産用の、ちょっとよいお酒だとだいたい3000円前後かな。お寿司の方がやや値がはる。物価も上がっているのにあわせて手土産に使う金額も3000円程度という基準から5000円ぐらいまでは引き上げてもよいかもしれない。

• いとうさんのコメント

0時に寝て5時に起きて6時半に起きた。朝から大鼓方を調べたりしていた。

persistent search あれこれ

ldap プロトコルの文脈でクライアントがサーバーに接続して、エントリーの更新を検出して更新があったエントリーのみを取得することを persistent search (永続検索) と呼ぶ。メッセージキューで言うところの pubsub の consumer に相当する機能。フィルター条件に合致したエントリーのみを取得するという側面では検索と言える。

ietf のワーキンググループに次のような仕様がある。

• Persistent Search: A Simple LDAP Change Notification Mechanism

go-ldap で過去に Add Persistent search control + PersistentSearch() #80 で実装を追加しようとしたのもあったので調べてみた。しかし、この機能に openldap は対応していないようだ。

以前から調べている openldap の syncrepl も persistent search を実現する機能の1つと言える。ldap に詳しくないと用語と機能と実装の切り分けができなくて困惑する。syncrepl はもともとレプリケーションのための仕組みではあるが、pubsub の consumer としても使える。そういうときに syncrepl を使って “persistent search” を行うと言ったりする。このときに先の ietf に提案されている persistent search とはまったく関係ない。だから混乱する。

lopenldap サーバー同士で syncrepl の provider の機能は次の overlay モジュールによって提供される。逆に syncrepl の consumer の機能は openldap の組み込みの機能で提供される。なんらかの歴史的経緯があるのだろう。

overlay syncprov

ldapsearch コマンドで persistent search (syncrepl consumer) を実行するには次のようにする。

$ ldapsearch -x -H "ldap://localhost:389" -b "dc=example,dc=com" -D "cn=Manager,dc=example,dc=com" -w "secret" -E '!sync=rp'

ldap プロトコルの文脈で persistent search を行うといった場合、クライアントから pubsub で言うところの consumer を用意するといった意味だけで、その実装や通信方法はいくつか実現方法があるということを学んだ。

サイトデザイン最終レビュー

19時からデザイナーさんとはらさんと打ち合わせ。少し前に用意してくれた サイトデザインのサンプルページ の最終レビューを行った。全体としては気に入っているので概ね ok なのだけど、詳細の気になったところやデザインの機微のようなところをはらさんと一緒にデザイナーさんとやり取りして共有した。

デザインだけをみてこちらで想定していたことも、デザイナーさんの意見や視点を伺ってみると発見があっておもしろかった。逆に言えば、デザインだけでデザイナーさんの意図を伝えるのはとても難しいということもわかった。背景の説明を受けると論理的だったり合理性があったりするものの、なにも情報がない状態でそのことに気付くのは難しい。これはコードリーディングにおいても同じで、作者に意図の説明を受けながらソースコードを読むと簡単に理解できたりする。そして、デザイナーさんもうちらの意見から考え方を見直すこともあった。ウェブデザインのようなものを1人で完全に気付きを得るのは難しそうだ。

はらさんにレビューに入ってもらっていてとても助かる。私は ui/ux については素人なので、要件やレビューする視点の重要なところにツッコミを入れてくれるので気付くことも多い。私がコードレビューで設計やプログラミングについて指摘しているのも、別の人の視点からみるとこういうみえ方をするんだろうなと思いながら聞いていた。「餅は餅屋」とはよく言った言葉だ。自分がよくわからない分野のお仕事を依頼もしくは話すときは、自分たちの立場でそういった外部の専門家を雇うことの重要性も同時に理解できた。私は課題管理の専門家としてそういうポジションを作っていきたい。

0時に寝て5時に起きて7時に起きた。もう暑くて家でもエアコンを解禁した。エアコンがあると寝心地が違う、快適。

運用のトラブルシューティング

厄介なインフラの問題 のクリティカルな方から着手し始めた。podman-compose を使って rootless な環境構築をやってみたところ、nginx を tls 終端としてリバースプロキシとするアプリケーションサーバーとの通信が数回に1回ぐらいの頻度で遅くなる。通常は 100msec 程度でレスポンスが返るのが数秒から数十秒かかる。

もともと podman-compose はサポート対象外なのでそんながんばる必要はない。しかし、これも調査の過程でコンテナの技術を学ぶ1つだと考え再現環境を構築しようとした。vagrant の debian 12 と podman-compose をインストールして同様に環境構築してみたが、仮想環境では再現しない。どうやら環境要因のようだ。そこで問題が発生しているマシンで私のアカウントで環境構築してみたが、やはり再現しない。なんと個人アカウントの違いによって起きる現象のようだ。また質が悪いのは私のアカウントでは再現しないが、メンバー2人のアカウントでは再現している。一般ユーザーから他人のユーザーのプロセスやコンテナの情報にアクセスできるわけがないので調査ができない。個人アカウントで compose 環境を構築するのは諦めてアプリケーションアカウントを作ってやりましょうという話しにした。アプリケーションアカウントで再現すれば調査するし、再現しなければこんな環境要因のトラブルシューティングの優先度を下げてもいいかなぁとも考えている。どうなるかなぁ。

サイトデザインのサンプルページ

サイトデザイン打ち合わせ の続き。実際のサンプルが出てきたのでデザインの雰囲気やコードも含めて確認していく。ざっとサンプルページを確認した。デザインはとても気に入っている。あとは私が hugo のテーマとしてテンプレートの組み込めるかどうか次第。今週末には実家帰らないといけないし、毎日やることがいっぱいいっぱい。

4時過ぎに寝て7時に起きた。3時前まで相続手続きの書類作業して帰ってきてから本を読んでたら寝るのが遅くなった。

メンバーの oss へのコントリビュート

チームのメンバーがプロダクトで使っているライブラリにコントリビュートした。土日にライブラリのメンテナーからコメントがあって、その指摘にもすぐに対応して日曜日にマージされていた。ライブラリ側のレビューもすぐに終わってすごくうまくいったと言える。

• feat: enable DirSync control in search operation #436

もともとうちらが欲しい機能を作りかけた pr があったものの、作業途中でマージされずにクローズされていた。その残骸を参考にうちらの要件を満たせるかどうかの調査から始めた。調査を進めているうちにうちらの要件には足りない機能があってそれを拡張するようにも指示していた。すぐに出来たというのでライブラリにコントリビュートするように私が指示していた。

その後メンバーに聞いてみると、oss のライブラリにコントリビュートしたのは今回が初めてだという。開発者なら初めて oss にコントリビュートしたときのことを覚えているだろうか？私は、、、何だったか覚えてないが、おそらく linux distributor で働いているときに簡単なパッチを送った気がする。昔はメールや課題管理システムにパッチを投稿していたのが、いまは pr で気軽にパッチを送れる。若いメンバーがうまくコントリビュート経験を積めたことの背景に github がもたらしたパッチを送る簡単さがあるようにも思えた。oss にコントリビュートする機会は普通に oss を使って開発していればいくらでもある。マネージャーがその機会を見逃さず、ちゃんとメンバーにアサインしてあげることの大事さもあると思う。メンバーにはこの成功体験を活かして今後とも活躍してほしい。

サイトデザイン打ち合わせ

先日の ワイヤーフレームのレビュー の続き。顧問のはらさんとデザイナーさんと私の3人でデザイン案をみながらレビュー会をした。素人の私からみたら十分によいものが出来つつあるように思えるのでデザイナーさんのモチベーションを削がないようにサポートできればと思う。はらさんはデザインの専門家なので細かいところの確認や気付きをあげていてさすがという印象。きっとデザイナーさんのモチベーションも上がるのではないかと推測する。私はこれまでデザインの打ち合わせに出たことがなかったので参考になることが多々ある。サイトのトップは普通は会社の紹介があるものらしいけど、私がそれはいらないとデザイナーさんに伝えたのでトップで会社紹介を一切しない稀な構成のサイトのデザインが出来上がった。その後、社名ぐらいあった方がよいのではないかという話しもあってこれから変えるかもしれない。私の会社情報を書かない理由は次になる。

• 一見さんの訪問客がみるようなサイト (会社) ではない
• 知人やうちの会社の関係者がみて近況を手早く分かるようにしたい
• デザインはシンプルな構成にしたい

1時に寝て7時に起きた。ヤフー防災速報 を設定したら昨日の大雨で次から次へと通知が届いた。状況を注視しておいた方がよいのかもしれないけど、どんどん通知が届くことに驚いた。アプリ自体はよく出来ていると思うのだけど、大雨が強くなっていく過程で様々な通知が届くようになって、通知が届いたところで私はなにかするわけでもないため、徐々に通知を無視するようになってしまって、本当に重要な通知を見逃したりしないかと心配になった。そういう意味で通知設定のカスタマイズが大事なのかもしれない。

法人決算

連休中に申告書の作成は完了していた。8時30分からの e-tax の稼働を待ってマイナンバーカードで署名して電子申告した。すぐに納付情報が返ってくるので pay-easy で法人税と地方法人税の納付をした。その後、紙の決算書を税務署へ提出しにいく。経験則から朝早い時間帯に税務署へ行くと2-3人ぐらいしか訪問者がいないため、ほぼ待ち時間なく窓口の受け付けができる。e-tax のドキュメントには電子申告の受付番号を書けとあるけど、窓口ではいつ電子申告したか日付だけでよいと指示された。おそらくシステムの検索条件に使うだけなのだろう。

本日の9時15分をもって第4期の法人決算を完了した。まだ5月上旬の段階で決算を終えられたので気分がよい。昨年は月末にぎりぎり提出でバタバタしていた。お仕事の区切りが4月末だったというタイミングの良さがこの余裕につながっていると思う。昨年は初めての電子申告だったせいか、1ヶ月後ぐらいに書類の書き方が間違っていると指摘があり、訂正して修正申告することになった。今年はどうだろうか。

ワイヤーフレームのレビュー

先日からコーポレートサイトのデザインをリニューアルしようとデザイナーさんとやり取りしている。最初のワイヤーフレームが出来たので21時から顧問のはらさんとワイヤーフレームのレビューをしていた。他に契約書の叩き台のレビューも兼ねていたので時間がかかって1時間半ほど雑談していた。デザイン変更にあたって、どうしたいという運営者の要件があって、それに対してデザインや訪問者の ui/ux があるので一概にこうだとも言えない。いくつか私が気付いていなかったアイディアも出て、うちみたいな動きのない、しょぼいサイトデザインでも確認事項はいくつも出てくることに気付いた。デザインに対してあれこれ意見が出ること自体はよいことだという。発散した意見をデザイナーさんがどう現実に落とし込んでいくのかが腕の見せ所なんだろう。私はデザインの素人なので要件以外にあまり口出しするつもりはない。一方でどういった内容が要件なのか詳細なのかの境界もよくわかっていないので今回はデザイナーさんと一緒にやり取りしながら学ぶ機会とする。