2時に寝て6時過ぎに起きた。睡眠はまぁまぁ。

今日の運動はレッグレイズ(椅子),腹筋ローラー,スクワットをした。統計を 運動の記録 にまとめる。

開発合宿の発表資料作り

気付いたらもう次の金曜日から始まる。開発合宿では参加者の親睦会を開いてそれぞれに20分ほど話をしてもらう。私もそのときに使うスライドを作り始めた。いま 運動やトレーニング に凝っているのでその話しをすることに決めた。

ランダムにメンバーを決めるための slack アプリ

主催者がランダム性をもってなにかを決めるとき公平性を担保するのが難しい。恣意的に決めようと思えば決められてしまう権限をもっているから。開発合宿の親睦会の発表順番を決めようと思って、なにかよいやり方はないかと調べてみて Team Picker という slack アプリを使うことにした。参加者は全員 slack にいる。これならアプリケーションがランダムに選択していることが参加者からみえる。このアプリケーションを私が開発しているわけではないため、少なくとも私がなんらかの不正をすることはできない。

軽く触ってみて使い方のドキュメントが丁寧でなかったり、(フリー版だから？) 操作していて timeout が発生したりもする。引数の誤りやスレッドへの返信などもわかりにくいエラーになる。ちゃんと動いているのか怪しい印象はあったものの、機能的にはまさに私が欲していた機能だったのでワークスペースに追加してランダム選択してみた。私の発表順番は8人中4番目になった。私は早めに発表した方が気軽に他の人の発表が聞けてよかったりする。後ろの方ではなくてよかった。

0時に寝て4時過ぎに起きて6時ぐらいまで起きてて1時間ほど寝てまた起きた。なんかおかしい。

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

定例会議

今日が feature freeze となる。開発は少し前には終わっていてとくに問題なく迎えた。余裕があったのでふりかえりをゆっくりやって、その後も雑談を多くしていた。

slack アプリ開発のチュートリアル

メンバーが slack アプリで llm を使った chat bot を作り始めた。slack のイベントを使ったアプリケーションの作り方を知らないようだった。過去に私が勉強会で作った slack アプリ開発のチュートリアルがあるのでそれを使って解説した。すぐに理解して、夕方には作り直して bot へのメンションイベントを捕捉して、その質問への回答を返す chat bot が出来上がっていた。どこで何が役に立つのかわからんもんよな。

• slack アプリ開発のチュートリアル

0時に寝て何度か起きて気分が悪くて吐きそうになりながら7時過ぎに起きた。昨日は飲み過ぎた。やはり年末でだらけているのでオフィスへ出勤したのが9時44分だった。

slack コネクト

昨日の 税理士さんとの打ち合わせ内容 の1つに chatwork のフリープランの メッセージの閲覧制限 への対応がある。以前は制限がなかったらしいが、どこかのタイミングで40日制限に変更されたという。slack もフリープランは3ヶ月に制限しているので世の中の流れとしては仕方ないのかもしれない。それはともかく、chatwork に (先方の負担で) 課金するか、slack コネクト へ移行するかの相談をしたら slack でも構わないという。先方も slack を有料プランで事務所内では使っているという話しだった。問題提起してヒアリングしてみたらなんのコストもなく移行できることがわかった。

早速、今日、調べて税理士さんを招待した。その際に社外の個人アカウントを使って slack コネクトの振る舞いも検証した。slack コネクトのよいところは次になる。

• 通常のメンバー同様、slack コネクトで招待したメンバーはチャンネル、プライベートチャンネル、ダイレクトメッセージを使える
• 自分のワークスペースに他組織のワークスペースのチャンネルを追加できる (参加するワークスペースが増えない)
• チャンネル名、トピック、説明はそれぞれのワークスペース管理となる
  • とくにチャンネル名を自組織のワークスペースの都合で名前を付けられるのがよいと思う

無料ワークスペースに設定されている使用制限 によると、フリープランは slack コネクトを利用できない。invitation を送るとフリープランでも接続できるが、それは pro のトライアルになるため、3ヶ月だけ使えるみたい。

開発合宿の打ち合わせ

先日 作成した旅のしおり を使って開発合宿の打ち合わせをした。打ち合わせをする前に見直していると、いくつも不備や誤りに気付いて1時間前ぐらいから修正したりしていた。私の作る資料は手直ししないと小さい誤りがいくつもある。参加者は現時点で7名で、いまのところ、これ以上増える見込みはない。昨年は4名だったのでおよそ2倍に増える。きのいえは9名まで宿泊できるようにみえる。神戸組4人に対して関東組は3人参加してもらえる。関東からわざわざ来てもらえるのは本当にありがたい。このぐらいの規模で数年継続できるような仕組みや体制を作るのが当初の目標でよい気がする。昨年は初めてだったので手探りだったが、今年は2回目なのでもう少し段取りやノウハウを使ってうまく運営できればと思う。

みんな時間通りに打ち合わせに集まってくれて、自己紹介して、主旨を説明して、大雑把なタイムスケジュールを紹介して、質疑応答をした。私の知人に声をかけているので神戸組と新規参加の関東組とはまったく面識がない。そういった人たちを少しでも話しやすいよう話題を設けたり、きっかけを作ったりすることがコミュニティマネージャーとしては求められる。別に私がコミュニティマネージャーを目指しているわけでもないが、コワーキングやコミュニティの価値の実践的なものを理解していく上で避けられないと考えている。私自身コミュ障で他人と話したくない人間なので、役割としてやらないといけないというポジションに追い込むことでその機会を得ていると言える。あと2ヶ月、詳細の詰めをしていく段階に入ってきた。

