4時に寝て6時に起きた。朝活があると何時に寝ても6時に起きれる。終わってからやっぱり眠くなって1時間ほど寝てた。お昼の外出から戻ってきて雑務やってから、なんか集中できなくて15時から帰ってお昼ご飯食べて2-3時間寝てた。寝る時間帯がずれると生活のリズムが狂ってしまい、全体でみると生産性が落ちるように思えてきた。水と金だけ6時に起きるのをやめて毎日6時に起きるべきだと強く思うようになった。

朝活

Webデザイントレンドのよりみち の金朝ツメトギに参加した。今回から「つめとぎ」から「ツメトギ」のカタカナに名前変更してパワーアップ？したみたい。本を読んでもよかったんだけど、チャット欄でコメントしながら live をみてみようと思って普通に聴いていた。#金朝ツメトギ というハッシュタグは私がコメントして生まれた。コミュニティ的に盛り上げるならタイムラインを共有した方がよいとは思う。youtube live のチャットにコメントした方がいいか、twitter で気軽にコメントした方がいいか、まだよくわかってない。youtube のチャット欄のコメントの一覧性とか、普段使いのツールになっていないせいか、なんとなく抵抗感がある。いま参加者が少ないせいか、コメントするとスピーカーがコメントに反応して返答したりするので、あまりカジュアルに書き過ぎるとスピーカーの作業の邪魔にならないかな？とか思ったりもした。youtube live という勉強会の人間関係の距離感が難しい。

あと Facebook Connect 2021 というイベントがあることを教えてもらった。友だちに共有したら会社を休んで参加するとか言っているので私も参加してみることにした。どうしようか迷ってたけど、身近な人たちが参加するとつられるのかもしれない。

法人県民税と法人市民税の中間申告と納付

前日(というか今日)に4時まで起きてたのは申告書の内容確認や記入をしてたから。せっかく申告書を作成したのですぐ納付したくなった。それで新長田の合同庁舎まで申告に行ってきた。eltax は相変わらず windows 向けの DL 版でないと申告できそうにない。WEB 版もあって一部対応しているようだけど、よくよく調べていくと DL 版でしかできないようにみえる。毎年 WEB 版でできるようになっているかどうかを調べている。この互換性を調べるような作業を都度やるのが面倒になってきた。vr 用途 (oculus link を使いたい) にも使えるので windows マシンを購入してもいいかもしれないと考えるようになってきた。申告書を郵送してもよいけど、1時間もあれば往復できる距離なので気分転換も兼ねて合同庁舎に出向いてきた。

帰りに新長田駅の近くの三菱UFJ銀行の支店で納付する。前回は窓口納付をしたが、今回は STM (Store Teller Machine) での納付に初挑戦した。STM(Store Teller Machine)の存在意義とは のブログ記事にも書かれている通り、納付書を OCR でスキャンすることでどんな納付書でも対応できるという汎用性はすごいと思うものの、その裏で人間がチェックしているんじゃないかと思えるメッセージや引き落とす合計金額はユーザーが手入力で決定する (OCR で合計がどの金額かわからなかった場合のみ？) といったオペレーションになっていて、なんか全く自動化されてない感があって残念に思った。見た目上、機械化されているけど、運用には人手がかかっているようにみえた。まぁでも、初めて使ってみて経験としてはおもしろかった。

Jira のフィルターとリマインダー

