移住先のFediverseインスタンスを選ぶのがむずかしい。
インスタンスの規約、文化、接続などのANDをとらないといけない。
規約は自身の利用方法が禁止されていない必要がある。
文化は自身がLTLの流れの妨げにならない必要がある。
接続はフォロワーがいるインスタンスから接続できる必要がある。
LTLがないインスタンスは文化面を気にしなくて良いので、比較的、移住がしやすい。
移住を試みてフォロワーとの関係を維持するには、フォローのインポートをしてフォローバックされる必要があるので、あまり試行回数増やすわけにもいかない。
この辺の難しさが自鯖を立てるモチベーションの一つなのかもしれない。
将来に対する不安を減らしたい。マインドフルネスとかで。
未来予測できなさすぎなので将来に対する不安は対処が難しく感じられる。考え方とか生理的な方向で不安に対処していきたい。
あと、目の前の問題をチビチビ減らしていきたい。
まだ大量に残ってる引っ越しの段ボールとか。
「文章がうまくカプセル化できているならば、グラフ化した文章を一つのノードとして扱える」
「グラフ化した文章を一つのノードとして扱えるならば、文章がうまくカプセル化できている」
これでは循環してしまっており、定義としてうまくいっていない。
「文章の多くを隠蔽できるならば、文章がうまくカプセル化できている」
こちらのほうがまだ良いか。
検討中・未検証
Misskey.ioが落ちているのでFedibirdへ避難した。
以前からMisskey.ioからエクスポートしてあったフォローリストをFedibirdへインポートした。
抽象から具体の順に説明するという方法は良さそうだとは思うものの、あまりに抽象的なことから説明されても困るだろう。相手に近いところから導入するほうが、話を聞いてもらいやすいはずだ。
例えば、道端で知らない人から話しかけられるとして、「国家はどうあるべきとおもうかね？」と話しかけられれば逃げたくなるだろうし、「最近ガソリン高くてツライっすよね……」と話しかけられれば「ちょっとは話を聞いてみようか」という気になるだろう（少なくとも前のものよりも）。
<文章のまとめ方>をうまく構築することができれば、一つ私にとって意義のあるものにできるように思える。
私の「文章がうまく書けない」という問題の解決になる。これに苦しめられてきた分、解放感もひとしおだろう。
同じような悩みを持つ人の助けにもなる。
文章を書く上で、情報量の最大化 と 理解の最大化 は関係はしてそうだけど、違うものだな。
いやでも、シャノンの情報量って、コミュニケーションで伝えられる量じゃなかったっけ。
Claudeに聞いてみると、理解の最大化に関係してGriceの協調原理というのがあるらしい。
前職の職場の近くにはOKストアがあり、そこでは300円でカツ丼弁当が販売されていた。
良い給料をもらっているはずの人々が、このカツ丼弁当で昼食代を浮かせていた。
また近くにはなまるうどんがあり、かけうどんには自分で出汁をかける形式になっている。
唸るほど金を持っているはずの社長は「出汁だけ飲みたいよね」などと言っていた。
激安定食屋が発生しやすいパターン
<直感を再現する>を久々に見つけて、見て回ってみると、その効果について言語化に苦しんでいるようだった。
今回はサクッと<直感的に引き入れると、後から直感的に探せる>と言語化できた。
理解の深化や、成長が感じられる。
私生活にも関わらず毎日タスクをこなさないといけないものだから、落ち着く日がない。なんとか日々を切り抜けていっている。こんなに私生活がずっと忙しかったことはかつてなかった。
Tak.さんがPodcastで言っていた、タスク管理の目的はその日をしのぐこと、というのが思い出され、まったくその通りだと実感が湧いてくる。
毎日複数のタスクがかわるがわるやってくるものだから、タスクがモヒカンと化して躍動的に襲いかかってくるような映像が脳内に浮かび上がってくる。
タスクを躍動させているのは自分だし、タスクが自分を躍動させている。
いつも仕事が終わって帰ると疲れ果てている。
そこで、今日は作業が一区切りつくたびに、意図的にリラックスするようにしてみた。作業興奮を落ち着かせるようなイメージだ。
そうしたところ、帰ってきてからグッタリする時間が短くなり、いつもより2〜3時間早く動き出すことができた。
リラックスを取り入れてみようと思ったのは、昨日ある動画を見たためである。
効果の再現性を確かめるために、明日もやってみようと思う。
1日のタスク数を増やすと、やりたくない作業に着手しづらくなるかもしれない。
ほかのタスクを進めることで、やりたくない作業を無視・遅滞することを正当化してしまいそうだ。
YWTの「次やること」って、「わかったこと」から考える必要があるのかと思ってたけど、もしかしてそんなことは関係なく次にどの作業をやるかを決めれば良いんだろうか
Claudeに聞くと「わかったこと」から「次やること」を考えるべきらしい。
そうすることで経験学習のサイクルが回るそうな。
思想を把握するために原典を読む必要があるな。
昨日の文章の練習の試みに引き続き、文章の図解化と、図解からの文章の再構成を試みている。
前回からの変化として、元の文章と対応している度合いが高くなるようにした。
今回の気付きとしては、今回作られたグラフの見た目は、別の島と関連させる矢印はすべて上方向になっている(図)。
すなわち、ある文章からの言及・説明・関係は、それより前の文に登場した物事を指し示している。
また、基本的に文章は抽象（あるいは大きな枠組み）から具体（あるいは小さな枠組み）へと説明が進むことが望ましいため、抽象は具体は指し示さず、具体から抽象への指し示しに限定している。
したがって、グラフによって文章の流れを構成するには、抽象的な物事や矢印の方向が向いている先を上に置くようにすれば良く、グラフから文章化するには上から順に文章化すれば良い。
物事の見方が変わって抽象と具体の立体感を獲得し、それらを使っていると、頭のこれまで使っていなかった部分が使われているような、血が通っているような感覚がしている。
「全体から書く」を意識して、
あれを
デライトを使っていたおかげか、頭の使い方、考え方、物事の見方が変わってきている。おそらく良い方向に。
デライトを使うことが考える訓練になっているし、道具が物事の見方に影響を与えている。
と書いていたのを、
道具が物事の見方に影響を与えるようだ。
デライトを使うことが考える訓練になっており、頭の使い方、考え方、物事の見方が変わってきている。おそらく良い方向に。
に並び替えてみた。どうだろうか？
相変わらず文章が書けない問題に取り組んでおり、文章を再現する練習をしてみている。
今回は、文章を頭の中で別の表現に変換してみる、ということをやってみている。
具体的には、
文章を一文（「。」まで）読む → 頭の中で別の表現にして記憶する（グラフとして構築する） →元の文章を見ずに頭の中のグラフから元の文章を再現する
というやり方。
例えば「おじさんはバイトさんにしょっちゅう話しかける。」[1]であれば、下記の図のようなグラフを頭の中で構築する。
そこから「おじさんはバイトさんにしょっちゅう話しかける。」を再構築する。
頭の中にグラフを構築して、それを保持するのが意外と難しい。
昼ごはんがてら免許の住所変更に行ったら15時からの受付で、しょぼくれた日曜日の始まり。
改めて運転免許証の住所変えにきたぞ。
また行くのがめんどくさいという気持ちになったのをねじ伏せた。
おもきさんが描き出していた「文章が上手な人と下手な人の違い」を読むには、文章が書ける人は頭の中だけで筋道を組んでいるらしい。
反射的には「そんなことはとてもできない」と思うのだが、否定するには、文章の中で説明されている「文章の下手な人のやり方」というのが、あまりにも私のやり方を言い表している。
相変わらず文章がうまく書けない問題に取り組んでいる。
私は何もないところから文章を書こうとしても書けない。その対策として話の筋やロジックをネットワーク状の図解を作成し、その図解を文章化する、という方法でなんとか書こうとしている。しかし、今までこのやり方で順調にいったことがなく、やり方を改善する必要性がある。あるいはまったく違うやり方に移行するか。
そこで、図解から文章化のやり方を改善するために、他の人が書いたすでに完成している文章を図解化し、図解から文章を再構築するということをやってみていた。
図解からの文章の再構築にやはり困難があり、今使っている図解の形態から文章が作り出せるような感じがしない。
図解からの文章化にあたって何が困るかというと、ネットワーク上の図解のどの点を始点として、文章を始めればいいのかわからないのだ。
一旦この問題を無視して、元となる文章の始点から始めてみても、どのような道筋で進めればいいのかわからない。一筆書きのパズルのような難しさがある。
元となる文章を変えながら、何度かこの作業を繰り返しながら模索すれば、なにか解決策が見つかるだろうか。
というか、論理のグラフを作ったとて、文章化するにあたってどこから手をつけたらいいかわからなくなる。
「結論から書く」という方策を取るにしても、結論を見ると満足してしまって手が動かなくなる。満足しているというよりも怠惰をしている可能性もある。
始点を置くとするならば読者の視点だろう。そこから結論までの道筋を文章にできればよい。のかもしれない。
『大学とは何か』を読んでいて思うに、大学は、功利主義の枠組みの中で評価されて活動するのではなく、その枠組み自体について研究する、たとえば功利主義に変わる何かを探し出すことこそが目的かもしれない。
まさに「枠組みを壊せることがエリートの本質」というわけだ。
しかし、ここ最近の日本では、大学が功利主義の枠組みで評価されるようになっていっており、枠組みを壊すような取り組みはうまくいっていないのかもしれない。
メ _|＼ _ ヾ､ メ ／ u ｡ ｀ｰ､＿__ ヽ / // ﾟ ｡ ⌒ ｡ ﾟ u ／ つ / //u ﾟ （●） u ﾟ｀ヽ｡i l わ l | | ｡ ﾟ,ｒ -(､_, )（●） / ! ぁぁ ヾ ! //「ｴｪｪ､ ） ﾟ u/ ﾉ あぁ // ｒヽ iｒ- ｒ ､//｡ﾟ／ く ああ ノ ﾒ/ ヽ｀ﾆ' ｨ―' ヽヽヾ ぁあ ＿/((┃))＿＿＿＿_i |＿ ｶﾞﾘｶﾞﾘｶﾞﾘｶﾞﾘｯ ／ /ヽ,,⌒)￣￣￣￣ （,,ノ ＼ ／ /＿＿＿＿＿＿＿＿＿ヽ ＼ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣
輪郭の前景と後景を作ることで、抽象度のレベルが調整されていく。
<デライトで長文を書く> よりも <デライトで文章を書く> の方が、書こうとしている文章にとって適切であることが発見されたりする。
{{あれ K#/A52F-E2CF}}と書くと{あれ}と表示されるので、"輪郭"として説明したいときには便利かもしれない。
ただ、正規の記法ではなく、かなり微妙なバランスで成り立っているように見える。前側のブラケットはリンクになっているが、後ろ側のブラケットはリンクになってない。
また、強調しようとして＊＊{{あれ K#/A52F-E2CF}}＊＊や{＊＊{{あれ K#/A52F-E2CF}＊＊}のように書くと強調が失われたり、その後の輪郭とくっついておかしなことになる。
{{あれ K#/A52F-E2CF}}
{あれ}
{{あれ K#/A52F-E2CF}}{あれ K#/A52F-E2CF}
{あれ}あれ
{{あれ} K#/A52F-E2CF}
あれ
＊＊{{あれ K#/A52F-E2CF}}＊＊
{あれ}
{＊＊{あれ K#/A52F-E2CF}＊＊}{あれ K#/A52F-E2CF}
あれ}{あれ
javascript: fetch("https://dlt.kitetu.com/KNo.EDD2/A52F-4881?dln&fmt=src").then(r=>r.text()).then(text=>window.open(`https://dlt.kitetu.com/?kw=${encodeURIComponent(new Date().toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join(""))}&dln={${new Date().getFullYear()+"年" + (new Date().getMonth()+1)+"月"}}> ${encodeURIComponent("\n")}<-{${new Date(Date.now()-24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}} ${encodeURIComponent("\n")}{${new Date(Date.now()+24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}}->${encodeURIComponent("\n\n"+text)}`))
javascript: (async ()=>{window.open(`https://dlt.kitetu.com/?kw=${encodeURIComponent(new Date().toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join(""))}&dln={${new Date().getFullYear()+"年" + (new Date().getMonth()+1)+"月"}}> ${encodeURIComponent("\n")}<-{${new Date(Date.now()-24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}} ${encodeURIComponent("\n")}{${new Date(Date.now()+24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}}->${encodeURIComponent("\n\n"+await fetch("https://dlt.kitetu.com/KNo.EDD2/A52F-4881?dln&fmt=src").then(r=>r.text()))}`)})()
javascript:(()=>{window.open(`https://dlt.kitetu.com/?kw=${encodeURIComponent(new Date().toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join(""))}&dln={${new Date().getFullYear()+"年" + (new Date().getMonth()+1)+"月"}}> ${encodeURIComponent("\n")}<-{${new Date(Date.now()-24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}} ${encodeURIComponent("\n")}{${new Date(Date.now()+24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}}->${encodeURIComponent("\n+{ルーチン K#/A52F-4881}")}`)})()
Fediverseの人々の中にはXも見ている人が多くおり、Xで面白いと思った投稿を何らかの形でFediverseへ持ち込むことがある。
持ち込む形態としては、
などがある。
働き始めてから振り返りが捗らない。働いていると書けないことが多く、私生活では特にやってることがないので書くことがない。
ごはんの話をしよう。
無収入期間での貯蓄の目減りや、就職先が前職と比べて収入が激減しているなどにより、節約が必要な状況にある。
節約となると目の敵となるのは食費で、特に職場に出ているときの昼食は出先で食べる必要があることから高くつきやすく、可能な限り安くあげたい。
これに対し、朝食と夕食の量を増やし、昼ごはんを減らして節約という手段に出ている。具体的には、朝食にパンを2つ食べて500〜600kcalほど確保し、昼食にはベースブレッドで200〜300kcalを摂り、夕食は適当に自炊したりスーパーで買った惣菜を食べて800kcalほど摂り、夜食で帳尻を合わせて総計で1800〜2200kcalほどを摂っている。
今日のところはうまくいっており、昼のベースブレッドだけで夕飯まで耐えることができた。お腹がすいた時に食べられるようにソイジョイを買っておいたが、食べずに済んだ。
この方策でしばらくは継続していきたいが、懸念されるのはベースブレッドが飽きた場合にどうするかである。毎日これをやれば1週間もせずにベースブレッドに飽きるだろうし、週1日だけベースブレッドで済ませ、ほかの日は別の手段をとったほうがいいかもしれない。例えば、安いファーストフード店に行き、安いメニューで済ませるなどの方策が考えられる。飲食店のキャンペーンなどによって、安く済ませられるチャンスがあれば、これを積極的に取り入れていくべきだろう。節約は飽きとの戦いなので、いろいろ工夫して飽きを遅延させていきたい。
栄養バランスを見るとカルシウムが不足している。牛乳などを取り入れておこう。
ネットワークの調子が悪く、ほかのサイトは開くことができないものが多い状況だが、デライトは少し待つと表示できる。
開発者コンソールのネットワークタブを見ると、デライトの1ページの転送量は30kB前後だった。参考のためにGoogleの検索ページを見ると1.5MBだった。
デライトを使って、分からない単語が大量に出てくる分野について勉強する際には、それらの単語を知名、説明を本文に書いた輪郭を描き出すことで、勉強が有利に進められると思われる
【理想】
作業する→次の作業する→次の作業する→……
【目論見】
作業する→SNSを少し見る→次の作業する→SNSを少し見る→次の作業する→……
【現実】
作業する→SNSを見る→SNSを見る→SNSを見る→……
OpenReviewは、主に人工知能、機械学習、コンピュータサイエンスの分野でよく使われている査読プラットフォームです。NeurIPSやCVPR、ICLR、ICML、ACL、AAAIなど多数のトップカンファレンスが使用しています。
朝から読書、論文、ラジオ体操、改善、ゲーム、プログラミングに着手した。
プログラミングは1時間ほどできた。ここまでしっかりプログラミングしたのは久しぶりだった。
就職に伴い、健康診断結果を提出する必要があるため、健康診断に行ってきた。
平日は作業があるため、あらかじめ土曜日に受けられるところを予約しておいた。
予約のあと特段連絡もなかったため本当に受けられるか心配だったが、無事に受けられ、健康診断結果も受け取ることができた。
これで安心だ。
健康診断後に夕飯を食べてたら眠くなり、仮眠のつもりで横になったら翌日の朝まで10時間も寝ていた。
この日は健康診断でカフェインも摂っていなかったし、それで寝てしまったのだろう。
というかカフェインで日頃寝不足状態だったのかもしれない。
仕事終わりに飲みに行った
デイリールーチンが実行できなかった。
夜にデイリールーチンを回すと実行できない場合が発生しやすい
朝できるように寄せていく
メッセージキューとかメッセージブローカーの使い方って、イベントの発生時にメッセージでIDなどと共に通知だけして、データ本体などは別途DBなどに格納しておき、それをイベント受信側が取得しにいくって理解でいいのかしら。
メッセージにデータ本体が載るならそのままデータも載せて、載りきらないならDBにAPIを介して取りに行くとかのほうが楽ではありそう。
ある動画でお〜いお茶がかわいく見えてくるし、ぬいぐるみに限らず、人が触っているものはかわいく見えるということでは？
とおもったのだけど、動画を改めて見直すと人がペットボトルを持っている部分は見切れて写っていなかった。
キーボード持っていかねば。
打鍵が強めなのでノートPCのキーボード壊れる。
いや、こう、早く打とうとして、底打ちの反発を使ってタイピングしてたら、だんだん打鍵が強くなってきてしまった。
一般に荒らしというのは、目立つ箇所に投稿などをして迷惑度の最大化を目論むと思うのだけど、デライトのコンテンツは閲覧が集中する点がないので、荒らすにしてもどこを荒らせばいいのか分からず荒らしづらい・荒らしがいがない気がする
AppleはUIを操作に合わせて物理っぽく動かすのが上手い。
慣性で動くように感じられるのに加えて、Liquid GlassではUIパーツがぽよぽよと動くことで柔らかさを呈しており、変態の所業。
おっ
ストレッチで腰が楽に
腰のストレッチ、今までやってたのは伸ばすべき方と逆だったんだわ
座ってる時に縮んでる筋肉を伸ばさなあかんかったんだわ
つまるところ股関節とか腹筋の下部とかを伸ばしたら良くなった気がする
いまのところは
描出した日付で輪郭をまとめたり、花火日報を書くと、妙に面白い輪郭が発見されるのも、時間的局所性によって同一の枠組み/包括/抽象の中での描出となる可能性が高いからだろう。それらの輪郭は意味的なまとまりを持ち、そこから意味のある枠組み/包括/抽象を見つけ出すことができる（ことが多い）。
（あれ・あれ）→共通点でつなげ、包括でまとめる→つなげながらまとめる（つなげながらまとめる）
ついに来たな！！
「つなげる」は「本文内のリンク」と「共通点で引き入れる」、「まとめる」は「包括で引き入れる」と捉えるとすっきりする。
いままでは「つなげる」を「本文内のリンク」、「まとめる」を「引き入れ」と捉えていたが、それよりもずっとしっくりくる。
もっと別の捉え方もあるかもしれないが、それでも今時点ではかなり理解が前進した。
これまでデライトの中で長文を書くに至らなかったのは、前景として輪郭を作る際に、長文を書くに資する抽象/範疇を作り出してこなかったためのように思う。
前景として作る輪郭の多くは「飲食店」のような単一のキーワードを知名にしていた。そうした輪郭の後景に輪郭がたまってきても、それらは共通点を持つだけで関係は弱く、文章としてなかなかまとまってはくれない。
KJ法で言うならば、文章としてまとまるには、「土の香り」がする抽象/範疇を作る必要がある。
Wikiのようなキーワードリンクでは、「キーワード」によるリンクのため、共通部分による紐づけはできるが、包括を表すことは難しいように思われる。
例えば、「コンビニ」のページについて考えると、その説明の中で「小売店」をキーワードリンクに設定することはできるが、その関係性はあくまで文中の説明によって示される。
資料作成からは完全に脱線し、抽象と具体の立体感の獲得についてまとめるのに熱中していた。しかし得られたものが資料作成に役立つことは間違いないし、資料作成よりも重要だったと思う。また、資料作成にはまだ時間がある。
私と似たような特性を持つ人が抽象と具体の立体感を獲得するのに役立つような何かを作っておく
抽象と具体の感覚、特に抽象から具体を見るイメージを得るのにデライトを使い始めてから5年もかかった。デライトが無ければ一生つかめなかったかもしれない。
これまで具体を見る、あるいは具体から抽象を見るしかできなかったが、後景として描出した具体から、前景として描出した抽象を積み上げてきた結果、抽象から具体を見るイメージができるようになった（気がする）。
デライトだけではなく、KJ法やソフトウェア設計などをやっていたことも効いたように思う。
また、『過程と実在』にて解説されていた哲学の方法である「真の発見の方法は、観察の大地から普遍化の大気圏へと出発し、再び元の大地に着地する」は、まさに具体から抽象を見ることと抽象から具体を見ることについて説明されていた。
「コンビニからローソンを見る」は抽象から具体を見るの一例（具体）だし、「抽象から具体を見る」から「コンビニからローソンを見る」を見ると、これもまた抽象から具体を見るになる
今まで、抽象を見たり作ったりすることはできたが、抽象へ視点を移動させ、具体の側に振り返り、そこから具体を見る、ということができなかった/そういったことを認識していなかった。
Kubernetes分からん人間からすると、Kubernetesについて調べたときに「minikube」や「kubeadm」といった固有名詞が大量に出てくるのがつらい。
YugabyteDBの勉強を再びやろうとしているのだけど、先にKubernetesの勉強が必要なように思われる。
YugabyteDBを運用するならKubernetesを使う方向になる（ほかの運用方法もあるだろうが、それらと比較検討するためにも結局Kubernetesの知識が必要になる）。
{Kubernetes K#/E97E} > {kubeadm K#/A52F-718F} >
となっていたのを
{Kubernetes K#/E97E} > {Kubernetesクラスター構築ツール K#/A52F-3B90} > {kubeadm K#/A52F-718F} >
とした。
Kubernetes直下に引き入れず、一段下位の輪郭に引き入れることによって、Kubernetesから見えない状態にしてある。
これによって、Kubernetesを開いている時には抽象（Kubernetesクラスター構築ツール）だけが目に入り、具象（kubeadm）は目に入らないようになる。
こうした操作は「知識のカプセル化」と呼べるかもしれない。
移住先のFediverseインスタンスを選ぶのがむずかしい。
インスタンスの規約、文化、接続などのANDをとらないといけない。
規約は自身の利用方法が禁止されていない必要がある。
文化は自身がLTLの流れの妨げにならない必要がある。
接続はフォロワーがいるインスタンスから接続できる必要がある。
LTLがないインスタンスは文化面を気にしなくて良いので、比較的、移住がしやすい。
移住を試みてフォロワーとの関係を維持するには、フォローのインポートをしてフォローバックされる必要があるので、あまり試行回数増やすわけにもいかない。
この辺の難しさが自鯖を立てるモチベーションの一つなのかもしれない。
「文章がうまくカプセル化できているならば、グラフ化した文章を一つのノードとして扱える」
「グラフ化した文章を一つのノードとして扱えるならば、文章がうまくカプセル化できている」
これでは循環してしまっており、定義としてうまくいっていない。
「文章の多くを隠蔽できるならば、文章がうまくカプセル化できている」
こちらのほうがまだ良いか。
文章がうまくカプセル化できているならば、グラフ化した文章を一つのノードとして扱えるし、それ同士の関係を結ぶことで合成・結合ができるはずである。
検討中・未検証
抽象から具体の順に説明するという方法は良さそうだとは思うものの、あまりに抽象的なことから説明されても困るだろう。相手に近いところから導入するほうが、話を聞いてもらいやすいはずだ。
例えば、道端で知らない人から話しかけられるとして、「国家はどうあるべきとおもうかね？」と話しかけられれば逃げたくなるだろうし、「最近ガソリン高くてツライっすよね……」と話しかけられれば「ちょっとは話を聞いてみようか」という気になるだろう（少なくとも前のものよりも）。
<直感を再現する>を久々に見つけて、見て回ってみると、その効果について言語化に苦しんでいるようだった。
今回はサクッと<直感的に引き入れると、後から直感的に探せる>と言語化できた。
理解の深化や、成長が感じられる。
私生活にも関わらず毎日タスクをこなさないといけないものだから、落ち着く日がない。なんとか日々を切り抜けていっている。こんなに私生活がずっと忙しかったことはかつてなかった。
Tak.さんがPodcastで言っていた、タスク管理の目的はその日をしのぐこと、というのが思い出され、まったくその通りだと実感が湧いてくる。
毎日複数のタスクがかわるがわるやってくるものだから、タスクがモヒカンと化して躍動的に襲いかかってくるような映像が脳内に浮かび上がってくる。
タスクを躍動させているのは自分だし、タスクが自分を躍動させている。
いつも仕事が終わって帰ると疲れ果てている。
そこで、今日は作業が一区切りつくたびに、意図的にリラックスするようにしてみた。作業興奮を落ち着かせるようなイメージだ。
そうしたところ、帰ってきてからグッタリする時間が短くなり、いつもより2〜3時間早く動き出すことができた。
リラックスを取り入れてみようと思ったのは、昨日ある動画を見たためである。
効果の再現性を確かめるために、明日もやってみようと思う。
1日のタスク数を増やすと、やりたくない作業に着手しづらくなるかもしれない。
ほかのタスクを進めることで、やりたくない作業を無視・遅滞することを正当化してしまいそうだ。
昨日の文章の練習の試みに引き続き、文章の図解化と、図解からの文章の再構成を試みている。
前回からの変化として、元の文章と対応している度合いが高くなるようにした。
今回の気付きとしては、今回作られたグラフの見た目は、別の島と関連させる矢印はすべて上方向になっている(図)。
すなわち、ある文章からの言及・説明・関係は、それより前の文に登場した物事を指し示している。
また、基本的に文章は抽象（あるいは大きな枠組み）から具体（あるいは小さな枠組み）へと説明が進むことが望ましいため、抽象は具体は指し示さず、具体から抽象への指し示しに限定している。
したがって、グラフによって文章の流れを構成するには、抽象的な物事や矢印の方向が向いている先を上に置くようにすれば良く、グラフから文章化するには上から順に文章化すれば良い。
物事の見方が変わって抽象と具体の立体感を獲得し、それらを使っていると、頭のこれまで使っていなかった部分が使われているような、血が通っているような感覚がしている。
「全体から書く」を意識して、
あれを
デライトを使っていたおかげか、頭の使い方、考え方、物事の見方が変わってきている。おそらく良い方向に。
デライトを使うことが考える訓練になっているし、道具が物事の見方に影響を与えている。
と書いていたのを、
道具が物事の見方に影響を与えるようだ。
デライトを使うことが考える訓練になっており、頭の使い方、考え方、物事の見方が変わってきている。おそらく良い方向に。
に並び替えてみた。どうだろうか？
相変わらず文章が書けない問題に取り組んでおり、文章を再現する練習をしてみている。
今回は、文章を頭の中で別の表現に変換してみる、ということをやってみている。
具体的には、
文章を一文（「。」まで）読む → 頭の中で別の表現にして記憶する（グラフとして構築する） →元の文章を見ずに頭の中のグラフから元の文章を再現する
というやり方。
例えば「おじさんはバイトさんにしょっちゅう話しかける。」[1]であれば、下記の図のようなグラフを頭の中で構築する。
そこから「おじさんはバイトさんにしょっちゅう話しかける。」を再構築する。
頭の中にグラフを構築して、それを保持するのが意外と難しい。
昼ごはんがてら免許の住所変更に行ったら15時からの受付で、しょぼくれた日曜日の始まり。
改めて運転免許証の住所変えにきたぞ。
また行くのがめんどくさいという気持ちになったのをねじ伏せた。
おもきさんが描き出していた「文章が上手な人と下手な人の違い」を読むには、文章が書ける人は頭の中だけで筋道を組んでいるらしい。
反射的には「そんなことはとてもできない」と思うのだが、否定するには、文章の中で説明されている「文章の下手な人のやり方」というのが、あまりにも私のやり方を言い表している。
相変わらず文章がうまく書けない問題に取り組んでいる。
私は何もないところから文章を書こうとしても書けない。その対策として話の筋やロジックをネットワーク状の図解を作成し、その図解を文章化する、という方法でなんとか書こうとしている。しかし、今までこのやり方で順調にいったことがなく、やり方を改善する必要性がある。あるいはまったく違うやり方に移行するか。
そこで、図解から文章化のやり方を改善するために、他の人が書いたすでに完成している文章を図解化し、図解から文章を再構築するということをやってみていた。
図解からの文章の再構築にやはり困難があり、今使っている図解の形態から文章が作り出せるような感じがしない。
図解からの文章化にあたって何が困るかというと、ネットワーク上の図解のどの点を始点として、文章を始めればいいのかわからないのだ。
一旦この問題を無視して、元となる文章の始点から始めてみても、どのような道筋で進めればいいのかわからない。一筆書きのパズルのような難しさがある。
元となる文章を変えながら、何度かこの作業を繰り返しながら模索すれば、なにか解決策が見つかるだろうか。
というか、論理のグラフを作ったとて、文章化するにあたってどこから手をつけたらいいかわからなくなる。
「結論から書く」という方策を取るにしても、結論を見ると満足してしまって手が動かなくなる。満足しているというよりも怠惰をしている可能性もある。
始点を置くとするならば読者の視点だろう。そこから結論までの道筋を文章にできればよい。のかもしれない。
『大学とは何か』を読んでいて思うに、大学は、功利主義の枠組みの中で評価されて活動するのではなく、その枠組み自体について研究する、たとえば功利主義に変わる何かを探し出すことこそが目的かもしれない。
まさに「枠組みを壊せることがエリートの本質」というわけだ。
しかし、ここ最近の日本では、大学が功利主義の枠組みで評価されるようになっていっており、枠組みを壊すような取り組みはうまくいっていないのかもしれない。
メ _|＼ _ ヾ､ メ ／ u ｡ ｀ｰ､＿__ ヽ / // ﾟ ｡ ⌒ ｡ ﾟ u ／ つ / //u ﾟ （●） u ﾟ｀ヽ｡i l わ l | | ｡ ﾟ,ｒ -(､_, )（●） / ! ぁぁ ヾ ! //「ｴｪｪ､ ） ﾟ u/ ﾉ あぁ // ｒヽ iｒ- ｒ ､//｡ﾟ／ く ああ ノ ﾒ/ ヽ｀ﾆ' ｨ―' ヽヽヾ ぁあ ＿/((┃))＿＿＿＿_i |＿ ｶﾞﾘｶﾞﾘｶﾞﾘｶﾞﾘｯ ／ /ヽ,,⌒)￣￣￣￣ （,,ノ ＼ ／ /＿＿＿＿＿＿＿＿＿ヽ ＼ ￣￣￣￣￣￣￣￣￣￣￣￣￣￣
輪郭の前景と後景を作ることで、抽象度のレベルが調整されていく。
<デライトで長文を書く> よりも <デライトで文章を書く> の方が、書こうとしている文章にとって適切であることが発見されたりする。
{{あれ K#/A52F-E2CF}}と書くと{あれ}と表示されるので、"輪郭"として説明したいときには便利かもしれない。
ただ、正規の記法ではなく、かなり微妙なバランスで成り立っているように見える。前側のブラケットはリンクになっているが、後ろ側のブラケットはリンクになってない。
また、強調しようとして＊＊{{あれ K#/A52F-E2CF}}＊＊や{＊＊{{あれ K#/A52F-E2CF}＊＊}のように書くと強調が失われたり、その後の輪郭とくっついておかしなことになる。
{{あれ K#/A52F-E2CF}}
{あれ}
{{あれ K#/A52F-E2CF}}{あれ K#/A52F-E2CF}
{あれ}あれ
{{あれ} K#/A52F-E2CF}
あれ
＊＊{{あれ K#/A52F-E2CF}}＊＊
{あれ}
{＊＊{あれ K#/A52F-E2CF}＊＊}{あれ K#/A52F-E2CF}
あれ}{あれ
javascript: fetch("https://dlt.kitetu.com/KNo.EDD2/A52F-4881?dln&fmt=src").then(r=>r.text()).then(text=>window.open(`https://dlt.kitetu.com/?kw=${encodeURIComponent(new Date().toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join(""))}&dln={${new Date().getFullYear()+"年" + (new Date().getMonth()+1)+"月"}}> ${encodeURIComponent("\n")}<-{${new Date(Date.now()-24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}} ${encodeURIComponent("\n")}{${new Date(Date.now()+24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}}->${encodeURIComponent("\n\n"+text)}`))
javascript: (async ()=>{window.open(`https://dlt.kitetu.com/?kw=${encodeURIComponent(new Date().toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join(""))}&dln={${new Date().getFullYear()+"年" + (new Date().getMonth()+1)+"月"}}> ${encodeURIComponent("\n")}<-{${new Date(Date.now()-24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}} ${encodeURIComponent("\n")}{${new Date(Date.now()+24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}}->${encodeURIComponent("\n\n"+await fetch("https://dlt.kitetu.com/KNo.EDD2/A52F-4881?dln&fmt=src").then(r=>r.text()))}`)})()
javascript:(()=>{window.open(`https://dlt.kitetu.com/?kw=${encodeURIComponent(new Date().toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join(""))}&dln={${new Date().getFullYear()+"年" + (new Date().getMonth()+1)+"月"}}> ${encodeURIComponent("\n")}<-{${new Date(Date.now()-24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}} ${encodeURIComponent("\n")}{${new Date(Date.now()+24*60*60*1000).toLocaleDateString("ja-JP").split("/").map((a, i)=>a+["年", "月", "日"][i]).join("")}}->${encodeURIComponent("\n+{ルーチン K#/A52F-4881}")}`)})()
野球を観戦して発狂する韓国人VTuberの箇所が音としての気持ちよさがある
働き始めてから振り返りが捗らない。働いていると書けないことが多く、私生活では特にやってることがないので書くことがない。
ごはんの話をしよう。
無収入期間での貯蓄の目減りや、就職先が前職と比べて収入が激減しているなどにより、節約が必要な状況にある。
節約となると目の敵となるのは食費で、特に職場に出ているときの昼食は出先で食べる必要があることから高くつきやすく、可能な限り安くあげたい。
これに対し、朝食と夕食の量を増やし、昼ごはんを減らして節約という手段に出ている。具体的には、朝食にパンを2つ食べて500〜600kcalほど確保し、昼食にはベースブレッドで200〜300kcalを摂り、夕食は適当に自炊したりスーパーで買った惣菜を食べて800kcalほど摂り、夜食で帳尻を合わせて総計で1800〜2200kcalほどを摂っている。
今日のところはうまくいっており、昼のベースブレッドだけで夕飯まで耐えることができた。お腹がすいた時に食べられるようにソイジョイを買っておいたが、食べずに済んだ。
この方策でしばらくは継続していきたいが、懸念されるのはベースブレッドが飽きた場合にどうするかである。毎日これをやれば1週間もせずにベースブレッドに飽きるだろうし、週1日だけベースブレッドで済ませ、ほかの日は別の手段をとったほうがいいかもしれない。例えば、安いファーストフード店に行き、安いメニューで済ませるなどの方策が考えられる。飲食店のキャンペーンなどによって、安く済ませられるチャンスがあれば、これを積極的に取り入れていくべきだろう。節約は飽きとの戦いなので、いろいろ工夫して飽きを遅延させていきたい。
栄養バランスを見るとカルシウムが不足している。牛乳などを取り入れておこう。
デライトを使って、分からない単語が大量に出てくる分野について勉強する際には、それらの単語を知名、説明を本文に書いた輪郭を描き出すことで、勉強が有利に進められると思われる
【理想】
作業する→次の作業する→次の作業する→……
【目論見】
作業する→SNSを少し見る→次の作業する→SNSを少し見る→次の作業する→……
【現実】
作業する→SNSを見る→SNSを見る→SNSを見る→……
OpenReviewは、主に人工知能、機械学習、コンピュータサイエンスの分野でよく使われている査読プラットフォームです。NeurIPSやCVPR、ICLR、ICML、ACL、AAAIなど多数のトップカンファレンスが使用しています。
朝から読書、論文、ラジオ体操、改善、ゲーム、プログラミングに着手した。
プログラミングは1時間ほどできた。ここまでしっかりプログラミングしたのは久しぶりだった。
就職に伴い、健康診断結果を提出する必要があるため、健康診断に行ってきた。
平日は作業があるため、あらかじめ土曜日に受けられるところを予約しておいた。
予約のあと特段連絡もなかったため本当に受けられるか心配だったが、無事に受けられ、健康診断結果も受け取ることができた。
これで安心だ。
健康診断後に夕飯を食べてたら眠くなり、仮眠のつもりで横になったら翌日の朝まで10時間も寝ていた。
この日は健康診断でカフェインも摂っていなかったし、それで寝てしまったのだろう。
というかカフェインで日頃寝不足状態だったのかもしれない。
仕事終わりに飲みに行った
デイリールーチンが実行できなかった。
夜にデイリールーチンを回すと実行できない場合が発生しやすい
朝できるように寄せていく
メッセージキューとかメッセージブローカーの使い方って、イベントの発生時にメッセージでIDなどと共に通知だけして、データ本体などは別途DBなどに格納しておき、それをイベント受信側が取得しにいくって理解でいいのかしら。
メッセージにデータ本体が載るならそのままデータも載せて、載りきらないならDBにAPIを介して取りに行くとかのほうが楽ではありそう。
ある動画でお〜いお茶がかわいく見えてくるし、ぬいぐるみに限らず、人が触っているものはかわいく見えるということでは？
とおもったのだけど、動画を改めて見直すと人がペットボトルを持っている部分は見切れて写っていなかった。
キーボード持っていかねば。
打鍵が強めなのでノートPCのキーボード壊れる。
いや、こう、早く打とうとして、底打ちの反発を使ってタイピングしてたら、だんだん打鍵が強くなってきてしまった。
一般に荒らしというのは、目立つ箇所に投稿などをして迷惑度の最大化を目論むと思うのだけど、デライトのコンテンツは閲覧が集中する点がないので、荒らすにしてもどこを荒らせばいいのか分からず荒らしづらい・荒らしがいがない気がする
おっ
ストレッチで腰が楽に
腰のストレッチ、今までやってたのは伸ばすべき方と逆だったんだわ
座ってる時に縮んでる筋肉を伸ばさなあかんかったんだわ
つまるところ股関節とか腹筋の下部とかを伸ばしたら良くなった気がする
いまのところは
描出した日付で輪郭をまとめたり、花火日報を書くと、妙に面白い輪郭が発見されるのも、時間的局所性によって同一の枠組み/包括/抽象の中での描出となる可能性が高いからだろう。それらの輪郭は意味的なまとまりを持ち、そこから意味のある枠組み/包括/抽象を見つけ出すことができる（ことが多い）。
（あれ・あれ）→共通点でつなげ、包括でまとめる→つなげながらまとめる（つなげながらまとめる）
ついに来たな！！
「つなげる」は「本文内のリンク」と「共通点で引き入れる」、「まとめる」は「包括で引き入れる」と捉えるとすっきりする。
いままでは「つなげる」を「本文内のリンク」、「まとめる」を「引き入れ」と捉えていたが、それよりもずっとしっくりくる。
もっと別の捉え方もあるかもしれないが、それでも今時点ではかなり理解が前進した。
これまでデライトの中で長文を書くに至らなかったのは、前景として輪郭を作る際に、長文を書くに資する抽象/範疇を作り出してこなかったためのように思う。
前景として作る輪郭の多くは「飲食店」のような単一のキーワードを知名にしていた。そうした輪郭の後景に輪郭がたまってきても、それらは共通点を持つだけで関係は弱く、文章としてなかなかまとまってはくれない。
KJ法で言うならば、文章としてまとまるには、「土の香り」がする抽象/範疇を作る必要がある。
資料作成からは完全に脱線し、抽象と具体の立体感の獲得についてまとめるのに熱中していた。しかし得られたものが資料作成に役立つことは間違いないし、資料作成よりも重要だったと思う。また、資料作成にはまだ時間がある。
私と似たような特性を持つ人が抽象と具体の立体感を獲得するのに役立つような何かを作っておく
抽象と具体の感覚、特に抽象から具体を見るイメージを得るのにデライトを使い始めてから5年もかかった。デライトが無ければ一生つかめなかったかもしれない。
これまで具体を見る、あるいは具体から抽象を見るしかできなかったが、後景として描出した具体から、前景として描出した抽象を積み上げてきた結果、抽象から具体を見るイメージができるようになった（気がする）。
デライトだけではなく、KJ法やソフトウェア設計などをやっていたことも効いたように思う。
また、『過程と実在』にて解説されていた哲学の方法である「真の発見の方法は、観察の大地から普遍化の大気圏へと出発し、再び元の大地に着地する」は、まさに具体から抽象を見ることと抽象から具体を見ることについて説明されていた。
「コンビニからローソンを見る」は抽象から具体を見るの一例（具体）だし、「抽象から具体を見る」から「コンビニからローソンを見る」を見ると、これもまた抽象から具体を見るになる
今まで、抽象を見たり作ったりすることはできたが、抽象へ視点を移動させ、具体の側に振り返り、そこから具体を見る、ということができなかった/そういったことを認識していなかった。
Kubernetes分からん人間からすると、Kubernetesについて調べたときに「minikube」や「kubeadm」といった固有名詞が大量に出てくるのがつらい。
YugabyteDBの勉強を再びやろうとしているのだけど、先にKubernetesの勉強が必要なように思われる。
YugabyteDBを運用するならKubernetesを使う方向になる（ほかの運用方法もあるだろうが、それらと比較検討するためにも結局Kubernetesの知識が必要になる）。
{Kubernetes K#/E97E} > {kubeadm K#/A52F-718F} >
となっていたのを
{Kubernetes K#/E97E} > {Kubernetesクラスター構築ツール K#/A52F-3B90} > {kubeadm K#/A52F-718F} >
とした。
Kubernetes直下に引き入れず、一段下位の輪郭に引き入れることによって、Kubernetesから見えない状態にしてある。
これによって、Kubernetesを開いている時には抽象（Kubernetesクラスター構築ツール）だけが目に入り、具象（kubeadm）は目に入らないようになる。
こうした操作は「知識のカプセル化」と呼べるかもしれない。