マネーの虎たちのその後

たまたまみたらおもしろかった。昔リアルタイムでみていた。いまの感覚でみればハラスメントやら人格否定しまくりの時代背景の史料の1つも思える。そのときボロクソに言っていた社長たちもその後破産している社長は多いみたい。そして、すごいのが数十億といった負債を抱えて破産してもまたやり直して復活している社長もいるということ。その再起のきっかけにセミナーや講演をしてマネーの虎を宣伝文句として使っているところが本当にダサいとは思うけど、そういったなりふり構わず売上を上げるためなら何でもやるといった姿勢が復活するためのバイタリティになっているのかもしれない。昭和世代のハングリー精神のようなものを感じる。

その中でも南原竜樹さんがすごい。年商100億の会社が取引会社の突然の倒産から資金繰りが悪化して破産して、2年かけてすべての負債 (20億円) を返済して、ホームレスになってからまた再起してまた年商100億まで復活したらしい。経営能力がある人はゼロから成功できるというのがよく分かるモデルケースにみえる。失敗して門前払いする人がいる一方、助けてくれる人もいたみたい。

• 元『￥マネーの虎』南原竜樹さん 年商100億円社長が45歳でホームレスに転落、どん底からの復活劇

一方で、手を差し伸べてくれる人もいた。中でもありがたかったのは、旧知の社長が会社の空きスペースの提供を申し出てくれたことだ。すべてを失った南原さんは、間借りしたオフィスで「過去の成功にとらわれず、心を入れ替えて再出発する」ことを心に誓った。

「僕は、“老害化”した経営者をたくさん見てきました。高齢になった経営者がいきなり頓珍漢なことを言い出して、周囲を困惑させるケースも少なくない。だからちょっと早めに準備して、いろんな方に事業を引き継いでもらいました。(…中略…) 頭も体もしっかりしているうちに、自ら退くのが一番なんです」

手持ちの資金はゼロだったので昼夜を問わず働いた。
「資金を得るためにオートバックスで8時間、吉野家で8時間、モービル石油で8時間バイトして、吉野家ではお客さんがいない時に立ったまま寝ていました（笑）。

22時頃に寝てしまって1時に起きて5時に起きて6時過ぎに起きた。とくになにもしていないのにバテている気がする。今週はずっと mongodb のレプリカセットの調査やインフラの移行作業などをやっていたせいか、普段よりもエネルギーを消費しているのかもしれない。朝から疲労困憊でオフィスへ向かった。

docker のコンテナネットワークの調査

docker のコンテナネットワークから解決できる名前がなになのか、よくわかってなくて、その調査のためにサンプルの compose サービスを作った。

• https://github.com/t2y/docker-compose-sample

myimage から nginx のコンテナの名前解決がどうなるかを試してみる。

c67a5ca94a77:/app# dig +short 00c719491558
192.168.240.3
c67a5ca94a77:/app# dig +short mynginx
192.168.240.3
c67a5ca94a77:/app# dig +short nginx
192.168.240.3
c67a5ca94a77:/app# dig +short yournginx
192.168.240.3

基本的にはサービス名、コンテナ名 (container_name)、コンテナー ID、ホスト名 (hostname) はすべて名前解決できる。hostname があるときはそのコンテナの /etc/hosts にその名前が追加され、ないときはコンテナ ID が追加されていた。

yourcontainer:/app# cat /etc/hosts
127.0.0.1	localhost
...
172.18.0.3	yourcontainer

冬の開発合宿の準備

日程を決めたのが5月末 で、うちの会社のワークスペースに slack のチャンネルを開設したのが10月。現時点で7人の参加者がいる。もうこのメンバーでいいかなと考えている。今回はコミュニティのワーケーションイベントというより、自社の開発合宿という体をとっている。スポンサーとしていくらか会社からお金も出す。その理由の1つは slack チャンネルにログを残したいという意図がある。コミュニティの slack だとフリープランになるので3ヶ月以上過去のログがみえなくなってしまう。それを解消するには自社の有料プランの slack チャンネルに置いておくのがもっともログを制御できて嬉しい。

城崎温泉では11月から 🦀 が解禁となって、今年は冬に行くので 🦀 を食べるというのも目的の1つ。チャンネルで盛り上げようと、たまに城崎温泉の記事を貼り付けたりしていた。そろそろ、メンバーと顔合わせの情報共有の打ち合わせをしようと思って調整さんを作った。他の人たちは、わざわざうちの slack のワークスペースにゲスト参加しているから、あまり無理強いをせずに情報共有できるようにしておきたい。たった1つの、ほとんどやり取りしないチャンネルのために slack のワークスペースをオープンしておかないといけないという用途はなかなか面倒だ。私が逆の立場でもそう思う。どうにか普段使っているワークスペースから、必要なときだけ連携できるような仕組みがないだろうか？

年末・年始の情報共有の打ち合わせへ向けて旅のしおりも準備していく。日々の業務に忙殺されて後回しにしがちなので自分を追い込むためにも予定を入れた。

0時に寝て6時に起きた。あまりうまく眠れなかった。

bolt for java

