0時に寝て6時に起きた。夜になにか作業をしようと考えていたけど、帰って晩ご飯食べたらだらだらしてた。

ブログ記事の執筆

今度の jjug ccc にチームの同僚と一緒に登壇する。同僚の発表スライドをみていて15分で話すには詳細を説明できないことに気付いた。せっかくイベントで発表して、よいプラクティスもできたのにもったいないとか思い始めて、発表の補足資料となるブログ記事を書きたいと私が言い始めた。先方ものってきてくれて、会社ブログを管理している社内の担当者を紹介してくれてそこに技術記事を書こうという打ち合わせをした。聞くところによると会社のテックブログはまだなく、技術記事も1つもないという話し。今回が初めての技術記事を公開する試みになるらしい。それはともかく、note の新エディタ が使えるようになっていたので初めて試してみた。新エディタの紹介記事を眺めてて画像のキャプションも入れられるようになったのにも気付いた。箇条書きの機能が増えたところはよいけど、勝手に段落がフォーマットされる感じが私の好みではない。エディタが勝手にフォーマットするのではなく、書き手が明示的に指示したときだけフォーマットされるような仕組みを私は好む。とはいえ、一般人は自動的によしなにやってくれる方がよいのかもしれない。半日ぐらいあーでもない、こーでもないと試行錯誤しながら一通りアウトラインに沿った草稿を書き上げた。

0時に寝て6時半に起きた。

ドキュメント作成

今週はあまり開発せず、バックログの wiki にドキュメントを書いてた。バックログの wiki は慣れると書きやすいし、Backlog Power Ups の chrome 拡張をインストールすると PlantUML で UML もレンダリングできる。ドキュメントの階層化はタイトルに / で区切ってグルーピングするというちょっと変なやり方。wiki のタグはフィルター条件として使いやすいように思えた。添付画像のサイズ指定ができないか調べてたら、ヌーラボコミュニティがあることに気付いた。せっかくなので 改善要望 を投稿しておいたけど、過疎っててあまり意味がないかもしれない。

1時に寝て7時半に起きた。昨日も半日ぐらいはコードを書いてて pr の草稿を作って帰ってきたら23時ぐらいだった気がする。

3ヶ月フィードバック完了

先日、書き始めた 3ヶ月フィードバック を書き終えた。平日少しずつ書こうと思ってたんだけど、平日は疲れて書かなくて、休日にまとめて書いた。最終的には1万文字ほどになった。見出しはこんな感じ。実質2日しか作業していないけど、2週間かけた。

• 開発プロジェクトに参加して気付いた3つの大きな課題
• 初めてスクラム開発をやってみた所感
  • 所感
  • スクラムのよいところ
  • スクラムのわるいところ
• 課題管理システム (チケット駆動開発) と情報共有
  • 情報共有とは
  • 課題管理と情報共有
• 情報共有とコミュニケーションコスト
• Pull Request のレビューと開発の生産性

明日プロジェクトのメンバーに共有してみる。反響があるのかどうか？もしかしたら誰も読まないかもしれないけど、私自身の思考の整理にもなっている。ここで書いた内容を洗練させてコンテンツとして再利用できるようにもしていきたい。

ストレッチ

本当はこの週末に ワーケーションへ行く予定だったが延期した 。いつもは土曜日の午前中に通っているストレッチを日曜日の夜に変更していた。

最近は日曜日をだらだら過ごす日が多いのだけど、今日は夜にストレッチの予定が入っていたので午前中は自分でストレッチして、午後から3ヶ月フィードバックを書き終えて、夜に Dr.stretch さんでトレーナーさんにストレッチしてもらうといった、平日のような充実した1日となった。休日も予定を作った方がきびきび動ける。いかに自分が怠惰かを思い知る。今日の開脚幅は開始前166cmで、ストレッチ後169cmだった。今週も全然ストレッチしなかった割にはまぁまぁよかった。

0時に寝て8時半に起きた。今日は雨降りだったのもあって1日お休みしてた。

3ヶ月フィードバック

はらさんと 雑談したこと を整理しながら wiki に書き始めた。勢いで2つの項目を書いた。書き始めにすごく時間を要するけど、書き出すとわりと推敲もしながら進む。

• 開発プロジェクトに参加して気付いた3つの大きな課題
• 初めてスクラム開発をやってみた所感