所得税や住民税の納付は原則毎月納付する必要があるけど、小さい企業は納付の特例という制度があって6ヶ月単位にまとめて納付できる。小さい企業の事務手続きの工数削減を狙いとしてある制度だと思う。うちもその特例制度を利用して6ヶ月ごとに納付している。カレンダーに繰り返し予定として登録してあるのでカレンダーをみていれば見落とすことはないのだけど、そのときに都度チケットを作ってやるのも面倒なので納付の親チケットを作っておいて、子タスクとして毎回作業するようにしている。それをみていて、納付期限を設定しておいてリマインダーしたら課題管理システムっぽくていいなと思って Jira でのやり方を調べてみた。Jiraにて期限の近い課題の通知を受け取りたい というのがあって、任意の JQL で期限を調べるフィルターを書いて、そのフィルターに対してサブスクリプションというメール配信設定を行う仕組みになっている。これはこれでよくできたうまい仕組みだと思う。しかし、いまチケットのイベントに対してメールを送る設定は無効にしていて、Slack インテグレーションを使ってすべて Slack の通知チャンネルにイベントを流すようにしている。できれば、Slack インテグレーションで期限のリマインダーを通知できるのが望ましいた。公式の Jira Slack app だと、JQL でフィルターはできるけど、イベント発生時に通知する仕組みなので毎週フィルター実行するような用途には使えない。

たまたまそんな話しをツィートしてたら Jira API と Slack API を使ってスクリプトを書いているというのを教えてもらった。これはこれで便利そう。

こんな感じのスクリプトでJIRAからslackに通知してます https://t.co/UzeIZ9Nbol

— Takanori Suzuki (@takanory) October 22, 2021

0-1時ぐらいに寝て7時半に起きた。よく眠れたか眠れてないかもわからないような目覚め方をして少しぼおっとしてた。朝ゆっくりしてもいいかと思いつつ準備して移動したら9時前にはオフィスにいたので普通の日とそう変わらない一日の始めだった。夜にジョギング行こうかと思ってたけど、ちょうど通り雨が降ったりやんだりしててやめた。代わりに雨やんでからオフィス行って調べてものしてた。

データ指向アプリケーションデザイン

7.3を読んで7章トランザクションを読み終えた。トランザクションの章は言葉も知らないし、あまりクリティカルなアプリケーションの開発に関わってこなかったのでそこまで意識したことがなかった。トランザクションで問題が発生する分離レベルと典型的なパターンが体系的に整理されていてすごく勉強になった。結果的にトランザクションを使わないとしても、トランザクションの要否や起きうる整合性の問題を理解しておくとデータ定義やアプリケーションの設計にも活かせる気がする。7章まで読んだ中でもっとも知らないことが多かった。約300ページなのでだいたい半分読み終えた。まだまだ先は長い。

トランザクションの開始時点でロックをかけるべきオブジェクトが存在せず、あるトランザクションでの書き込みが他のトランザクションの検索クエリの結果を変化させてしまう問題を ファントム と呼ぶ。ファントムの対策の1つとして、あらかじめそのデータを作っておき SELECT FOR UPDATE でロックを取得するやり方を 衝突の実体化 (materializing conflicts) と呼ぶらしい。グループウェアの開発をしていた頃、1つのスレッドしかトランザクションを実行できないことを保証するための切り札として、ロック用途のテーブルを設けておき、そのロックを獲得したスレッドだけ処理できるようにしていた。当時はわからなかったけど、あれは衝突の実体化という手法だったんだといま気付いた。

データベースのクラッシュや整合性に関する問題に対する信頼性を保つために、それらの問題を単純化するために、この数十年にわたって選択されてきた仕組みが トランザクション である。トランザクションは、アプリケーションが複数の読み書きを論理的な単位としてまとめる方法である。概念的には、トランザクション中のすべての読み書きは1つの操作として実行される。トランザクションは抽象化のレイヤーであり、アプリケーションはある種の並行性の問題や、ある種のハードウェアやソフトウェアの問題が存在しないかのように振る舞えるようになる。

トランザクションは全体として成功（ コミット（commit） ）もしくは失敗（ 中断（abort） 、 ロールバック（rollback） ）する。トランザクションが失敗した場合には、アプリケーションは安全にリトライできる。トランザクションは自然法則ではなく、データベースにアクセスするアプリケーションのためのプログラミングモデルをシンプルにするという目的を持って生み出された。トランザクションを利用すれば、ある種の潜在的なエラーの状況や並行性の問題はデータベースが面倒を見てくれるので、アプリケーションはそれらを気にしなくてよくなる（このことは 安全性の保証 と呼ばれる）。

トランザクションが提供する安全性の保証は ACID で示される。

