ツールを使ってテストしていて、成功するはずのリクエストが失敗して、ログを調査しながらデバッグしていた。ldap エントリーを扱う難しさの1つに、ldap サーバーはエントリー間の依存関係やデータの整合性といったものを検証しない。そういった用途はアプリケーションの役割であって、ldap プロトコルはあくまで id を管理することに特化したものという役割分担になっているのだと推測する。そうすると、(open) ldap サーバーへ登録できたエントリーが次の agent や api サーバーといったアプリケーションのレイヤーでエラーになることがある。このとき、ldap サーバーではエラーが発生していないため、直接的なエラーを検知することができなくて、デバッグや調査に時間がかかる。
agent の実装として、ユーザーエントリのストリームとグループエントリーのストリームの2つに分割して、非同期にそれぞれのエントリーを id 連携する設計にしていた。というのは、ldap エントリーにはユーザーやグループといった概念は原則として存在しない。そのエントリーがユーザーなのか、グループなのかはアプリケーションが判断している。アプリケーションの用途としてはこの2つを明確にわけないと不便なことから、ワークアラウンドもしくは実務的な解決策として検索するときのフィルターと base dn で管理するようにしていた。そして、これらをそれぞれ別のストリームとして扱うよう、私が設計していた。このことがタイミングによってはユーザーエントリーとグループエントリーに依存関係がある場合、データの整合性を保証できないことに気付いた。なぜならば、ユーザーエントリーとグループエントリーそれぞれ非同期/並行に処理されてしまうから。
あまり notion を使う気になれないのは、課題管理システムをメインに使っているから wiki もそこにセットで付いていてほしいという願望がある。うちは jira cloud を使っているので本当は atlassian の wiki プロダクトを使いたいところだが confluence が使いにくいから使っていない。atlassian は confluence とは別にもっと軽量でシンプルな wiki プロダクトを別途提供すればよいのでないかとすら思う。一方で esa や notion のような、wiki 単体のサービスを活用するのは課題管理システムとの連携において不便なように思えた。だから notion は最近プロジェクト管理の方に手を広げているのかもしれない。 github や gitlab のように、課題管理システムと wiki はとても相性がよいのでツールセットで提供するのがよいと思う。今後のプロダクト構想の中で wiki を考えていなかったけれど、アプリケーション間連携という視点から考察してもよいかもしれない。
sns などで電子帳簿保存法対応がすごく大変といったメッセージをたまにみかける。この法律は電子取り引き (請求書や領収書を pdf ベースでやり取りするサービスなど) に対応するもので紙の請求書や領収書でやり取りしている事業者には影響はない。しかし、昨今取り引きが電子化されていく流れでもあるため、電子取り引きはまったくないという事業者もあまり存在しないのではないかと思う。そして、これまではそういった事業者が取り引きの証拠となる電子データを消失してしまっても法律から言及できないという状態だった。電子取り引きはデータしかその取り引きがあったことを証明する証拠がないのにそのデータを消失して OK なわけないよね?というのが本来の電子帳簿保存法の目的になる。
低辺 sier のひどい労働環境や多重請負契約の構造を it 業界の代表的なもののように揶揄されるのと同様、いかに世の中のできない人たちが自分たちのスキル不足や知識不足を大騒ぎしてその内容が正当であるかのように喧伝しているのかが伺える。まともにシステムを使っている会社は電子帳簿保存法で大きな影響を受けない。多少の運用手順が変わったり、システムの開発が必要になったりする程度だと思われる。これはインボイス対応もそう。うちのようなマイクロ法人でもインボイス対応は新規の取引先を登録していく作業が増えたぐらいで日々の会計処理にほとんど影響を受けていない。世の中のニュースと実際の実務運用に大きな乖離がある。そして、実際にやったこともないような人たちが「弱者いじめ」だと党派性をもって大騒ぎする。
モニター変更
これまで27インチと24インチのダブルディスプレイを使ってきた。実家 (コワーキングスペース) に27インチのモニターを持って帰ろうと思って、24インチのモニターをもう1つ買ってその入れ替えをしていた。24インチ x 2 のダブルディスプレイに変更した。27インチ x 2 は有効視野を考えると幅が広過ぎて私にはあわない。首振りが疲れる。1台でもっと大きいモニターを使うという選択肢もあるかもしれない。しかし、私はなんとなく2台のディスプレイで1つをコードを書くメイン、もう1つをブラウザで調べたものを表示させておくためのサブという使い方を気に入っている。ただの習慣かもしれない。
駅の南側はうってかわってオフィス街となっている。ビルが立ち並びお店などはあまりない。駅の南北で役割分担をしているような、おそらく都市計画でそういった整備が行われているのだと推測する。税理士さんの事務所まで、姫路駅から徒歩20分ぐらい歩いた。あらかじめ調べた上で歩いたわけだけど、それでもやや遠かった。体力が落ちていて駅から徒歩20分とか、普通には歩けないようになりつつあるのかもしれない。帰りはタクシーを使ったら運賃が1300円だった。三ノ宮から姫路まで JR で990円なのにこの距離で1300円なのかとか、いろいろ思うことがあるな。
1ヶ月に1-2件ほど折りにふれて税務相談をする機会があったりする。税理士さんとは chatwork でやり取りしている。これがストレスになってきたのではらさんに相談にのってもらった。はらさん曰く、税理士さんの普通と it 業界のうちらとは業務の取り組み方への姿勢がまったく異なるため、最初の1年はストレスや不満がたまるのはあるという。士業という資格によって独占的に保護された業務のせいか、顧客に寄り添った対応をしてくれるわけではなく、質問の背景や意図を汲んでくれなくて質問に回答を返して終わりといった、チャットなのにメールのような一問一答のようなやり取りになっている。さらに回答が意図した内容ではなくて、追加で質問や背景の説明をしても、すぐにレスポンスが返ってくることはなく、数時間たってから回答が1つ届き、それも期待したものじゃないとさらに質問して、さらに数時間といったやり取りで5-6往復するのに数日かかるのがざらにある。はらさんがいうには税理士さんの回答を得るのに1週間ぐらいかかったり、問い合わせを数日放置されるのも普通とのことらしい。
インボイス対応もあるため、請求書に明細を書いて pdf で送ってくださいと依頼して2日間返信なく放置されている。税理士さん事務所の顧問報酬の明細や請求書について尋ねても即日に返信がこないような状況になる。はらさんが言うには税理士さんの対応とはそんなもんらしい。チャットでやり取りしている意味がないし、こんなググればわかるレベルのやり取りしかできないなら解約も検討している。もう1つ懸念に思っているのは本人がチャットで回答していないのではないか?と考えている。チャットなのに1問1答でしか返信がこないし、コンテキストが伝わっていないと感じることも多々ある。とてもベテランの税理士さんが答えているとは思えないコミュニケーションの齟齬がある。