あと課題管理システムのことや情報共有の考え方やレベル、PR のルールやレビューと開発の生産性について書く。三分の一ぐらい書いたところかな。少しずつ空き時間をみつけて書いていく。

0時に寝て6時に起きた。起きたときは普通だったけど、午前中に働き始めてからまた頭痛がしてきた。内覧後は帰ってベッドで仮眠してた。夕方に頭痛のピークがきたものの、21時ぐらいにはおさまって元気になったのでそれからまたオフィスに戻って作業してた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。開発のお手伝いを始めて3ヶ月経つので私の気付き事項のレポートを書こうかと考えている。組織や開発の改善やよくないところは、外部から入ってきたときに一番気付く。だんだんとその組織や文化に慣れていって違和感を感じたかどうかがわからなくなっていく。そのため、11月から働いていて気付いたことをずっとメモし続けてそれが3ヶ月分たまったのでそのメモを総括してレポートにまとめようという話し。そのふりかえりみたいな話しをさらに部外者のはらさんとあーだこーだと話してた。雑談レベルなのでそういう話しをすることで書くときの思考整理の前準備にもなる。

• 課題管理システムやチケット駆動開発の実践についての話し
• 聞かなくてもわかる というコミュニケーションコストの話し
• コードの品質と業務形態の話し
• PR のルールやレビューと開発の生産性の話し

オフィス内覧

オフィス引っ越し調査のために 神戸国際会館のレンタルオフィスの内覧 に申し込みしていたので行ってきた。必須条件は窓があって外がみえること。いま借りているレンタルオフィスもリフォームした後から入っているので新築みたいなもので施設や設備に関しては不満はない。参考までにいま借りているレンタルオフィスの料金はこんな感じ。

• 月額利用料: 35,000
• 共益費: 5,000

神戸国際会館というグレードの高いビルにあるレンタルオフィスは普通に文句の付け所がなくて素晴らしい。1人部屋は窓がないけど、いま借りているところより少しだけ広い。一方で料金は3倍ぐらいになる。

• 月額利用料: 110,000
• 共益費: 5,000

窓がないと引っ越す意味がないので窓がある部屋は2人部屋になって広さも余裕ができるものの料金も高い。ブラインドを上げたらガラス張りで22階だから見晴らしもよくて気持ちよさそう。

• 月額利用料: 195,000
• 共益費: 5,000

いまの財務とお仕事なら払えないような料金ではないけれど、こんな家賃を払っていると、お仕事辞めてしばらく遊ぶみたいな余裕がなくなってサラリーマンと変わらない生活に戻ってしまいそうで不安になる。今期は3ヶ月ほど働かずに遊んでいたけど、そうやってられたのは家賃の固定費が安かったというのもあったんだなとこの料金を聞いて考えたりしていた。幸いにも神戸三ノ宮はレンタルオフィスがいくつもあるのでまだまだ候補はある。おそらく一番グレードが高いのが神戸国際会館なのでこれから行くところは妥当な料金になってくるとは思う。

23時に寝て3時過ぎに起きて作業しようと思ったものの、やっぱりそのまま寝てしまって7時に起きた。前々日にあまり寝てなかったせいか、睡眠不足を解消したとポジティブに考えとく。

習慣化のための平均66日

前に GIG MINDSET ギグ・マインドセット を読んだときにロンドン大学が行った研究で習慣になるには平均して66日かかるというのをみかけた。「平均して」というのが曖昧なところで、直観的に理解できるけど、対象の難易度によって習慣化に要する日数が異なる。簡単なことはすぐ習慣化できるし、難しいことには時間がかかる。それらをいくつも試してみて平均したら66日だったという話し。66日仮説 でも言及されているようにこの手の研究はあまり鵜呑みにするのもよくない。とはいえ、何らかの基準や目安があること自体は悪いことではないので一般論として参考にするのはよいと私は考えている。日記を書くというのは比較的簡単なことだと私は捉えるが、66日続いたので習慣と化したとみなしていいだろう。

書くこと

日記に関連して「書くこと」そのものを研究対象としている。自分でも日記を書き続けて何が起こるのかを理解するために実践しているという意図もある。