slack apps を開発するためのフレームワークとして bolt と呼ばれる高レベルのフレームワークが提供されている。このフレームワークは slack sdk を使って作られていて、slack apps の開発が簡単になるようにユーティリティが提供されている。The Bolt family of SDKs によると、javascript, python, java 向けに提供されている。以前 bizpy でも slack アプリ開発のチュートリアルの勉強会をしたことがある。そのときは bolot for python を使っていた。

• python-study/BizPy/slack

一度触ったことがあったので bolt がどういうものかはすでに知っている。その java 版を使って slack apps を作ってみようと取り組み始めた。まずはチュートリアルを一通りやってみようと次のリポジトリでやってみた。

• https://github.com/t2y/bolt-java-sample

チュートリアルの内容を動かすだけならすぐできた。次に java の waf は何を使おうかを調べてた。Supported Web Frameworks によると、次の4つがある。

• spring boot
• micronaut
• quarkus undertow
• helidon se

さらに slackapi/java-slack-sdk#modules をみると、次の2つも追加されている。どちらも kotlin 向けのフレームワークらしい。

• http4k
• ktor

それぞれのフレームワークの説明を読んだり、この機に kotlin をやってみることも検討してみた。長期間の保守を前提にすると、一時的に触るだけの言語を使うのもどうかな？と思うところはあってやはり java でやることにした。spring boot はお仕事でよく使っていてどういうものかを理解しているので選択するなら他の3つのどれか。

Quarkus was created to enable Java developers to create applications for a modern, cloud-native world. Quarkus is a Kubernetes-native Java framework tailored for GraalVM and HotSpot, crafted from best-of-breed Java libraries and standards. The goal is to make Java the leading platform in Kubernetes and serverless environments while offering developers a framework to address a wider range of distributed application architectures.

https://quarkus.io/about/

いま kubernetes に好印象をもっていることもあり、この説明を読んで quarkus を選択することに決めた。そんなことをつぶやいていたら、せらさんからいくつかアドバイスをいただけた。slack について何かをつぶやくと100%返信がくる (ソースは私の経験) 。感謝。

そうですね。App クラス側は servlet やその他のライタイム含め、何にも依存していないので標準でアダプターがない場合にも自分で書けば任意の Web フレークワークで動かせます。 #SlackDevJP

— Kazuhiro Sera (瀬良) (@seratch_ja) September 23, 2022

Quarkus いいですよ！ただ、GraalVM については少なくとも短期的にはサポート予定ありません。 https://t.co/0cVGgohLez #SlackDevJP

— Kazuhiro Sera (瀬良) (@seratch_ja) September 23, 2022

java アプリケーションを実行可能なバイナリにコンパイルする機能を graalvm が提供している。graalvm ではこのバイナリのことを native image と呼んでいる。quarkus は java の web アプリケーションフレームワークであり、graalvm を使って native image を作ることも考慮して設計されている。コンテナでデプロイすることを想定したフレームワークと言える。残念ながら slack sdk が使っているライブラリである gson はリフレクションを多用していて、それが graalvm とは相性が悪いだろうという話しで現時点では native image 化は難しいみたい。たしか native image でリフレクションを使うには使っている箇所を設定にすべて列挙しないといけなかった気がする。リフレクションのような動的に用いるものと静的な設定は相性が悪く、がんばれば特定のバージョンで動くものは設定できるかもしれないけど、ライブラリのようなものでバージョンアップに追随するのはしんどいという話しなのかなと思う。

slack と backlog の連携

backlog の rest api を使って課題一覧に定型的なフィルター処理を実行してその結果を slack に通知したい。日々のスクラムイベントで画面をぽちぽちしながらチェックするのにそろそろ飽きてきた。運用が熟れて、みないといけない課題のフィルター条件が明確になったとも言える。こういうのを人間が手作業でフィルターするのをやめて誰でも操作できて、頻繁に目に付くようにすることでメンバーの運用に変化をもたらす。人間の行動や運用を変えるのは並大抵のことではないので、こういった小さな気づきを絶え間なく与え続けることが大事だと私は考えている。気付く人はすぐに気付く。もちろんそうじゃない人もいるが。

backlog 公式 slack app は backlog で発生したイベントに対するデータを通知することしかできない。たぶん機能拡張されることもなさそうなので足りない機能は自分で作るしかない。当初は知人が働いている会社の次の記事を読んで aws chatbot を使おうと考えていた。

• プロジェクトにChatOpsを導入してみる

いろいろ調べてみると、chatbot は基本的に aws とのサービス連携を前提としたものだとわかった。もちろん lambda と連携することで backlog の rest api を呼び出すことはできるだろうけど、backlog にアクセスしたいだけなら最初から slack apps を自前で作ってそこから backlog の rest api を使った方が構成がシンプルでカスタマイズもしやすいのではないかと思えてきた。slack apps をどこにどうやってデプロイするかは検討課題と言える。lambda にデプロイすることもできるし、専用に ec2 インスタンスを設けてもいいかもしれない。すぐには結論が出ないのでデプロイは作った後で考えることにする。

次にサードパーティの slack apps のセキュリティはどうやって担保するのだろう？と調べてみた。slack 社もレビューはするけど、セキュリティを保証するものではない。適当にググってみつかった記事を読んでみても、基本的に悪意のない slack apps かどうかを検証する方法はなさそう。slack のメッセージを不正な用途に使われる可能性があるというリスクを受け入れつつ、サードパーティの slack apps をインストールするときに権限が適切かどうかを確認するぐらいしかできない。

