0時に寝て4時過ぎに起きて6時ぐらいまで起きてて1時間ほど寝てまた起きた。なんかおかしい。
今日の筋トレは腹筋:15x1,腕立て:15x1,スクワット20x1をした。
今日が feature freeze となる。開発は少し前には終わっていてとくに問題なく迎えた。余裕があったのでふりかえりをゆっくりやって、その後も雑談を多くしていた。
メンバーが slack アプリで llm を使った chat bot を作り始めた。slack のイベントを使ったアプリケーションの作り方を知らないようだった。過去に私が勉強会で作った slack アプリ開発のチュートリアルがあるのでそれを使って解説した。すぐに理解して、夕方には作り直して bot へのメンションイベントを捕捉して、その質問への回答を返す chat bot が出来上がっていた。どこで何が役に立つのかわからんもんよな。
1時に寝て4時に起きて2時間ほどだらだらして7時半に起きた。
今日の筋トレは腹筋:15x1,腕立て:15x1,スクワット20x1をした。
virtualbox に windows server 2022 のインストールと Active Directory ドメインサービスの構築 する方法のドキュメントを書き終えた。年度が変わったら新卒のメンバーがチームに入る可能性もあるし、滅多にやらない作業だし、windows のことを私はよく知らないので整理しておくとよい気がした。その後、メンバーのツール開発やインフラ作業のアドバイスややり取りなどをしていたら時間が経ってしまった。
年を明けて初めての テックブログ一気読み選手権20240122杯 に参加した。次の記事を読んで他の参加者に共有した。
この30分イベントのためにテックブログを読むことを強制されるのがよい。この日記を始めたことで「書くこと」と最近は「筋トレ」も継続できるようになった。短い時間の継続を目的とした仕組みをもっとうまく取り入れて他にも応用していきたいと思う。
5時前に寝て8時過ぎに起きた。夜に部屋のレイアウト変更して掃除し始めたら集中力が出てきてやりきってしまった。
今日の筋トレは腹筋:10x2,腕立て:15x1をした。夜に1時間で3-4kmぐらいは歩いたかな。
近くの文房具屋さんで クリヤーブックウェーブカット固定式A4縦 100枚青 品番:ラ-T590B を購入した。税込で4,697円になる。年度をまたいで有効な契約などの書類を一元管理しようと思う。うちが4年強で溜め込んだ年度をまたぐ書類として21ファイル使った。1つのファイルの表裏に書類を入れているので40書類ほどになる。クリアブックを机に置いても自立する。キャパシティの1/5程度しか使っていないのでまだまだ余裕がある。年度をまたがない書類は、基本的に法人決算の書類をまとめるための別クリアブックに保管している。その年に締結した契約書 (業務委託契約とか) なども年度決算のクリアブックに収めている。
年度をまたぐ契約というのは、例えば 経営セーフティ共済 の契約書などがある。こういった組織との契約だと、厚手の紙の立派な証明書が送られてくる。それを保管する義務があるのかどうかよく知らないが、これをシュレッダーにかける気にはなれない。立派なのでとりあえず保管しておこうとなる。
他にも初期の手続きの書類には契約条件や制約事項などが書いてあったりする。なにもトラブルがなければ不要だが、後になって調べたいときがある。例えば、2023年10月分からシェアオフィスの賃料の自動引き落としの手数料が200円請求されるようになった。請求額が増えていることに気付いて「おいおい。引き落としの手数料なんか聞いてないぞ。文句言ってやろう。」と思いつつ、念のため、契約書を掘り返してきて自動引き落としの手数料について記載があるかどうかを調べた。すると、自動引き落としの手数料は借り主が負担するとちゃんと書いてあった。つまり、2023年10月分から請求するようになったのは、これまで4年近く運営会社が自動引き落としの手数料を請求すべきところをなにかの手違いで見落としていて請求していなかったのだと推測する。その見落としに10月頃に気付いて請求するようになったと推測される。引っ越し前の契約書も 2022年12月に引っ越しした ときの契約書のどちらにも自動引き落としの手数料は借り主負担と書いてあった。ちゃんと契約書を保管していたので、運営会社に勇ましくクレームして、後になって自分が間違っていたと恥をかくこともなかった。
これまで種別やカテゴリ、取引先組織といった、なんらかのグルーピングをして書類をクリアファイルに収めていた。そうして4年経ったらやや膨らんだクリアファイルが数十できてしまった。そして、なにかを調べたいときに目当ての書類がどのクリアファイルの、どこにあるのかを探すのが煩雑になってきた。さらにクリアファイルを棚のあちこちに置くと、どこに置いたかも忘れてしまって、結局すべてのクリアファイルを机の上に並べて線型探索するみたいな作業になってしまう。この運用にうんざりしてきた。
そこで100枚入りの巨大クリアブックの出番だ。個々のクリアファイルに保管していたものを1つに収める。なにかあったらその1つのクリアブックを線形探索するだけで済む。クラウドに例えると、100枚入りの巨大クリアブックは s3 の1つの bucket で、書類はそこに格納されるオブジェクトになる。その bucket を ListObjects api で列挙すればどこかに入っているとわかる。その bucket は無限に拡張するのであふれることはない (巨大クリアブックは100枚が上限だが) 。運用ログを1つの bucket に溜め込む感覚と似ている。なにもトラブルがなければただのアーカイブだ。なにか起きたときだけ調査して見返す。これまでは、書類ファイルがローカルのファイルシステムにあったり、google drive にあったり、dropbox にあったりしていたようなイメージだ。
4年ぶりの開催 ということなので散策してきた。5年ほど神戸に住んでいるけど、ちゃんとルミナリエに参加するのは初めて。今回のメイン会場はメリケンパークにあり、有料チケットを購入することでイルミネーションの真下を歩ける。1時間ごとに5000人の人数制限をしている。チケット料金は前売り500円、当日券1,000円になる。屋台の出店も10件以上は並んでいてそこに100人ぐらいの行列ができて繁盛していた。19:30の開始時間の入場でちょうどそのぐらいの時間に行ったら入場ゲートで20分待ちの行列になっていた。入場ゲートが4テントほどあって、1つのテントに2つの入口があってチケットをもぎりしてカードを渡すといった運用になっていた。もう2倍ぐらいあったらスムーズに入場できんたんじゃないかと思えた。入場ゲートさえ通過してしまえばちょっと混み合っている程度の過密度だったので人数制限は適切だったと思う。入場ハックするなら1時間の区切りの終了時間の15分前ぐらいに行って行列を待たずにすぐ入場させてもらうのがいいんじゃないか？と思えた。
初めてちゃんと参加したルミナリエはこれだけの参加者を集客する荘厳さがあったように思う。鎮魂イベントやしね。普段みないような巨大イルミネーションを鑑賞して非日常の気分を味わえたと思う。今回は初めての1月開催、交通規制をせずに3会場分散配置、人数調整のための有料エリアなど、ルミナリエのイベント自体も新しい取り組みをしていたようにみえる。私は過去イベントに参加していないので比較しようもないが、混雑を制御できているという視点からはうまくイベント運営されているようにみえた。新しい企画をした運営スタッフはしてやったりじゃないかな？コミュニティのイベントスタッフをしていた影響でイベント運営の勘所みたいなところをついついみてしまう。
0時に寝て3時に起きてちょっとネットみたりしてまた寝て7時に起きた。
今日の筋トレは腹筋:10x2,スクワット20x1をした。
筋トレの疲労がたまっているのかもしれないが、今日も太ももの後ろの筋がかなり張っていた。胸筋もやや張りがあったように感じた。トレーナーさんによると、筋トレした後に使ったところはストレッチして伸ばした方がよいという。今日の開脚幅は開始前153cmで、ストレッチ後156cmだった。先週とほぼ同じ。
筋トレを継続できているのでトレーナーさんにいろいろ聞いてみた。
税理士さんに 電子帳簿保存法対応の事務処理規定の叩き台 をレビューしていただいた内容を規定に反映した。念のため、再レビューしてもらうが、これで完了とする予定。規定から実際の運用のためにガイドラインを作る。運用ガイドラインは notion にまとめる。
あまり 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つをブラウザで調べたものを表示させておくためのサブという使い方を気に入っている。ただの習慣かもしれない。
人間の視野は左右の眼を合わせると180度以上あります。 片眼の視野は鼻側に約60度、耳側に約100度、上方向に約60度、下方向に約70度と言われています。その中で、標識の文字を読むなど、モノのカタチや色などがキチンと認識できる範囲を中心視と言い、わずか1～2度ほど。中心視のまわりの必要なものを識別できる範囲、有効視野は左右に35度ほど。その外側である周辺視野では、カタチや色などをハッキリと認識することはできません。
モニターを入れ替えしたら埃っぽくなったのでついでにオフィスも掃除した。掃除機は sharp の EC-CT12-C を使っている。サイクロンだからパワーもあるし、ゴミ捨ても紙パックいらないから簡単。コンパクトで数ヶ月に1回ぐらいしか使わない私の用途にちょうどよい。普段は箱にしまってある。
箱から掃除機を取り出して、終わったら片付けるときに箱にしまい方も書いてある。他の掃除機はどうなのか知らないけど、たまにしか使わない家電で使ったらまた箱にしまうよねと気の利いたこの絵が嬉しい。掃除機を作ることに一生懸命だとこういう気遣いはできない。こういった配慮ができるのは会社の文化や組織や開発体制に「余白」があるからじゃないかと、私もマネジメントをしていて最近は思うようになってきた。この絵があるからこの掃除機を購入するわけではない。それでも、この掃除機を使っていて故障してもまた sharp の掃除機を買おうかなという気持ちにさせる。
マンションに帰って22時半から部屋のレイアウト変更を始めた。少し前に ホットクック を購入したものの、思いの外、大きくて置く場所がなくてそのための 置き台 をジモティーで購入していた。その置き台を台所の横に設置するには、本棚をどかす必要があって、それは重労働になるのでついつい先延ばししていた。こんな感じ。
設置して無線 LAN の接続や COCORO HOME に家電登録してアプリ間連携の設定をしていた。私のような Web 系の開発者からみると設定 UI やわかりにくさはひどいものだったが、家電メーカーの作るアプリはそんなものだろう。ホットクックの WiFi は 2.4GHz しかサポートしていない。うちの無線 LAN ルーターは 5GHz only で稼働させていたので 2.4GHz も有効化して接続した。私が購入したホットクック (KN-HW24G-W) は COCORO KITCHEN に非対応だった。COCORO KITCHEN は deprecated で今後は COCORO HOME になるのかな？COCORO KITCHEN で家電登録しようとしてうまくいかないとまごまごしていた。
23時に寝て4時半頃に起きてそのまま6時半までだらだらして起きた。早寝早起き。
今日の筋トレは腹筋:20x1,腕立て:15x1,スクワット20x1をした。
顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。内容が多くて1時間超えた。
はらさんが よりひろいフロントエンド を始めたそうでその話しも聞いていた。個人のブログサイトにするのか、複数人で記事を共有するサイトにするのかもまだ曖昧だという。Contentful + Next.js + Cloudflare Pages という構成らしい。Contentful というツールを私が知らなかったのでまた時間のあるときに調べてみようと思う。
母が一人暮らしをしていて体調もよくないことから要介護状態になるリスクがそこそこあると考えている。最悪の場合、会社を休眠させてしばらく介護をするかもしれない。はらさんが仰るには休眠はよいアイディアだという。会社員に例えると退職した日の帰り道を想像するとよいと話されていたのだけど、私は過去の記憶があまりないというのもあるが、これまで6回も退職してきたのに退職日を特別に思ったことはあまりない。退職日と他の日に大きな違いはなくて、次のお仕事の準備や調査をしていることが私は多かったと思う。それでも退職にあわせて有休を1-2ヶ月とってゆっくり過ごしていたことには変わりない。私もそういう、メリハリのある働き方が好きだ。
たまたまメンバーが誤った設定で smtp サーバーに接続したときにタイムアウトするまで5分ほどかかるという現象を発見した。タイムアウトの設定をせずに接続しようとするからそんなことが起きるのかな？と考えて smtp クライアントのタイムアウト設定を調べてみると net.DialTimeout を使えばよいという。
多めに見積もって30秒のタイムアウトを設定して接続するようにして再度メンバーに再現検証してもらったら直っていないという。接続そのものは出来ていたのだ。ソースを読んでみると、smtp クライアントを生成するときに 220 というレスポンスを読むことがわかる。誤った接続設定でもコネクションは確立するが、レスポンスが返ってこなくて待ち状態になっていた。
func NewClient(conn net.Conn, host string) (*Client, error) {
text := textproto.NewConn(conn)
_, _, err := text.ReadResponse(220)
if err != nil {
text.Close()
return nil, err
}
c := &Client{Text: text, conn: conn, serverName: host, localName: "localhost"}
_, c.tls = conn.(*tls.Conn)
return c, nil
}
調べてみると Conn インターフェースにデッドラインを設定する API が提供されている。注意事項としては接続した後にデッドラインをリセットしないといけない。
デッドラインとは、I/O操作がブロックされずに失敗する絶対時間のことである。デッドラインは、ReadやWriteを呼び出した直後のI/Oだけでなく、将来の保留中の I/O すべてに適用される。デッドラインを超過した後は、未来にデッドラインを設定することで、接続をリフレッシュすることができる。
デッドラインを超えた場合、ReadやWrite、その他のI/Oメソッドの呼び出しは、os.ErrDeadlineExceeded をラップしたエラーを返します。これは、errors.Is(err, os.ErrDeadlineExceeded)を使用してテストすることができます。errorのTimeoutメソッドはtrueを返しますが、期限を超過していなくてもTimeoutメソッドがtrueを返すエラーが他にもあることに注意してください。
アイドルタイムアウトは、ReadまたはWrite呼び出しに成功した後、デッドラインを繰り返し延長することで実装できる。tの値が0であれば、I/O操作はタイムアウトしない。
次のように SetReadDeadline() を使ってタイムアウトを5分から30秒に短縮できた。
func (s *Clinet) connectWithReadDeadline(conn net.Conn) (*smtp.Client, error) {
if err := conn.SetReadDeadline(time.Now().Add(dialTimeout)); err != nil {
return nil, fmt.Errorf("failed to set read deadline: %w", err)
}
c, err := smtp.NewClient(conn, s.config.Host)
if err != nil {
return nil, fmt.Errorf("failed to connect to the smtp server: %w", err)
}
// clear read deadline
if err := conn.SetReadDeadline(time.Time{}); err != nil {
return nil, fmt.Errorf("failed to reset read deadline: %w", err)
}
return c, nil
}
1時過ぎに寝て6時半に起きた。久しぶりによく眠れた。6時半に起きてたのに8時ぐらいまでだらだらしてた。
今日の筋トレは腹筋:20x1,腕立て:15x1,スクワット20x1をした。
Windows Server 2022 の試用版が提供されていると知ったのでローカルの VirtualBox 環境にインストールしてみた。Active Directory の検証に使うのでディレクトサービスや ldaps 接続のための証明書サービスなどを設定する。メンバーがインストールして課題管理システムにメモを残してくれてあったのでそれを見ながらインストールや設定自体はすぐにできた。1つだけうまく接続できないことがあった。
ホスト os から ldapsearch で ldaps で接続しようとすると次のようなエラーになる。
$ ldapsearch -x -H "ldaps://192.168.56.101" -W -b "CN=Users,DC=myad,DC=com" -D "CN=Administrator,CN=Users,DC=myad,DC=com"
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
ldap では接続できるので tls の検証のチェックに失敗していることは自明だったが、メンバーは接続できているようにみえたので私の環境の設定が誤っているのかどうかを調べていた。2時間ぐらいデバッグしたりしながら調べてもよくわからなくて、たまたまチーム勉強会があったので終わったときにメンバーに聞いてみた。すぐに完結した。ldapsearch は LDAPTLS_REQCERT という環境変数で tls のリクエストの振る舞いを制御できる。次のように明示的に指定すると接続できる。
$ LDAPTLS_REQCERT=never ldapsearch -x -H "ldaps://192.168.56.101" ...
この設定はいくつかの方法で設定ファイルに書いておくこともできる。メンバーが使っている環境には ldap.conf でこの設定を有効にしていたので ldaps 接続できていたというオチだった。私が openldap について明るくないのでこういった背景知識をもっていなくてはまっていただけだった。
Thus the following files and variables are read, in order:
variable $LDAPNOINIT, and if that is not set:
system file /etc/openldap/ldap.conf,
user files $HOME/ldaprc, $HOME/.ldaprc, ./ldaprc,
system file $LDAPCONF,
user files $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,
variables $LDAP<uppercase option name>.
Settings late in the list override earlier ones.
神戸ジャーナルの記事をみかけて、そういうイベントがあるのは知っていた。
開発合宿の翌週だし、わざわざ行くほどでもないかとスルーしていたものの、関東から知人がわざわざ歩きに来るという話しを聞いて、せっかくの機会なので私も参加することにした。土曜日の午前中に明石海峡大橋を歩いてくる。まだ申込みが始まったばかりなので希望の時間帯を選択できると思う。
3時過ぎに寝て1度起きて7時半に起きた。また体調を崩さないか心配になってくる。
今日の筋トレは腹筋:15x2,腕立て:10x1,スクワット20x1をした。
隔週で水曜日はメンバーと1on1をしている。今日は年明けで最初の1on1になる。あるメンバーと勉強のやり方について話題になった。私が普段、業務で行っている勉強のやり方を紹介してみた。
業務をしながらこれを繰り返してプロダクト開発をしている。
私からみると、経験の浅い開発者は勉強せずに、インターネットでググった内容をそのまま業務に応用しようとする。そして、理解の解像度が低いために誤った設計や実装をしてしまう。それで手戻りが発生したり、品質が悪かったりする。何度も公式ドキュメントを読んだ方がよいと提唱しているものの、これがなかなか勉強しないといけない人には通じない。私も過去にそういう時期があったので意図が理解できないというのも理解できる。だからこそ、この話しは何度でもするし、いつかそのことを理解できるときがきたら役に立つことだと考えている。
メンバーから「公式ドキュメントを読んでも書いてあることが理解できない」というコメントをもらう。そう。理解できないから自分でコードを書いて、動かしてみて、その勉強をするんだよと教える。本当にそれだけのことなんだけど、それだけのことも理解できずに他人が書いた信頼できるかどうかわからない記事のコードを使う人が多い。本質的には技術の勉強を過小評価している。経験の浅い人は1-2時間読み書きしただけでモダンなフレームワークの抽象化や振る舞いを理解できるはずがない。私でもバックエンドならたいていのことは理解できるが、経験の浅いフロントエンドは怪しい。だから、分かるまでもっともっと勉強しないといけないという認識が必要だ。1-2時間で終えようではなく、勉強も含めて2-3日かけようと思うぐらいでちょうどよい。
さらに私はメンバーに「時間がかかってもよいからちゃんと理解して開発しなさい」と、これも何度も何度もメンバーに伝えている。それによってタスクが遅れても構わないとすら言っている。他社のプロダクト開発でそこまで言うと経営者からクレームがくる可能性はあるが、おそらくお手伝い先の経営者もいっときの開発の速度よりも、地に足の着いた開発者として成長してもらう方がずっと価値があると理解してもらっていると、私は考えている。だからこそ、メンバーにそう言って、みせかけだけで開発しないように伝えている。
今日話していて、ようやく自覚できるようになってきたんじゃないかと手応えを感じた。1年かかったけれど。私自身マネージャーとして未熟でもあるし、マネジメントがよくなかったところもあるし、伝え方もよくなかったのかもしれない。それでも繰り返し繰り返し、開発において大事な価値観はメンバーに伝えていこうと気持ちを新たにした。
先日 石川県の災害義援金に寄付した ときにサイトにその日の残高を掲載していることに気付いた。関心をもったのでその記録を付けている。チェックを忘れたときは internet archive から分かる範囲で調べた。次のような感じに推移していて、そろそろ落ち着くのかもしれない。約60億円といったところ。他の団体や期間からの寄付もあるだろうけど、被害総額は約8,000億円らしいのでまだまだ全然足らない。
月例のカフーツさんのオンラインイベントに参加した。前回の所感はここ 。今回のテーマは「自治体とコワーキング」だった。私は行政を好ましく思っていない。行政と関わるお仕事もいくつかやってきた中で行政側の態度がよくなかったり、担当者も上から指示されたからやってますといったやっつけだったり、若い担当者は理解があっても決済権をもってなくて上司に没にされたり、一緒に働いていて楽しいようなお仕事に巡りあわなかったからだ。そして、目的意識からの違いから行政とのお仕事やプロジェクトが失敗とまで言わなくても、うまくいかないケースをいくつも見聞きしてきた。うまくいかないのに対して、うまくいったというのはほとんど聞いたことがないからまずうまくいかない。
それはともかく、行政と一緒になってコワーキングの事業をやろうとしている人たちもいるのでそれはそれでどんなことをやっているのかを聞いていた。今回は新しい参加者がいてその人の経歴ややっているコワーキングの行動なども聞けておもしろかった。街の人たちとどうやって仲良くなるかという話しで単純接触効果がもっとも効果が大きいのではないかと話されていた。なにもしなくてもそこにいて、徐々に人がくるようになって、人と会っているうちに仲良くなるといった話し。営業さんが取引先をまわるのもその戦略。
空き家バンク は住居向けしか対象としていなくて事業用にはなっていない。事業に使える空き家を探すのが難しい。空き家のマッチングシステムはあるようでないらしい。空き家がいっぱいあるのはわかっているので空き家をコワーキングスペースに改装して、町興しの拠点に使えばいいのではないかといった話しがあった。それはそうかもしれないが、私の感覚では、田舎にスペースは山ほどあるが人がいない。コワーキング的な新しい価値観で個々が自律して課題解決するような人を田舎でみつけるのはなかなか難しいと考えている。どちらかというと、一定の人口がいる地方都市や大きめの市が落とし所なのではないかと思う。
21時頃から寝て何度か起きて7時半に起きた。昨日は頭が痛かったら早く帰って安静にしてた。安静にしたら直ったので大したことはなかったみたい。
今日の筋トレは腹筋:15x2,腕立て:10x1,スクワット15x2をした。
いまどきの開発の定番としては ci/cd でコミット単位にテスト環境にデプロイする仕組みを構築している。テスト環境は1つだけになるのだけど、プロダクトの開発を1年以上やってきて機能が増えたことによって、1つのテスト環境で相容れない複数の要件や機能を混在させることで管理や運用が煩雑になってきた。気付いたタイミングがよい時期だと思うのでこの機会に1つのテスト環境を3つのテスト環境に分散させようと思う。既存データを確認するだけなら1つでもよいが、id 連携という機能の特性上、複数のシステム間でデータ連携するため、システム間での依存関係が発生する。それを整理しないといけなくなったという次第。今日のところは現状把握や移行に必要な段取りなどを設計していた。
昨日の続き 。23時過ぎに外に出たついでにオフィスに寄り道して書き始めたらまた熱中してしまって2時ぐらいまで書いていた。ハンズオンで説明する内容は一通り書いたつもり。せっかくの機会だから上級者向けにもう少し知っていることを書いてみようとは思う。
4時半に寝て7時半に起きた。深夜にハンズオン資料を作っていたらまた眠れなくなった。朝から頭痛くて調子が悪い。きっと生活のリズムが崩れているせい。早くお仕事を終えて帰って寝てた。
今日の筋トレは腕立て:10x1,スクワット15x1をした。
先週末から作っていたテストツールがようやく一通り動くようになった。ldap エントリーを生成したり、既存のエントリーに対して更新、削除、パスワード変更のリクエストをランダムに自動生成して送る。常時 id 連携の処理を動かしたときの並行処理の問題であったり、やや負荷をかけたときになにかの敷居値を超えて不具合がないかといった検証に使える。8月末に開発に着手して、年末から再開して、1月明けでようやく完成した。テストツールの開発の優先度が低いので後回し後回しにしているうちにどんどん後ろに流れていった。悪い開発の典型例。
昨日の続き 、、、をやろうと思っていたけど、頭痛でしんどかったので今日はお休み。イベントが公開された。
他のツールをみていて slate というツールは知らなかった。api ドキュメントを書くためのツールとある。
うちはいま redocly というツールを使って openapi のフォーマット (yml) で api ドキュメントを管理している。開発は openapi を使ってなくてドキュメントのためだけに openapi を使っている。量が増えてくると yml でドキュメントを書くのも辛くなってくるので markdown で api ドキュメントを書けるならそれもよいかもしれない。
2時過ぎに帰ってなんか眠れなくて4時半に寝て8時に起きた。なんか夜型になってきて変な生活リズム。
今日の筋トレは腕立て:10x1,スクワット15x1をした。
昨日の続き 。
朝からいろいろ直していた。やり始めると凝ってくる。スタイルやシンタックスハイライトなどを修正していた。
新年もくもく会 に参加した。なぜか今回は参加者が多くて15人ぐらいほぼ満席だった。lt 大会の内容は新年なので今年はこんなことやりたいという抱負を発表する人が多かったように思う。一通り lt を聞いてから、午前中に引き続き、ハンズオン資料の調査をしていた。夕方眠くなって集中力がなくなっていた。軽く1次会だけ行って眠くてそのまま帰ってきた。
飲み会から帰ってきて2時間ほど寝て、それからまた再開して2時半ぐらいまでやってた。サイトの構築とテーマの設定のところを書き終えた。初心者向けにハンズオン資料を書いているが、テーマの設定はなかなか難しいなと思える。拡張を作り込んでいるテーマもあるが、設定方法のドキュメントはあまりないことが多い。デモ画面とそのソースの設定ファイルをみながら空気を読むみたいなところで初期設定をしていかないといけない。
晩ご飯食べてくつろいでからまたオフィスに戻って作業してた。3時過ぎに寝て8時に起きた。寝不足のせいか、今日も夕方に眠くなって家に戻って3時間ほど寝てた。
今日の筋トレは腹筋:25x1,腕立て:10x0,スクワット15x1をした。
今週もとくにお仕事で疲労や負荷はないものの、筋トレを継続しているせいか、やや腰が痛いかなといったところ。トレーナーさんによると、筋トレで筋肉痛になっていると体が硬くなるという。おそらくそのせいでやや硬めの印象になっているのだと思う。腰や太ももの前・後ろの筋に張りがあったのでこれらはスクワットの反動ではないかと思われる。今日の開脚幅は開始前152cmで、ストレッチ後157cmだった。先週と同じだ。
ジモティーで「ハンガーラック」を500円で購入した。これもコワーキングスペースで使う。この前帰ったときにジャケットを掛けるものがないと気付いた。引き取りに東灘区へ行く機会が増えてきてだいぶ道を覚えてきた。マンションの駐車場まで行って、そこでハンガーラックを受け取った。解体してくれていたので難なく荷室に積めた。丁寧な方で駐車場から車が出ていくときまでお見送りしてくれた。ジモティーだと受け渡しが終わったらすぐ帰る人の方が普通なので性格なのかホスピタリティの違いが出るなと思った。
日記を書こうと決めて初日に書いた内容 が iostat-tool の保守だったなと思い出した。2年半ほど前。一昨日からプルリクエストが届いていたのでレビューしたり、CI 環境の設定を更新したりしてマージした。
マージしてから 0.3.1 として https://pypi.org/project/iostat-tool/ にパッケージをアップロードした。
先週の続き 。17時からの予定だったが、プランナーさんの前の予定が早く終わったそうで15時半からに変更になった。お昼以降ならいつでもよいと伝えていたのでこういった調整ができてよいと思う。卓上カレンダーをお土産にもってきてくれた。今日は次のような内容を話した。
先方もどうせ来るならもっと準備して来たらいいんじゃないかとも思うが、次は teams でテレビ会議にしましょうと提案した。30分の打ち合わせのために三ノ宮のオフィスまで来てもらうのも申し訳なく思えてきた。その際にメールアドレスを伝えていて「すべて小文字ですか？」と聞くのでメールアドレス (ドメイン名) は大文字小文字を区別せず、大文字でも届きますよと教えてあげたら思いの外驚かれていた。昔からある古い仕様は大文字小文字を区別しなかったりする。大文字小文字を区別しないというのは、多くのケースで百害あって一利なしだけれども、互換性のために変更することもできない。
先日の打ち合わせ を受けて資料作りに着手した。hugo のサイト構築やテーマ設定は一度行ったらそうそう変更することはないので久しぶりに設定したら忘れていて、これどうだったかな？とか、このフォーマットはどこからきているのか？とか、いろいろ調べて思い出しながらやっていた。
hugo は設定ファイルを yaml, toml, json で記述できる。フォーマットを複数対応するというのはよくないということに気付いた。json はみたことないけど、テーマのサンプルの設定ファイルを yaml と toml の、開発者が慣れた方を使う。そうすると、テーマのサンプルの設定ファイルを yaml で提供していて、hugo.toml でサイトの設定をしていた場合、テーマの設定を yaml から toml に変換する作業が発生する。コンテンツの markdown も toml と yaml の両方で記述できるからフォーマットの統一感もなかったりする。なによりも初心者が調べたときに設定ファイルが toml だったり、yaml だったりして混乱する。
デフォルト設定は toml になっているので hugo で yaml は使わない方がいいんだろうなと思えた。
さらに設定ファイルの名前も昔は config.toml だったのが、最近は hugo.toml に変わり、さらにどちらのファイル名でもよいという仕様になっている。こんなことになんの意味があるのかもわからない。
With v0.109.0 and earlier the basename of the site configuration file was config instead of hugo. You can use either, but should transition to the new naming convention when practical.
まずはサイト構築して github actions で github pages へアップロードする環境構築を完了した。
徐々にコンテンツを追加していく。