日記だけではなく、私は業務の過程で普通の開発者より、平均的な文章量よりも大量に書く。課題管理システムに私以上にコメントを書く開発者を、この10年で1人もみたことがない。私以上に課題管理システムを使いこなす開発者もこの10年みたことがない。課題管理システムの使い方や応用をメンバーにアドバイスするし、メンバーも私の使い方をみて真似してくれることもあった。これまでそういった行動は無意識にやっていたことだけど、それを意識化して形式知として体系化したいという狙いもある。

書くことは メタ認知を活用して学びのスキルを磨く 手法の1つとして優れていると私は考えている。これを開発者にとって日常的な課題管理 (システム) に取り入れられないかというのが、私の持論であり今後の研究課題である。たまたま、はらさんとそういった話題で話す機会があり、共感してもらえて嬉しかった。

@t2y 先ほどはありがとうございました！色々と参考になることがあり、また久しぶりにお話しできて楽しかったです！また、お願いします。
下記の「書くこと」とか、すごい良いと思い、ライトに始めてめて見ようと思います！https://t.co/WnnQ1JeSG4

— Hiroshi Hara (@hir_hara) November 30, 2021

0時に寝て6時半に起きた。

ストレッチ

先週に引き続き、今週もお仕事でバテてストレッチは2日/週とあまりできなかった。ウォーキングもほとんどできなかった。とはいえ、先週の土日に観光案内でいつもよりかなり歩いたのでその休息と考えればそれほど悲観的にならなくてもよいかもしれない。ウォーキングしなかった背景は寒くなってきて21時頃に帰ってきて、また外に出掛けるのが億劫になってしまった。お仕事を早めに切り上げて早めに帰って来た方がよいかもしれない。

今日の開脚幅は開始前168cmで、ストレッチ後170.5cmだった。また170cmを超えるようになったのでよいサイクルに入ってきた。2週間に渡った中殿筋の張りはおさまった気がする。代わりに腰の筋肉に張りがあって、トレーナーさんも念入りにそこをストレッチしてくれた。生活していると、そのときどきで調子の悪い箇所は移動していて、ストレッチするとそのことに気付くので体調管理を意識する意図でもストレッチは役に立っている。

もくもく会

【三宮.dev】もくもく会 に参加した。今回はオフラインのもくもく会だった。私は bizpy の勉強会の資料作成の準備をしていた。ここ数回は主催者と私の2人だけしかオフラインに来ないといったことが多かったのだけど、今回は8人も参加していて、その8人中5人が勉強会コミュニティに主催者だったりしてちょっとおもしろかった。

コミュニティの主催者は、コミュニティ運営の苦労がわかるから他のコミュニティのよき参加者になり得る。私は 三宮.dev の運営には関わっていないが、コミュニティを盛り上げることに寄与する振る舞いはしていて、それは自分のコミュニティでもこういったやり取りが増えるといいなという願望を他のコミュニティで参加者としてやっていたりする。今回のオフラインの参加者が多かったのも、他の勉強会コミュニティでもオフラインでやりたいよねと思う人たちが集ったのではないかとか考えたりしていた。

ぷち飲み会

終わってからわたなべさんと立ち飲みに行ってきた。最近あまり行ってない はんなりPythonの会 の勉強会で (オンラインで) なんどか話したことがある方で、ずっと京都に住んでいると思っていた方がめっちゃご近所さんだった。わたなべさんは私より1つ学年が上で、世代における価値観に共感するところは多く、自身もマイクロ法人を営んでいた。研究者としてキャリアを積み重ねてこられて昨年、独立したようだ。はんなりPythonの会の運営にも最近入ったそうで、ついでというわけではないが、話していて気が合うなと思ったので bizpy の運営に入ってくれません？と尋ねたら快く了承してくれた。

bizpy の最大の懸念は運営が私1人で、私がお仕事で忙しくなったら休業してしまうという問題があった。なかなか勉強会のコミュニティの運営をできそうなメンバー (スキル、価値観、時間的余裕) をみつけるのは難しいので了承してくれてとても嬉しかった。わたなべさんは博士で研究者のキャリアをもっていて、いまは機械学習などに取り組んでいるのかな？私のキャリアとは全く重なりがないのでお互いに学ぶところがあってよい関係を築けるのではないかと思う。ビジネスパーソン向け機械学習入門みたいな勉強会をしてもよいと思う。

リーンキャンバスレビュー (後半)