• Slack App Security Review
• Third-Party Apps on Slack: Lurking Data Security Threat

従って、サードパーティ製の backlog slack apps を作ろうと思ったらソースコードを公開して悪意がないことを訴求するぐらいしかできることはなさそうにみえる。ソースコードを公開しておけば、それぞれの組織内でデプロイする手段も取れる。当社のプロダクトとしてクラウド上にパブリックに公開するかどうかはある程度、作り込んでから後で考えることにする。github のカスタム action は java で作ったけど、今回は go で作ろうと思う。

1時半に寝て6時に起きた。夜にウォーキングに出かけようとしたらたまたま雨が降ってきて諦めた。そしたら寝付けなかった。やっぱり歩いて疲弊すると寝付けやすいのかもしれない。ストレッチしたりしてたら寝るの遅くなった。

中間申告の納付

法人税・地方法人税の申告用紙が届いていたので内容を確認しながら e-tax で申請して pay-easy で税金の支払いを完了した。国税は一番最後に書類が届く。今年の書類が届いた日はこんな感じ。毎年記録しているから届く時期に準備していて慌てなくて済む。

• 法人市民税: 10月16日
• 法人県民税: 10月20日
• 法人税・地方法人税: 11月8日

国税の納付をもって中間申告をすべて終えた。中間申告は税金の先払いだからキャッシュフローが悪いと払えないみたいなことが起きる可能性がある。そうすると仮決算して支払い金額を抑えるみたいなことが必要になるんだろうな。まさに貧乏暇無し。

GitHub + Slack Integration

integrations/slack の内容をみて subscribe する内容を確認した。4月頃にアップグレードしてそれまでの設定の互換性をなくして、その影響でうまく動かなかったりしてた。

github の slack 連携のときの commits:all が commits:* に変更されたみたい。4月中旬のバージョンアップ以降に作ったリポジトリか設定だと commits:all だと連携されないみたい。https://t.co/mGVUyEbgGQ

— Tetsuya Morimoto (@t2y) April 30, 2021

その後、追いかけてなかったけど、いま README をみたら次の5つのイベントはデフォルトで有効になるみたい。

• issues
• pulls
• commits
• releases
• deployments

必要に応じて他のイベントも追加するとよいみたい。私は次の3つかな。

• reviews
• comments
• commits:*

デフォルトのイベントは指定しなくてもよいけど、コピペですべて明示的に設定するならこんな感じ。

/github subscribe owner/repo issues,pulls,commits:*,releases,deployments,reviews,comments

みんなの Python 勉強会

みんなのPython勉強会#75 で発表した。参加者は190人となっているけど、実際に zoom に参加していた人の最高値は110人ぐらいだったかな。190 * 0.6 = 114 なので無料イベントの参加者数は6割前後の法則に合致する。人数が増えるほどこの法則は精度が高いように思う。発表者は3人いて、私は2番目に発表して、持ち時間は30分だった。録画していたので後でアーカイブをみれるようにするみたい。私は録画否定派で録画すると参加者がオンタイムで見なくなるのと、いつでも見れるものは見ないということもあるので勉強会のレベルは録画しなくてもいいんじゃないかと考えている。もちろん大きなカンファレンスは録画があった方が参加できない人も後から興味のある発表を見返せていいとは思う。25分発表で質疑応答5分で発表の時間配分はうまくいった。あまり準備できなかった割には伝えたいことはだいたい話せたと思う。なんか質疑応答で「カザモリ社は python のお仕事を受けてくれますか？」といった質問があってちょっと驚いた。ここ数年 python をメインにしたお仕事してなくて、仕事は java, go が多いと言っているせいか、python の仕事はやってないようにみえてしまうのかもしれない。python, java, go の3つの言語のお仕事は受けますよと回答した。発表終わってから1時間ほど懇親会をした。ほとんどコミュニティの主催者と発表者で雑談してた。久しぶりに外部の勉強会でいろんな人とお話することができて楽しかった。たまには外に出かけていくことに重要性も認識できた。またネタがあったら発表したいなとは思う。

呑み

懇親会が終わったのが22時で、疲れと空腹から仲のよい焼き鳥屋さんのお店に寄って晩ご飯を食べることにした。時短が終わっているので22時からでも飲みに行ける。お店は翌2時まで営業している。22時過ぎに行ったらお客さんは誰もいなくて、野菜サラダと焼き鳥を注文してマスターと雑談してた。

時短が終わってから景気はどうかを聞いてみると、まだまだお客さんの戻りはコロナ前とくらべてまだまだだという。0時まわってから他の飲食店で働いている人たちが店内を埋まるぐらいは来てくれていたそうだけど、まだまだ余裕がないのか全然戻ってきてないと話されていた。0時半頃に2人組で「○○さんの紹介で来ました」みたいな既に酔っ払っているお客さんが来たりして、終電終わってからこういうお客さんが来たりしていたんだなと雰囲気は理解できた。マスターも2時に閉店して5時まで開いている他の飲食店に飲みに行くと話してた。そうやってお互いにお店に飲みに行って付き合いのようなものができているんだというのが理解できた。どこかのスナック行って3万円ほど使っても、必ずそのスナックの人がお店に来てくれて3万円以上使ってくれるという。お金をまわすってそういうことなんやなとマスターの話しを聞いていて理解できた。自分のお店を2時に閉店して、5時まで飲み歩いて、それから寝てまた次の日に仕事というのは体力的にすごくしんどそうで、マスター自身もコロナ明けは体調をみながら飲み歩いているとも話されてた。結局、2時前までマスターと雑談してて、私も22時から4時間弱ほど居座ってた。久しぶりに外で飲んでハイになっていたかもしれない。