原子性 (Atomicity)

• 原子（アトミック） はそれ以上小さな部分に分割できないものを指して使われる言葉
• マルチスレッドのプログラミングにおいては、あるスレッドがアトミックな処理を実行しているというなら、それは他のスレッドからはその処理の半分だけ完了した途中の状態を見る方法が存在しないことを意味する。システムが取りえる状態は、その処理が始まる前と終わった後の状態だけであり、その中間の状態になることはない
  • 前にメモリモデルの文脈で、あるプロセスが書き込み完了したデータが、他のプロセスからも確実に読めることをアトミックな操作と習ったことがある
• 原子性と並行性は関係がない
• エラーの際にトランザクションを中断し、そのトランザクションのすべての書き込みを破棄できることが、 ACID の原子性を決定づける特徴と言える
  • アプリケーションがリトライしても安全であることを保証する
  • 中断可能性（abortability） の方が原子性よりも良い言葉だったと思われる

一貫性 (Consistency)

• 一貫性は多くの意味で使われる
  • とくに日本語では整合性とも訳される
• 非同期のレプリケーションシステムでは結果整合性の問題が発生する (5章)
• コンシステントハッシュ法は、リバランシングのためにいくつかのシステムで利用されているパーティショニングのアプローチ
• CAP 定理では、一貫性という言葉は線形化可能性の意味で使われる (9章)
• ACID の文脈における一貫性は、データベースが「良い状態」にあることを示すアプリケーション固有の概念を指す

同じ言葉を少なくとも4つの異なる意味で使われている。ACID における一貫性という概念は、データについて常に真でなければならない何らかの言明（ 不変性 ）があることを指す。たとえば、会計システムの場合、すべてのアカウントでまとめれば常に貸方と借方は等しくならなければならない。この一貫性の概念はアプリケーション固有の不変性の概念に依存しており、一貫性を保つようにトランザクションを適切に定義することはアプリケーションの責任となる。原子性、分離性、永続性はデータベースの特性だが、一貫性は（ ACID という考え方においては）アプリケーションの特性である。したがって、 C は実際には ACID に属していない。

分離性 (Isolation)

多くのデータベースは、同時に複数のクライアントからアクセスされる。データベース中の同じレコードにアクセスするときに並行性の問題（レース条件［ race condition ］）が生じる可能性がある。データベース中に保存されているカウンタを、2つのクライアントが同時にインクリメントすると仮定する。それぞれのクライアントは現在の値を読み取り、1を加え、新しい値を書き戻す。ACID における分離性とは、並行して実行されたトランザクションがお互いから分離されており、お互いのつま先を踏みつけあうようなことがないという意味である。実際の運用では、パフォーマンスの制約から分離レベルによって保証される分離性が変わってくる。

永続性 (Durability)

データベースシステムが目的とするのは、データを失う恐れなく保存できる安全な場所を提供すること。永続性は、トランザクションのコミットが成功したら、仮にハードウェアの障害やデータベースのクラッシュがあったとしても、そのトランザクションで書き込まれたすべてのデータは失われないことを約束する。

用語の整理

トランザクションはデータモデルがどういったものであるかにかかわらず、価値あるデータベースの機能と言える。並行に実行されたトランザクションがお互いに影響しあわない分離性における保証を 分離レベル と呼ぶ。

• read committed
• スナップショット分離（repeatable read とも呼ばれる）
• 直列化可能

これらの分離レベルに対してトランザクションで発生する様々なレース条件がある。

• ダーティリード
  • あるクライアントが他のクライアントのまだコミットされていない書き込みを読める
  • read committed 分離レベル及びそれ以上に強い分離レベルはダーティリードは生じない
• ダーティライト
  • あるクライアントが他のクライアントによるまだコミットされていない書き込みの内容を上書きしてしまう
  • ほぼすべてのトランザクションの実装は、ダーティライトを生じない