前回 の続き。残りの半分を進めるのかなと考えていたけど、前回のおさらいから始めて、私の意図するプロダクトの価値やサービスの特徴の話しをしていたら、このサービスはすぐに顧客に価値が伝わるものでもなければ、急成長するようなビジネスでもないということが伝わって、リーンキャンバスをやる意味はあまりないねという話しで後半戦をやらずに終わったw。どうも新規事業=急成長やスケールするビジネスという考えでリーンキャンバスを持ち出したところがあって、私は最初からそんなことは一言も言ってないし、私が作った資料にもそういった懸念や展望は書いてあったんだけど、リーンキャンバスを通して話しているうちにその意図を理解してもらえたといった様子だった。

そういう意味でリーンキャンバスは急成長やスケールするビジネスを取り扱うときに投資家や顧客にわかりやすく訴求するためのフレームワークと言えるのかもしれない。仮にビジネスがうまくいったとしても、合同会社は投資を受けるのが難しいのでそのときは株式会社を別途作ってやるのかなぁみたいな、取らぬ狸の皮算用みたいな話も知った。

22時ぐらいには寝て6時半に起きた。昨日はお出かけしてきてバテたんで19時頃からうたた寝を繰り返してずっと寝てた。実家に帰っていた期間を除いて、土日のどちらかを休むのはここ3ヶ月はなかったと思うし、土日の2日間ほとんど仕事をしなかったのは半年ぐらいはなかったと思う。久しぶりに土日に仕事しなかったなという印象で、その理由は業務委託のお仕事の契約が決まって余裕があるからだと思う。

kustomize の Inline Patch

Inline Patch に次の3つのやり方が説明されている。

• patchesStrategicMerge: Strategic Merge Patch として解析されるパッチファイルのリスト
• patchesJSON6902: 1つのターゲットリソースのみに適用可能な JSON Patch として解析されるパッチと関連付けされるターゲットのリスト
• patches: 関連付けされるターゲットとパッチのリスト。このパッチは複数のオブジェクトに適用でき、パッチが Strategic Merge Patch なのか JSON Patch かは自動的に検出

patches は patchesStrategicMerge と patchesJSON6902 の両方を記述できる。運用上は patchesStrategicMerge か patchesJSON6902 を適用したいパッチの内容によって使い分けることになる。おそらく前者は base にない要素を追加したり、base の要素をすべて置き換えたりするときに使う。後者は base にある map や list の一部の要素のみを限定して置き換えたり、削除したりするときに使う。ちなみに patchesJSON6902 の 6902 というのは RFC 6902 JavaScript Object Notation (JSON) Patch に由来する。

patchesJson6902 の例として次のような設定にパッチを適用する。base から読まれた metadata の要素から namespace のみを削除したり、spec.metadata の1番目のリストの secretKeyRef が参照する Secret を my-secret で置き換えたりできる。こういったパッチを patchesStrategicMerge で実現することはできないのではないかと思う (詳しくないので私が間違っているかもしれない) 。

base.yml

apiVersion: apps/v1
kind: Component
metadata:
  name: my-component
  namespace: default
spec:
  metadata:
  - name: username
    value: user
  - name: password
    secretKeyRef:
      name: base-secret
      key: password

kustomization.yml

...
patchesJson6902:
  - path: my-patch.yaml
    target:
      group: apps
      version: v1
      kind: Component
      name: my-component
...

my-patch.yaml

- op: remove
  path: /metadata/namespace
- op: replace
  path: /spec/metadata/1/secretKeyRef/name
  value: my-secret

リーンキャンバスレビュー (前半)

前に作ったリーンキャンバス を使って友だちにプロダクトの設計をレビューしてもらった。私がリーンキャンバスを作ったことがなかったので、この項目にはどういった内容を書くか、それぞれの項目がどういった関連付けや粒度で整理するかといった、リーンキャンバスの書き方そのものも含めて教えてもらった。

私が設計のために作った40枚のスライドを話すと2時間必要とするが、リーンキャンバスを使えば要点のみ15分で話せるようになるのが狙いになるみたい。とはいえ、リーンキャンバスの書いてある内容の半分を確認するだけで今日は2時間弱かかってしまった。議事録を取りながらだったので話すだけならもっと短くなったかもしれないし、その背景や根拠を細かくツッコミしていくとそれなりの時間はかかるのかもしれない。リーンキャンバス上は数枚の付箋で簡潔に書いてあるが、これどういうこと？みたいな問いになると詳細を説明しないといけないので時間がかかったように思う。リーンキャンバスの精度や品質が上がれば、読み手が詳細を確認しなくても意図を理解しやすくて詳細のツッコミが不要になるのかもしれない。これまで使ったことがないツールでおもしろいので週末に後半を行う。課題管理の背景には実践知、認知心理学、情報共有、組織論といった様々な分野にまたがるのでそのコンテキストを共有するのはなかなか難しいのではないかという思いもある。