マスターのお勧めで だいやめ という芋焼酎をお湯割りで飲んだ。香熟芋という珍し？芋を使っていて、ライチのような香りのする芋焼酎でおいしかった。お土産によさそうなので覚えておこうと思う。

0時に寝て5時半に起きたが、休日だからゆっくりするかと思って二度寝して8時に起きた。知人のタイムラインで紹介されていていい言葉だなと思ったので書いておく。日記があるとこういう流れていくちょっとしたことを書く場所にもなるな。コミュニティ活動の本質はこれなんじゃないかという気もする。

自分にまったく利益をもたらさない人間を、どう扱うかでその人がどんな人間かがはっきりわかる

サミュエル・ジョンソン

ストレッチ

今週もジョギングの代わりにウォーキングをしてた。ジョギングやると筋肉痛や疲労から他の日を休みがちになるけど、ウォーキングならジョギングよりは継続しやすい。今週は4-5日ほど歩いた。ただストレッチはさぼってて2日しかできなかった。ウォーキングのせいかわからないけど、右足太もも後ろの筋が張るようになった。ストレッチを始めてから日々の運動や生活の変化と関節や筋肉の張りが変化するのも意識するようにもなってきた。今日の開脚幅は開始前167.5cmで、ストレッチ後168cmだった。前週よりは数値がよくなっているのでこんなもんかもしれない。

神戸のコワーキングスペースの半歩先の未来を考える

たまたまタイムラインでみかけたので 神戸のコワーキングスペースの半歩先の未来を考える を視聴していた。私はシェアオフィスとコワーキングスペースが併設された場所で働いているのでテーマには関心がある。途中からだけど、13時半から15時までみていた。

第一部はコワーキングスペースの運営者が登壇して、どちらかというそれぞれの運営者がやっていることの、宣伝的な要素が強かったように思う。ある運営者が起業家を育てるのは大学生からでは遅くて、保育園から起業家教育をしているという話題があった。そこで何を教えているかというと、子どもの頃から徹底的に自己肯定感を高めるための教育をしているらしい。たまたま 自己肯定感が高い人の4大特徴が明らかに！ の記事をみたら、自己肯定感が高い人は他人も肯定するという内容がある。たしかに日本/日本人の同調圧力は異質なものを拒む傾向があると考えると、自己肯定感の高低がそういった文化の背景にも現れているのかもしれないと思えた。

第二部はコワーキングスペースの利用者として、二地域居住シェアハウスプロジェクトの研究/実践をしている佐藤さんと、メディアアートをされている 浅井宣通 さんが登壇していた。佐藤さんが冒頭でコワーキングスペースにはびっくりするほどすごい人がいるみたいな話しをした後で、浅井さんが登場するといった流れが偶然できてて、ほんとだ、これはすごいとなったw 浅井さんはメディアアートを言葉で説明しても伝わりにくいので動画でみてもらうようにしていると話されていた。私もみてこれはすごい人だとすぐに理解できた。私が興味をもつ作品だと 攻殻機動隊 新劇場版Virtual Reality Diver の Creative Director も務められたらしい。企業やイベントの PR のための映像で浅井さんが手伝っている作品はいくつもあるそうだ。

浅井さんは東京を脱出したいという想いがずっとあって、コロナでリモートワークが普通になり、奥さんの実家の須磨に引っ越してきたらしい。ただ自身は神戸にはほとんど知り合いがいない状態でコワーキングスペースを利用しているうちに、人を紹介してもらって人脈を形成することができたという。東京は大半が地方から出てきた人たちの集まりなので必然として孤立しており、競争関係になってしまうという。神戸の人たちは地元で育ってそのつながりが強いという違いを感じているらしい。地元の人なので協力の関係を築きやすい。コワーキングスペースがその触媒になっていると話されていた。人がつながるには、場所や触媒が必要でコミュニティマネージャーもそういった役割を担っていて大事だという。

多様性は大事だが、多様性だけでも人のつながりができない。同じ分野だとライバル関係になってしまったりする。そこで対話の深さが重要だと話されていた。同じ分野であってもお互いが対話を通して理解を深めると、共通項があったり、細かい得意分野が違ったりもする。デザイナー同士がかぶってしまうと、よく競争の関係になってしまうし、全然違う人と話しても話が噛みあわなくて仕事で苦労することもあったという話があった。それで対話の深さが大事ということに気付いたといった話だった。もう1点、おもしろかった話が地元の人は土地への感情として、この場所・土地が好きだという共通項があるので協力の関係を築きやすいのではないかと。東京は多くの人が生まれ育った土地ではないのでそういった感情は抱きにくいが、神戸っ子という言葉があるように神戸の人たちにはそういった土地に根ざした愛着があり、それを媒介につながるのも美しいといったことを話されていた。

第三部はコワーキングスペースを支える人たちとして、カフーツ の伊藤さん、ANCHOR KOBE の立ち上げ に関わった神戸市のイノベーション専門官の松山さん、fixU というサービスを提供している山岡さんが登壇していた。