• 読み取りスキュー（nonrepeatable read）
  • クライアントが異なる時刻にデータベースの異なる部分を見ること
  • この問題の最も一般的な回避策はスナップショット分離によるもので、これはトランザクションがある時点での一貫したスナップショットから読み取りを行えるようにする
  • 通常、MVCC（multi-version concurrency control）を利用して実装される
• 更新のロスト
  • 2つのクライアントが並行して read-modify-write サイクルを実行するとき、片方が他方の書き込みをその変更内容を考慮せずに上書きしてしまい、データが失われること
  • スナップショット分離レベルの実装にはこの異常を自動的に回避してくれるものもあるが、明示的なロック（ SELECT FOR UPDATE ）をしなければならない実装もある
• 書き込みスキュー
  • トランザクションが何かを読み取り、その値に基づいて判断を下し、その結果をデータベースに書き込む
  • この状況で、書き込みが行われた時点で判断の根拠となったプレミスが真ではなくなっている場合を指す
  • 直列化可能分離レベルのみがこの異常を回避できる
• ファントムリード
  • トランザクションが何らかの検索条件にマッチするオブジェクトを読み取り、他のクライアントはその検索結果に影響する書き込みを行う
  • スナップショット分離レベルは単純なファントムリードを回避してくれるが、書き込みスキューを伴うファントムに対してはインデックス範囲ロックのような特別な対応が必要となる

弱い分離レベルは、これらの異常のいくつかを防いでくれるが、それ以外はアプリケーション開発者に対処する必要がある（たとえば明示的なロックなど）。すべての問題に対する保護を提供してくれるのは直列化可能分離レベルのみ。直列化可能なトランザクションの実装方法は、3 種類ある。

• トランザクションを順次実行する
  • それぞれのトランザクションをきわめて高速に実行でき、加えて単一の CPU コアで十分処理できる程度にトランザクションのスループットが低いのであれば、これはシンプルで効果的な選択肢となる
• ツーフェーズロック
  • 数十年にわたって直列化可能分離レベルの実装において標準的な方法であった
  • パフォーマンス上の特性から多くのアプリケーションがツーフェーズロックの利用は避けている
• 直列化可能スナップショット分離（SSI、serializable snapshot isolation）
  • 新しいアルゴリズムであり、これまでのアプローチが持つ欠点のほとんどを回避している
  • SSI は楽観的アプローチを取っており、トランザクションはブロックされることなく処理を進められる
  • トランザクションはコミットの時点でチェックされ、その実行が直列化可能になっていなければ中断される

改正法人税法等の説明会

改正法人税法等の説明会 に参加してきた。所感からまとめるとこんな感じ。

• 神戸文化ホールについて
  • 電源がない
  • FREESPOT が提供されていてフリー wifi として利用できるが、通信品質は不安定
    • スマホでテザリングもやってみたが、電波状態がよくなくてもっと不安定
  • ラップトップ向きの場所ではない
• 税制を身近にするイベントとしては参加してもよい
• もらった資料をたんたんと説明するだけなのでイベントに参加することで得られる付加価値はとくにない
• 気分転換や時間があれば参加すればいい、忙しかったら参加しなくてもよさそう

公益社団法人 神戸納税協会 という組織がある。年会費 (うちの会社だと7,800円) がいるのでいまは入らないけど、無料税務相談があるので余裕ができたら困ったときの相談相手になってもらう意図で入会してもよいかもしれない。冒頭の神戸税務署長の挨拶で法人税の申告における e-tax の利用率は 88.4% だと話してた。うちは紙で申請しているので意外とみんな e-tax 使っているんだなと自社を恥じた。だって Windows マシンないとできへんねんもん。参加したことによる学びとして書いていくとこれらかな。

• 「研究開発費」は会計上の用語、「試験研究費」は税法上の用語
• DX 投資促進税制の創設

内容は基本知らないことなので、知らないことに触れるイベントという点では斬新ではあった。ほうほうと聞いてただけなんだけど。直接うちの会社に影響を与える税法の改正はインボイス制度ぐらいかな。