2時に寝て8時に起きた。起きてからドラクエタクトのダイの大冒険コラボイベントをお昼前までやってた。午前中遊んでた割には今日はいろいろ作業した。ゆっくり寝たせいか、個々の作業は集中してできた。

リーンキャンバス

友だちにプロダクトの設計についてレビューしてもらう機会を調整してたらリーンキャンバス作るとよいとアドバイスをもらった。全然やったことがないので試しに自分でもやってみることにした。リーンキャンバス（Lean Canvas）を活用した企画書の書き方【テンプレート付】 を読みながら Canvanizer というツールで作成してみた。リーンキャンバスの利点の1つとしてA4サイズ1枚程度におさめるので短時間で作成できるというのがある。プロダクトの要件定義と設計はすでにできているので、リーンキャンバスは1時間も経たないうちにたたき台を作成できた。また友だちにレビューしてもらうときにフィードバックをもらいながら精度をあげていく。

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

昨日から 9.4 分散トランザクションと合意の後半の3つの節を読んだ。第Ⅱ部、400ページを超えたので2/3ほど読み終えた。

• 9.4.3 耐障害性を持つ合意
• 9.4.4 メンバーシップと協調サービス
• まとめ

合意の問題は、次のように形式化される。1つ以上のノードが値を 提案（propose） し、合意アルゴリズムはそれらの値の中から1つを 決定（deside） する。この形式化においては、合意アルゴリズムは次の性質を満たさなければならない。

• 一様同意（uniform agreement） : 2 つのノードが異なる決定をしていないこと
• 整合性（integrity） : 2 回決定をしているノードがないこと
• 妥当性（validity） : ノードが値 v を決定したら、 v を提案しているノードがあること
• 終了性（termination） : クラッシュしていないすべてのノードは、最終的に何らかの値を決定すること

耐障害性を持つ合意アルゴリズムで最も広く知られているのは、Viewstamped Replication（ VSR ）、Paxos、Raft、Zab であり、こういった合意のアルゴリズムは全順序ブロードキャストを実装しており、複数回にわたって合意が行われる。全順序ブロードキャストによって耐障害性を保ちながら線形化可能でアトミックな操作を実装できる。ZooKeeper のようなツールが、アプリケーションから利用できる合意、障害検出、メンバーシップの「アウトソーシング」サービスを提供する上で、重要な役割を果たしている。分散システムにおける様々な問題に耐えうるようなアルゴリズムを独自に開発するよりははるかによいといえる。合意へと落とし込めるような問題の処理が必要で、さらに耐障害性が求められるなら ZooKeeper のようなサービスを使うとよい。

神戸駆動開発イベント

大阪駆動開発 という xr (vr/ar/mr) のコミュニティがあって、いろんな地域に拡張しているようで、その支部？の1つに神戸駆動開発ができて、そのイベントとして 【神戸】XR体験&交流会 に参加してきた。会場が 神戸電子専門学校 だったのでどんなところかを見に行く意図でも出かけてきた。三宮.dev の主催者も神戸電子専門学校の中の人とつながりがあるらしく、今度オフラインの勉強会をそこでしようか検討しているといった話しもあった。bizpy もコロナが落ち着いたらオフラインの勉強会をやってもいいかなとは考えているので接点を作っておいてもいいかもしれない。神戸なんて狭い地域なのでコミュニティ関係者はすぐにつながるけど、神戸でオフラインの勉強会を開くに当たって適当な場所がないというのはあちこちで聞く話しでもあるので、神戸電子専門学校がそういったコミュニティをつなぐハブ的な場になるならそれはそれでいいのかもしれない。