私がもっとも興味深かったのは伊藤さんの話しだったのでそれをまとめておく。コワーキングスペースはただ作業する場所ではなく、課題を解決したい人がいて、それを手伝いたいという人がつながることで価値が生まれるという。長い間、コワーキングスペースに関わってきたことから経験が積み重なってわかってきたことがあると話されていた。「コミュニティはどうやって作るんですか？」という質問に答えるのは難しいものの、その取っ掛かりとして、まず課題をみえる化するのが大事だという話しをされていた。イベントなどで課題を表明して、多くの人たちに知ってもらうことで、その課題の解決に興味をもつ人たちが集まってきて、それが協調となり、コミュニティへとつながっていくという。Facebook 社が Meta 社に社名変更して、Microsoft もそれに追従し、メタバースの話題が盛り上がっている。ビッグワードに流されるつもりはないが、コロナによりオンラインでできることの幅が広いことを、仕事はオンラインでよいと多くの人たちは気付いた。じゃあ人と人との関わりがどんな価値をもつのか、コロナが落ち着いてくる時期 (この先1-2年) でそういう方法論も新たに出てくるんじゃないかとも話されていた。

Slack apps の調査

次回の bizpy 勉強会向けに 新機能、アプリのホーム・ヴューを活用しよう🏡 を読んで実際に bolt-python やってみた。UI の設定は JSON で記述できるようになっていて、Block Kit Builder でぽちぽちやるとどんな JSON を書けばよいかのサンプルのペイロードを確認できる。これらの UI に対して操作すると、プログラミングの用語で言えば、すべてイベントが発生してリクエストが届くような仕組みになっている。bolt のコード上ではそれぞれ event と action と view という名前が付いたイベントを扱うことで任意のモーダル画面を表示したり、そのフォームのユーザー入力を取得したりできる。一通りサンプルコードはできた。あとは簡単に資料をまとめるだけ。

2時に寝て6時に起きた。前日の夜にウォーキングしたせいか、よく眠れた。朝活を終えてから朝ご飯を作って食べてそのままオフィスに出社した。6時起きを日課にした方が生活のリズムがよい。夕方に眠くなって1時間ほど昼寝した。

朝活: ミクロ経済学入門の入門

【三宮.dev オンライン】リモート朝活もくもく会 で第4章の供給曲線を読んだ。需要曲線の逆からの視点なので考え方は同じで図の形が異なる。用語がいくつか出てきたのでまとめる。

• 収穫逓減 (しゅうかくていげん): 製品をより多く生産するのにかかる経費が増大していくこと
  • 生産活動において2倍の生産量を生み出すには2倍以上の経費がかかる
• 費用関数: 生産量と費用との関係をあらわす
• 限界費用: 追加的に1単位生産する費用
  • 3個を生産する費用は、1個目の限界費用 + 2個目の限界費用 + 3個目の限界費用
    • 個数が増えるごとに費用は高くなっていく
  • 費用を図示するときは限界費用に分解した方が視覚的にわかりやすい
• 限界費用逓増: 生産するごとに限界費用が高まっていくこと

「逓」という漢字は「つぎつぎ」や「だんだん」という意味をもつ。

• プライステイカー: 自分の生産量が価格に影響を与えられない
  • 減産により希少価値を高め価格を吊り上げる市場操作ができない
• 独占企業: プライステイカーの反対。
• 利潤: 売上 - 経費
• 最適解: 利潤を最大化する生産量
  • あと1個追加して生産すると利益がマイナスになるところ
• 生産者余剰: すべての企業の利潤の和
• 供給曲線: すべての企業の限界費用をヨコに足し合わせた曲線

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

昨日の続き。8.4 を読んで8章分散システムの問題を読み終えた。全体としても学びになったけれど、とくに 8.3 信頼性の低いクロックの節が全く開発・運用で意識したことがなかったので私にとっては学びになった。

分散システムにおいて発生する厄介な問題がある。

• ネットワーク経由でパケットを送信しようとした場合、そのパケットはロストしたり、どれほど遅延するか分からない。同様に、レスポンスもロストしたり遅延したりするので、レスポンスを受け取れなかった場合には元々のメッセージが到達したかどうかも分からない

• ノードのクロックは他のノードと大きくずれているかもしれない（できる限りの努力をして NTP をセットアップしたとしても）。クロックは急に進んだり戻ったりするかもしれず、たいていはクロックの誤差をうまく計る方法がないので、クロックに依存するのは危険

• プロセスは処理中にいつどれほどの長さ一時停止するかもしれず（おそらくはstop-the-worldガベージコレクタのため）、他のノードから落ちていると見なされた後に自身に一時停止があったことを理解しないままに復活するかもしれない。

こういった 部分障害 が生じうるのが分散システムの特徴と言える。ソフトウェアが他のノードが関わる何かをしようとした場合、それは時おり失敗したり、ランダムに速度が落ちたり、まったくレスポンスが返されない（そして最終的にはタイムアウトする）といった可能性がある。分散システムでは、部分障害への耐性をソフトウェアに組み込み、システムの構成要素が一部破損していてもシステム全体としては機能し続けられるようにする。

フォールトに耐えるための最初のステップはフォールトを 検出 することだが、それさえも難しい。多くのシステムは、ノードに障害が生じていることを検出する正確な仕組みを持たないので、ほとんどの分散アルゴリズムはリモートノードが生きているかどうかを判断するのにタイムアウトに頼る。しかし、タイムアウトはネットワークの障害とノードの障害を区別できず、ネットワークの遅延変動のために間違ってノードがクラッシュしていると誤検知することもある。弱っているものの落ちてはいないノードは、きれいに落ちているノードよりもさらに扱いが難しくなる可能性がある。