夜はドラクエタクトやってて2時過ぎに寝て7時に起きた。気のせいか、日記を書くようになってから早く寝付けるようになった。まつのさんが twitter で久しぶりに Python 書いたとツィートしていて、何気なくふと Implement experimental asyncio support #101 #340 をみて、そのツールの関係者でもないのに勝手にクソリプ的なレビューコメントをした。気付いてしまったらみなかった振りするのも気持ち悪いので。

インボイス制度の準備

2023年10月1日から 消費税の軽減税率制度・適格請求書等保存方式（いわゆるインボイス制度） が開始される。開始される前に適格請求書発行事業者に登録しておく必要があり、その登録受付が今日から開始された。前に知人が教えてもらった解説動画を見返した。

ちなみにうちの会社は今期から課税事業者になるのでインボイス制度開始による益税の影響は受けない。前期の決算で消費税を算出したとき、本則課税と簡易課税なら後者の方が46%の納税金額が少なくなることがわかった。IT 業界は経費に占める人件費の割合が大きい (人件費は消費税がかからない) ので簡易課税の方が節税になるのではないかという気がする。そのため、簡易課税で申請している。一度、申請すると2年間適用され、不適用届出を出さない限りはずっと簡易課税で継続される。

国税庁の 申請手続 をみながらe-Tax (WEB 版) で申請した。

個人で副業を受けることを想定すると、個人でも適格請求書発行事業者に登録した方がよいのだけど、私の場合、自分の会社なので法人で仕事を受けるのと個人で仕事を受けることの違いって何だろう？とわからなくなった。法人税と個人の所得税の税率の違いの話しは一旦置いておいて、最も大きな違いは会社で仕事を受けても(直近の)給与は増えないのでその報酬を自由には使えない。個人で仕事を受けたらその報酬を自由に使えるぐらいかな？もうちょっとその違いを調べ直してから考えよう。先の youtube 動画の中で税理士さんが「免税事業者という制度をやめたらいいのに。。。」と言ってたけど、個人はどうしよう？と悩んでしまう本質は免税事業者という概念があるからというのは正しいと思う。

Terminal のカスタマイズ

hugo の Shortcodes で class で任意の CSS クラスを指定できる。

{{< youtube id="E0lOsLfj1T0" class="video-container" >}}

static/style.css をカスタムの CSS として読み込んでくれる。youtube のビデオサイズをよしなに調整するために次のスタイルを定義した。なかなか難しい。

.video-container iframe {
    border:0;
    max-width: 600px;
    max-height: 338px;
    width: 100%;
    height: 50vh;
}

Joel on Software

読み終えた。ソフトウェアの本で test of time (時の試練？) に耐えるのは相当に難しい。本書だとマネジメントや教育、ビジネスや経営に関する内容はいまでも有効でおもしろかった。また後日ブログに書評を書く。いまとなっては手放しでお勧めできる本ではないため、どういう切り口で書くかが難しい。自分にとって学びとして身につけたいと思った本はなるべく書評を書いて自分の言葉で説明できるようになっていきたい。

カジュアル面談

プロジェクトマネージャーを募集している会社の CTO と面談。先方の時間が15分しかないという話しだったので事前に質問は連絡しつつ、バックエンドは Go 言語を使っているという話しだったので私が過去に書いたブログ記事やちょっと前に作った go-sql-executor を連絡して、技術選考の参考にしてほしいと伝えた。募集要項からスクラムを採用するように読めたのでその背景を聞いたところ、外部の技術顧問が推奨しただけでとくにこだわりはないという。いまもメンバーは8人いて1週間のスプリントでスクラムっぽい運用はしているとのこと。私の言う、課題管理とイテレーション開発の概要を軽く説明しつつ、それを実践するためにプロジェクトマネージャーをやりたくて、その実践の場を探しているといった話しをした。外部の技術顧問が欠席したせいか、Go 言語の開発に関する質問はとくになかった。メンバーはすべて業務委託という話しなので寄せ集めグループのドタバタプロジェクトなんだろうなという印象を受けた。心理的安全性や一体化マネジメント法とか勉強したんで グループ じゃなくて チーム 開発できるマネジメントがやりたいなぁ。