HoloLens 2 と Nreal Light と iphone や apple watch とレンズやミラーを組み合わせて作った手作りのデバイスなども体験させてもらった。HoloLens が思ったよりも映像がみえにくくて、ロボットを操作してロケットを発射させるコンテンツをやってみたんだけど、操作よりもコンテンツが明確にみえなくて難しかった。もしかしたら装着の仕方が悪かったのかもしれない。それに比べて Nreal Light はアイドルのライブみたいなコンテンツをみたんだけど、映像も音声もはっきりしていたので印象はよかった。

適当にスタッフの人と話していて、センサーを使って現実のモノや事象を vr 空間に持ち込むと vr コンテンツを作るのは簡単かも？という話しをした。なんかセンサーを探してもいいかもしれない。そのスタッフの人はピアノを弾くのでピアノ音を取り込んで加工したりしていると話していた。

傾斜枕

胃食道逆流症（英語表記Gastro Esophageal Reflux DiseaseからGERD（ガード）とも呼ばれています）は、主に胃の中の酸が食道へ逆流することにより、胸やけ（みぞおちの上の焼けるようなジリジリする感じ、しみる感じなど）や呑酸（酸っぱい液体が上がってくる感じ）などの不快な自覚症状を感じたり、食道の粘膜がただれたり（食道炎）する病気です。胸が詰まるような痛みを感じたり、のどの違和感や慢性的に咳が持続する患者さんもいます。胃酸の逆流は食後2～3時間までに起こることが多いため、食後にこれらの症状を感じたときは胃酸の逆流が起きている可能性を考える必要があります。

(…)

現在では成人の10～20％がこの病気にかかっていると推測されています。

胃食道逆流症(GERD)

ここ1-2年、睡眠がうまくとれなくなったことと関連して、寝ていて胃酸が逆流してむせるといったことも2-3ヶ月に1回ぐらいと稀ではあるけれど、起きるということに気付いた。2年ほど前、健康診断で胃カメラを受診したときに医師から胃の入り口の弁が、普通の人は逆流しないように閉じているものが私のは開いているという話があった。そのときは特に日常生活に困ってないからいいんじゃないで流してたんだけど、加齢とともに胃食道逆流症が起こっているのかもしれないと、いくつかの事象を認識して思うようになってきた。喉の違和感も気になるようになっていた。その症状の軽減に逆流しにくいように傾斜を付けて寝るとよさそうというのをみつけて、傾斜枕を買ってみた。しばらく試してみて寝心地や胃食道逆流症がどうなるかを観察してみる。

0時に寝て7時に起きた。昨日は寝不足だったせいかぐっすり眠れた。

設計ドキュメント作成

昨日の続き。着手すると徐々に興が乗ってくる。朝からずっとやり続けて17時ぐらいに一通りたたき台ができた。なぜか朝ご飯もお昼ご飯も食べずに資料を作り続けてた。お腹もあまりすかなかった。経緯や背景、設計の意図やシステム構成、展望やビジネス戦略など、スライドで39枚になった。顧問さんに情報共有するための資料なんだけど、自分一人の会社で自分一人で開発するのに2日もかけて資料作る必要あるのだろうかと考える人も多いと思う。この資料に書いた内容はすべて課題管理システム上のチケットのどこかに書いてあることなので、私の視点からは全部知っている内容ではある。ちょうど100を超えたばかりのチケット上のどこかに書いてあることを、39枚のスライドにまとめて今日の時点でのスナップショットを作るというのは思考の整理に役立っている。去年はそういうことをやらなかったので何かうまくいかなくなったのを リモートワークと相談相手 に書いた。今年はうまくいってないという感覚がないので気持ちに余裕がある。気持ちに余裕があるから新しい施策やアイディアに集中できているように考えている。

ジョギング

資料できたのが嬉しくて気分がよかったのでそのまま帰ってジョギングしてきた。今週初めて。19時までに帰ってくると行く気するんだけど、それよりも遅く帰ってくるとお腹空いて晩ご飯を先に食べてしまい、晩ご飯を食べると走りに行く気力がなくなってしまう。前に軽く調べたら健康的には食べる前に走った方がよいみたい。先週とだいたい同じ時間帯に行った んやけど、陸上部の人たちが減ってて走りやすかった。曜日じゃなくて何か別のサイクルがあるのかな。ちょっと寒いぐらいだから走っててもあまり汗も書かないし、走った後にストレッチするのも汗だくにはならない。

Slack Community

Slack Community というのがあるのをみかけたので参加してみた。これからしばらく Slack apps についてがっつり調べていく予定。困ったときに相談できるように。