フォールトが検出されたとして、システムがそれに耐えられるようにすることも簡単ではない。マシン間にはグローバルな変数も、共有メモリも、共通の情報やその他何らかの共有された状態もない。ノードは現在の時刻についてさえ合意できず、ましてやもっと重大なことに合意することなどできない。あるノードから他のノードへ情報を流せる唯一の方法は、その情報を信頼できないネットワークを通じて送ることだけである。重要な判断は単一のノードだけで安全に下すことができないので、他のノードの助けを得てクオラムが合意に至るようにするためのプロトコルが必要となる。

同じ操作をすれば決まって同じ結果を返してくれるような、単一コンピュータにおける理想化された数学的な完全さの中でソフトウェアを書くのに慣れていると、分散システムの雑然とした物理的な現実への移行はちょっとしたショックを伴う。一方、分散システムのエンジニアは、しばしば単一のコンピュータ上で解決できる問題を簡単なものだと見なすが、実際のところ今日では単一のコンピュータがこなせる仕事量はかなりのものになっている。単一のマシンでシンプルにことを済ませられるなら、概してそうする価値はある。

分散システムを利用する理由はスケーラビリティだけではない。耐障害性や低レイテンシ（地理的にユーザーの近くにデータを置けることによる）も同様に重要な目標であり、こういったことは単一ノードでは実現できない。本章ではネットワーク、クロック、プロセスの信頼性の低さが避けがたい自然の法則なのかも調べた。安全ではなく、クリティカルではないシステムの多くでは、高価な高信頼性よりも安価な低信頼性が選択される。また、信頼性の高いコンポーネントを前提としているスーパーコンピュータも取り上げました。スーパーコンピュータはその前提が故に、コンポーネントに障害が生じてしまった場合には完全に停止させて再起動することになる。これに対し、分散システムはサービスレベルでは中断することなくいつまでも動作し続けられる。これは、少なくとも理論上はすべてのフォールトやメンテナンスはノードレベルで処理できるためである。

お昼ご飯

気分でスーパー寄って買いものして家に帰り、お昼ご飯を作って食べた。前に適当に作った かぼちゃの煮物 がおいしかったので再挑戦してみた。今度は圧力鍋を使っていろいろ具材を入れてみた。過去に作っておいしかった料理のレシピを evernote に書いたりしていたけど、もういまは書いてないので気が向いたら日記に書くようにする。

材料

• A
  • 水 900cc
  • めんつゆ 100c
  • 醤油 適量
• B
  • かぼちゃ 1/4切れ
  • なす 3個
  • にんじん 2本
  • 玉ねぎ 1個
  • しめじ 1パック
• C
  • 卵 2個
  • 豆苗
  • せみ餃子

作り方

1. 圧力鍋に A を入れて火にかける
2. B の野菜を切りながら圧力鍋に入れていく
3. 圧力鍋に B をすべて入れたら圧をかける (高圧30秒)
4. 圧が下がったら蓋をあけて C を入れる
5. C に火が通るまで2分ほど煮込む

所感

圧力が強過ぎたのか、かぼちゃが煮汁に溶け出してしまって原形がなくなってしまった。スープとして飲んでもおいしいけれども、水を入れ過ぎたのかもしれない。肉の代わりに餃子を使ってみた。水餃子っぽくなるので焼き餃子で油使うよりヘルシーな気持ちになっておいしい。

bizpy 勉強会

Python で Slack のインテグレーションをやってみる勉強会 #1 を開催した。半年以上開催してなかったので億劫になってしまっていたけど、再開できてよかった。10名ほどが参加してくれた。用意したコンテンツを話し終えたら8時半ぐらいで時間もちょうどよかった。初参加者も数人いた。slack インテグレーションの調査も兼ねてあと2-3回は集中的にやっていきたい。

3時に寝て6時に起きた。今日はちゃんと起き上がって朝からお茶を煮出して粗熱とって冷やしたりしてた。その後、準備してオフィスに着いたのが7時20分。いつもより1時間早く起きているのでオフィスに着くのも1時間早くなる。先週 の水曜日と金曜日だけ朝活やってみて逆に生活のリズムが乱れてよくない感じがした。今週は毎日6時に起きて朝活に参加してみるのを試す。

ミクロ経済学入門の入門

早起きしたので打ち合わせ前の隙間時間に第3章の需要曲線を読んだ。まずは用語の整理から。

• 上級財: 所得が増えたときに消費が増える財
• 下級財: 所得が増えたときに消費が減る財

一般的な傾向として、ものは消費するほど有り難みが減る。たとえば僕はコーヒー1杯目に最大4ドルまでなら払ってよいけれど、2杯目には最大2ドルまでしか払いたくない、そして3杯目には最大1ドルまでしか払いたくない、というように。

食べものとか実際にボリュームディスカウントされることが多いので食べものだとイメージしやすい。スーパーで半額になった豚カツを2枚買うときの私の気持ちはこんな感じ。定価なら1枚しか買わないのに半額なら2枚買ってもいいかと思ったりする。たまに2枚を一度に食べて気分悪くなって後悔する。たいていは晩ご飯に1枚、翌日のお昼ゴハンに1枚を分けて食べる。

• 余剰: 価格と消費者がお金を払ってもよい金額との差額
  • コーヒー1杯に400円払ってよいと考えていて、100円のコーヒーを買うなら300円が余剰といえる
    • さらにコーヒー2杯目を50円で買ってよいと考えるなら350円が余剰と言える

すべての消費者の余剰を計算したものを消費者余剰という。需要曲線からある価格 p を取るときの次のグラフにおける面積を消費者余剰と呼ぶ。グラフにすると直観的にわかりやすい。

消費者余剰に対して、売る側の利潤の合計を生産者余剰と呼ぶ。消費者余剰と生産者余剰との和を社会的余剰と呼ぶ。社会的余剰を「市場のよさ」のモノサシとして使うと談合は禁止すべしということになる。

• ベルトラン価格競争
  • 同品質で同費用の業者が価格競争をした場合、顧客は価格が安い方から商品を購入する。こうした市場をベルトラン寡占市場と呼ぶ
  • このとき業者間の価格競争は最終的に「底辺への競争」が起こり、経費と同じ価格に近づく
    • この状態をベルトラン均衡と呼ぶ
  • 業者間で談合して価格を据え置けばよいが、業者の数が多くなるとこれは難しい
    • 裏切りが発生したり、信頼関係を維持するのが難しかったりして、長期的な利益や全体の利益を追求するのが難しい
      • ゲーム理論の話しのように読めた
• 価格弾力性
  • 価格の変化によって需要がどのぐらい弾んで動くかをあらわす
  • 弾力性が低いというと、価格が動いても需要はあまり変わらない状態をいう
  • 弾力性が高い財は値上げすると需要が大幅に下がる
    • 必需品は値上げしても需要が下がりにくい
      • 課税で考えると、必需品への課税は貧しい人の生活に与えるダメージが大きい
• ギッフェン財
  • 需要曲線は右下がりのカーブになるのが通常だが、経験的事実に即している
    • そうした財を正常財と呼ぶ
  • ごく稀に価格が上がるにつれ売れ行きが増すものがある、それをギッフェン財と呼ぶ
• 代替効果: ある商品が値上げしたときに別の商品に置き換えたくなる
• 所得効果: 生活にゆとりがなくなると、高いものは買えなくなり、安いものを買おうとする

内容はそう難しくないが、急にたくさんの用語が出てきて読み解くのに時間がかかった。

設計ドキュメントレビュー

先週から作っていた設計ドキュメントを顧問さんと一緒にレビューした。スライド40枚を2時間がっつり話してめっちゃ疲れた。話し終えて20-30分抜け殻になって軽く散歩してきた。ここ3ヶ月、調べものをしてきた内容の集大成でもあり、頭の中にしかなかった課題管理の実践知を明文化するといった取り組みの (途中) 結果でもある。品質の良し悪しで言えば、たった3ヶ月で出来たものなので大したことはない。あくまで途上における段階でしかないのだけど、私の中でも納得感は出てきたし、レビューしてもらって厳しい指摘もなかったので方向性は出てきた感じがある。このまま時間のあるときに進めていく。

Slack apps の調査

この水曜日にある勉強会の 資料作成 が完了した。Slack apps の調査を勢いよくやりたいので2週間ごとに開催することにする。ドキュメントを眺めていて次回は 新機能、アプリのホーム・ヴューを活用しよう:house_with_garden: のチュートリアルをやってみることに決めた。

お昼寝

睡眠時間が短かったせいか、朝早かったせいか、夕方に集中力がなくなったので17時に切り上げて帰って寝てた。今日は雨だったので徒歩通勤だったのもありウォーキングにもなった。途中でスーパーに寄って買いものして帰った。運動目的だと1時間ぐらい歩いても平気なのに通勤だと15分歩くだけで疲れる。同じ行動をしていても目的意識で変わってくる。18時ぐらいには家に着いてそのまま4時間ほど寝てた。その後、また起きて夜の作業に入った。起きてからお腹すいて即席でめんつゆと醤油とかぼちゃとささみと卵で煮物を作ってみたら意外とおいしかった。お腹すいているとちょっとしたものでもおいしい。気に入ったのでカバー画像にしてみた。

2時に寝て9時に起きた。寝る前に1時間ほどウォーキングしてきたせいか、よく眠れた。田んぼをしたり運動をしたり体を動かして疲れた方がよく眠れるような気がしてきた。しばらく続けてみようと思う。お昼は調べものをしていて夕方に眠くなって2時間ほど寝てまた夜も調べものをしていた。

Slack apps の調査

この水曜日に勉強会があるので調査と 資料作成 をしていた。いつの間にか slack app 作成のためのドキュメントもいくつか 日本語化 されていることに気付いた。Bolt フレームワークを使って Slack Bot を作ろう のドキュメントをみながら bolt-python を使って簡単な bot アプリを作成した。アプリの設定・開発の流れはだいたいこんな感じ。

1. slack app 作成
2. bot ユーザー作成
3. oauth スコープの設定
4. bolt アプリケーションの実装
5. イベントサブスクリプションの設定

bolt とは別に python-slack-sdk というライブラリが提供されていて、このライブラリを使って bolt というフレームワークが実装されている。bolt でやりにくいことがあったら直接 sdk を触ることもあるのかもしれない。

現時点で勉強会の参加者は17人もいる。半年以上さぼっていたけど、けっこうな人数が参加してくれている。slack app の調査も兼ねて3-4回ぐらいは勉強会を開く予定。初回はアプリを作成するときの雰囲気を学んでもらえればと思う。