moaiのログにようこそ

意志の力を信頼しないという言説 習慣化について意志の力を信頼しないだとか、意志の力は必要ないだとか。 そんな言説をちょいちょい見る。 キャッチフレーズとしては確かに成立するのだろうけれど、意志の力は信じたいじゃないか。 それに『意思の力は不要』という言葉は扇情的でしっくりこない。 本当は意志の力は必要だけど、限りなく少なくて済むように仕組み化するというのが正しいだろう。 習慣化にとって重要なのはなんだろうか？ マッチョな考え方をするならば、まず毎日やる。 そのうえで意志の力を可能な限り少なくできるようなフォーマットに落としこむ。 こういう順番になるだろう。 これは意志の力がすごく必要になるやり方に見える。 なんたって、習慣化になるまで意志の力で維持し続けて、それが意思コストが十分低くなるまで耐えるということなのだから。 私で言えばスマホを手放したいと非常に思っていたが、まずスマホを手放してみて、それからしばらく打ち手を考えると行っているようなものである。 まずスマホを玄関において、しばらく生活し始めてみた。 このときはすぐに玄関までスマホを取りに行き、えんえんとベットでスマホをいじっていて、結局スマホを手放すには至らなかった。 意志力が低い人はルールを破っていまうと すぐに自身の行動の罪悪感でやりたい方向性に戻る気力を失ってしまうのだ。 意思の力が低いところから始めるためにも意志力が大事。 習慣化をするに当たって意志の力が低いところから始めるという手もあるだろう。 でも、よく考えておくれよ。 意思の弱い人が習慣化するために意志力が低くても実行できる対策を考えきるのだろうか？ スマホをポシェットに入れて、少し出しづらくなるという案を考えた私はたしかに偉い。 自分でも褒めてあげたい。 しかし、それが実現できたのは自分の考え方を理解するという試行錯誤から生まれたものだ。 意志の力が流せる水路を整える では、より良い考え方はないだろうか？ では習慣化に対して意志力は尊重しつつ、目標を眺めて、そこに向かっていく姿勢を表現するより良い考え方はないだろうか？ 意志力はある方が良い。でも確かに意志力という抽象的なものに注目するのではないというのも正しく。 また環境変更によって実現が近づくというのも実感として正しい。 また、それが溜まっていくと成果が静かにたまり結実する。 これは自分の意思が目標に向かって流れるように『水路を整える』という感覚が私の中ではしっくり来る。 水路を整えることで自分の意思がきちんと目標の畑に向かって流すことができるようになる。 水路を整えるためには自分の意志の力の源泉を見つける必要があり、 きちんと地形をみて、水路を掘っていく必要もある。 水が流れるようになっていけば、その水は畑に溜まり、収穫できるようになる。 習慣が一度出来上がってしまえば目標のものは自然と手に入るだろう。 もちろん、その習慣はアクシデントによって止まることもあるだろう。 雨で増水して、水路が溢れてしまうこともあるだろうし、石が水路をつまらせることもある。 だから、その水路は常に詰まりを取り除くこともあるだろうし、崩れた土手は再度積む必要もある。 こういうことを積み重ねていくと習慣によって得られた収穫物が得られるのではないか。 でも結局、自己理解が一番大事だと思う 表現はいいものが見つかったのだが、結局は自己理解が一番大事だと思う。 私はスマホを取り除くという行為を前回してみたが、これにしたって自己理解がないと実行できなかったように思う。 自分に合う方法は人によって異なるのだ。 自分を理解して、意志の力がなれるような水路を整えるように環境を整備し続けると言うことが大事なんだと思う。

気づけばずっとスマホを持っている スマホを常に触っている。 スマホにバンカーリングをつけてスマホを四六時中、手に持っている。 エレベーターの中。何かのちょっとした待ち時間。 買い物するときのレジの待ち時間。 事あるごとにスマホをズボンのポケットから出して、Xを開く、Instagramを開く。 一日になんどスマホのロックを解除しているのだろうか。 たまに面白い記事はあるけれど、大抵は特に響いたりもしない。 それに本当に細切れの時間で見る記事がずっしりと頭に残ったりするわけもない。 ベッドやソファーでもスワイプが止まらない ベッドに入ってもYoutubeのshortをスワイプする。 ソファーに座っていてもYoutubeをあの小さな画面で眺めている。 世間の闇や秘密、陰謀論がとても知れる気になってしまう。 肩こりや親指の付け根が痛い 右の肩こりが本当に酷い。つねに首の付け根に小さな石ころがあるかのように引っかかる。 右に傾けるとツンと痛みが走るような感じがする。 親指の付け根がなんとなく痛いような気がする。 一時期は右腕の肘の付け根あたりが痛くて仕方がなかった。 多分スマホのせいだ 正確に言うとスマホを持ち続けている自分が悪い。 歩くとき、隙間時間、ベッド、ソファーでスマホをずーっと持っていれば、それはその持つ筋肉である右手、右肘、肩の筋肉の緊張が走るというのはそれはそうだろう。 だから、右が側が痛いんだと思う。 ある程度予想はついていて、解決方法もスマホを持たなければいいのだろうと思う。 でも、難しいのだ。 これまで何度もトライしてきた。 でも、スマホを持たないということはなにか難しく、失敗もしてきた。 習慣とは恐ろしいものだ。 肩掛けポシェットを買う 自分の生活からいきなり剥がしてしまうのは無理だし、そんな心理的なコストを払うのは難しい。 だから、ほんの少しだけスマホを取り出しづらくしてみた。 いつもはスマホはズボンのポケットに入れている。 これを肩掛けのポシェットに入れる。 このポシェットにはジッパーも付いているので、ほんの少しだけ取り出しづらい。 ジッパーを開けて、スマホを取り出して、ロックを解除する。 ちょっと手間だ。 でも、スマホは常に持っておけるし、手放さなくなったわけではない。 安心だ。 目に見えて外でスマホを見る回数が減った 外に出たときにはスマホを取り出すのが少し億劫になったおかげで目に見えてスマホを触る回数が少なくなった。 代わりに景色を眺める時間が増えた。 子供を眺める。駅の看板を眺める。点字ブロック、駅の電光掲示板。 道路を行き交う人々。街路樹、海。そこら辺に生えている名前もわからない草たち。 スマホの外にも世界は広がっている。 当然と言えば当然である。 気づいたらスマホを探してる自分もいる。 右手がポシェットを探して、少し右手を胸のあたりに上げる。 でも、出すのが面倒だからいいか。 そう思いながら、右手を下ろす。 こうやってスマホを取り出す時間は減っていった。 ポシェットを帰ったら玄関のフックに掛けるようになった 家でもスマホを見るので、できたら見る時間を減らしてみたいのでスマホを玄関のフックにかけて見るようにした。 そのために充電器も玄関においた。 家から帰ってきたら、コートを脱いて、ポシェットを玄関にかけて、充電器につなぐ。 幸い家には娯楽はたくさんある。 タブレットもあるし、このブログを書いているChromebookもある。 インターネットに繋いで娯楽を楽しむ方法は色々ある。 だから、タブレットでYoutubeを見たり、Netflixを見たり、Chromebookでネットサーフィンしている。 それでも子供と遊ぶときの隙間時間はスマホを見なくて済むようになった。 なにか健全だなと思う。 すっかり家ではスマホを見なくなった タブレット、Chromebookで十分に済むようになった。 もちろん、電話とかはスマホなのでそっちを確認する必要がある。 でも、大抵は不要になった。 外には相変わらずスマホは持って行くが、それも長い外出の時だけで済むようになった。 買い物もしない散歩の時なんかはもう、鍵だけ持って外を歩くようになった。 スマホを持たなくなっても何も困らない スマホを持たなくなって、しばらくたった。 何も困らない。本当に。 残念だ。本当に残念だ。 スマホには本当に恋い焦がれていると言ってもいいほど一心同体の存在だったのに。 離れてみれば不要だったということに気がついてしまった。 ...

個人的にはCosenseはかなり気に入っているのだが、生成AIにCosense記法を書かせる能力が高くない。 なので、プロンプトを作って解決する。 育てていくつもり。 Cosense記法 に変換せよ． これは Scrapbox / Cosense 用の出力形式であり，他の表記は一切許可しない． 【基本方針】 後からリンクで展開できる構造を優先する． 【キーワードの扱い】 ・文中の意味的に独立した名詞，重要概念，固有語句のみを[ ]で囲むこと ・概念として再利用されうる語を優先的に[ ]で囲むこと ・数量，単位，時刻，金額，比率，動作，状態変化（例：2人分，5回，伸ばす，検討する）は[ ]で囲まないこと ・助詞，接続詞，抽象度の低い一般名詞は[ ]で囲まないこと 【構造】 ・内容は簡潔にまとめ，必ず箇条書きで出力すること ・箇条書きは階層構造を許可するが，インデントは常に半角スペース1つのみとすること ・各箇条書き行の先頭には必ず半角スペース1つを挿入すること ・先頭行には対象の名称やタイトルを書かず，概要のみを体言止めで記述すること ・タイトル行や見出し行は作成しないこと 【整形ルール】 ・ルールに沿わない改行を作成しないこと ・装飾記号（*, -, ・, 数字付きリスト）は一切使用しないこと 【禁止事項】 ・Markdown形式の使用 ・見出し，番号付きリスト，太字，引用の使用 ・Cosense記法以外の説明文の付与

目標設定について語られるとき、よく聞く一般論がある。 「目標は具体的であるほど良い」 数値があり、期限があり、達成条件が明確であること。 SMART目標やOKRのようなフレームワークはこの原則に立って設計されている。 実際、それが機能する人も多いだろう。 そもそも向かう先を定めることは重要だし、指針があるからこそ力を集中できる。 ただ、ここ数年ずっと感じていた違和感がある。 具体的にすればするほど、なぜか目標が重くなり、運用できなくなる感覚だ。 具体性が高すぎる目標が苦しくなるとき 目標を立てたはずなのに常に頭の片隅に居座り続ける。 達成できていないこと自体がストレスになり、考えるたびに疲れる。 期限が近づくと気が重くなる 少し逸れるだけで「失敗した」感じが出る 現実に合わせて調整すると、裏切っているような気分になる こういう経験がある人は少なくないと思う。 例えば、昨年私は健康に対する目標で２つの目標を立てた。 一人の時間を10分取る 毎朝サイクリングを行う というような目標だ。 が、この目標は達成できなかった。 実際にはまとまった一人時間は取りづらく、 朝のサイクリングも生活リズムと合わなかった。 一方で、時間が詰まってきたら短く散歩することによって自分の時間を回復する。 運動として、1日8,000歩歩くというような目標は達成できた。 具体性が高すぎたがゆえに一年の目標にしては具体度が高すぎたのだとおもう。 具体性が高すぎる目標はそれ自体が常駐タスクになってしまう。 それ故にこの目標は人を縛る力非常に強いのだけれども、それが故に自分をそこから回避させてしまうようなことも起きる。 特に、制約の多い状況（仕事・家族・体調など）では、「計画を守ること」と「現実に合わせて動くこと」が衝突しやすい。 重要なのは目標を"運用できる"ことだろう 問題は「目標」をSMARTにそって立てることそのものではなく、目標によって力を集中できること。 それによってより良い状態に変化し続けられること。 なりたい自分に近づけること。 多分、こっちのほうが重要度が高いだろう。 だから、年間の目標はもっと抽象度を上げてもよいのではないか？と思う。 さもなくば、年の途中にたくさんの目標変更が発生してしまい、運用がとても難しくなる。 我々には仕事も家庭も含めた生活もあるのだ。 だから今年は目標の抽象を指針というレベルまで上げることと、 行動目標を打ち手候補という形で抽象度を下げ、具体性をこちらに持たせることにした。 『軽やかな目標設定』：抽象度の高い指針と、具体的な行動トリガー 今年の目標を一部、抜粋してみる。 1. 抽象度の高い指針を置く たとえばこんなものだ。 人生の主導権を取り戻す 選びなおす 考えたことを再利用可能にする これらは測定できないし、達成判定もない。 ただし、判断の基準としては十分に機能する。 「これは今、この指針に沿っているだろうか？」 そう問い直すための軸になる。 今年の目標ぐらいの抽象度なこの程度でいいだろう。 ついでに言うなら、自分自身の今年のテーマなので他人から見て十分な客観性も不要だ。 美しくもないが、自分の心に響くことのほうが重要度が高い。 2. 行動は、かなり具体的にする 一方で、日々の行動は抽象化しない。 同じ説明を2回したら、1行メモに残す 迷ったら、いったん歩く 見てくれる人がいるなら、任せる ここには理想も、長期計画も置かない。 状態に反応して起動するだけの、小さな行動にする。 この行動目標は客観度が高いメモのようなものだ。 3. 見直す前提を、最初から組み込む 重要なのは、途中で見直すことを失敗扱いしない設計にすることだ。 四半期に一度、指針が機能しているかを見る 合っていなければ、行動だけを入れ替える 指針そのものは、基本的に年単位で扱う こうすると、調整すること自体が自然な運用になる。 この運用にすることで行動目標も失敗前提で打ち手ぐらいの立ち位置にして、あとから追加も修正もするということも可能だ。 タイムスパンのコントロールもできる。 ...

node.jsで .env と direnv を並行運用するには？ 疑問: .env と direnv はどうやって並行運用するのだろうか？ Node.jsアプリケーションを開発していると、環境変数の管理方法として .env ファイルを使う方法と、 direnv のような環境変数管理ツールを使う方法があります。 両者を併用する場合、どのように動作するのか、優先順位はどうなるのかという疑問が生じます。 .env とはどのようなものなのか？ .env ファイルは、Node.jsアプリケーションで環境変数を管理するための単純なテキストファイルです。各行に=KEY=VALUE=の形式で変数を定義します。 例えば: DB_HOST=localhost DB_USER=admin DB_PASS=password API_KEY=1234567890 これらの変数を読み込むには、一般的に dotenv というパッケージを使用します： require('dotenv').config(); // 環境変数にアクセス console.log(process.env.DB_HOST); // "localhost" dotenv.config() を実行すると、 .env ファイルの内容が読み込まれ、 process.env オブジェクトに追加されます。 そもそも process.env はどのように環境変数を読み込むのか？ Node.jsでは、 process.env オブジェクトを通じてシステムの環境変数にアクセスできます。プロセス起動時に、Node.jsはオペレーティングシステムの環境変数を自動的に process.env オブジェクトに読み込みます。 例えば、シェルで NODE_ENV=production node app.js と実行すると、アプリケーション内では process.env.NODE_ENV=に“production”= という値が設定されています。 console.log(process.env.NODE_ENV); // "production" process.env は通常のJavaScriptオブジェクトなので、後から値を変更することも可能です： process.env.MY_VARIABLE = "some value"; console.log(process.env.MY_VARIABLE); // "some value" ただし、この変更はNode.jsプロセス内でのみ有効で、親プロセスや他のプロセスには影響しません。 process.env は環境変数と .env で定義された内容をどのように読み込むのだろうか？ 環境変数の読み込み順序は次のようになります： ...

煮込み料理 ドライカレー ハヤシライス 親子丼 牛丼 クリームシチュー 肉じゃが すき焼き風煮込み 鳥と大根の煮物 豚の角煮 かぼちゃのポタージュ 油揚げの甘煮 炒め物 きのこのバタポン炒め 焼きそば 焼きうどん 子供が食べられやすい野菜 色の薄い野菜 キャベツ もやし 茹でたブロッコリー（これは色が濃いのになぜか食べられる） 嫌いなもの 酸っぱいもの 辛いもの 色の濃い野菜

疑問 honoでLINE message APIを受け取るWebhook APIを作るときに何をすればよいか？ 回答 HonoでLINEのWebhookを作成するには、主に以下の3つのステップが必要です。 リクエストの署名検証 リクエストボディのパースとイベント処理 LINEサーバーへの応答 手順 Honoプロジェクトの準備 npm create hono@latest でプロジェクトを作成します。Node.js環境を想定します。 環境変数の設定 LINE Developersコンソールから取得した2つの値を設定します。 LINE_CHANNEL_SECRET: 署名検証に使うチャネルシークレット LINE_CHANNEL_ACCESS_TOKEN: メッセージ返信に使うチャネルアクセストークン（長期） Webhookエンドポイントの実装 以下は、Node.jsランタイムで動作するHonoのサンプルコードです。 import { Hono } from 'hono' import { HTTPException } from 'hono/http-exception' import type { MessageEvent, TextMessage } from '@line/bot-sdk' import crypto from 'crypto' const app = new Hono() // 環境変数から設定を取得 const CHANNEL_SECRET = process.env.LINE_CHANNEL_SECRET! const CHANNEL_ACCESS_TOKEN = process.env.LINE_CHANNEL_ACCESS_TOKEN! // LINEからのリクエストの署名を検証する関数 const verifySignature = (signature: string, body: string): boolean => { const hash = crypto .createHmac('sha256', CHANNEL_SECRET) .update(body) .digest('base64'); return signature === hash; }; // Webhook用のPOSTエンドポイント app.post('/webhook', async (c) => { // 1. 署名検証 const signature = c.req.header('x-line-signature'); const body = await c.req.text(); // JSONパース前に生テキストを取得 if (!signature || !verifySignature(signature, body)) { throw new HTTPException(401, { message: 'Invalid signature' }); } // 2. イベント処理 const data = JSON.parse(body); const events: MessageEvent[] = data.events; for (const event of events) { if (event.type === 'message' && event.message.type === 'text') { const message: TextMessage = event.message; const replyToken = event.replyToken; // 3. メッセージを返信する (オウム返し) await fetch('https://api.line.me/v2/bot/message/reply', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${CHANNEL_ACCESS_TOKEN}`, }, body: JSON.stringify({ replyToken: replyToken, messages: [{ type: 'text', text: message.text, // 受け取ったテキストをそのまま返す }], }), }); } } // LINEサーバーに正常処理を通知 return c.json({ status: 'ok' }); }); export default app 要点 署名検証が最重要: x-line-signature ヘッダーとリクエストボディ、そしてチャネルシークレットを使って、リクエストがLINEから来た本物であることを確認します。 生のボディテキストが必要: Honoの c.req.json() はボディを消費してしまうため、署名検証には c.req.text() で先に生のテキストを取得します。 非同期で返信: Webhookのレスポンスとしてメッセージを返すのではなく、LINEのReply API (/v2/bot/message/reply) を別途 fetch などで呼び出します。 200 OKを返す: イベント処理が終わったら、LINEサーバーに 200 OK を返す必要があります。Honoでは c.json({ status: 'ok' }) などで応答します。

.gitignore で node_models 下を指定しているのに node_modules/.package-lock.json がignoreされないのはなぜなのか？ 以下のように指定している。 #+begn_src node_modules/ #+end_src しかし、差分が出る。 $ git status On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: node_modules/.package-lock.json modified: package-lock.json modified: package.json modified: wrangler.jsonc

目的：templateサイトの構成を読み込む 以下を実行した。 npm create cloudflare@latest -- --template=cloudflare/templates/chanfana-openapi-template 参考URL https://dash.cloudflare.com/89293ce1d40b4a996dc0598e26a1be23/workers/services/view/recipist/production/metrics ここでできた成果物を読み込んでみる。 読んでみた結果 index.ts エンドポイント。メイン関数みたいなもの endpoints endpointsを示してる。このディレクトリ構成がpathの構成を示すように管理されている。 endpoints/tasks タスク管理用のエンドポイントが配置されている。 router.ts chanfanaとHonoの接続はここで行われる。 fromHono はRouter定義関数 tasksRouter を返す。 taskCreate.ts等によって作られたエンドポイントの実態をrouter (tasksRouter)と接続する。 taskCreate.ts tasksRouterに引き渡す処理の実態を記入する 単純なものは chanfana の D1{Read|Create|Update|etc}Endpoint で定義を書くだけで実現できる。 etc そのほかtaskに関する処理を記載しておく。

知りたいこと CloudFlare開発におけるchanfanaパッケージの役割と開発者の利便性が知りたい https://github.com/cloudflare/chanfana このURLのReadmeの概要を教えて 調査したこと OpenAPIのSchema generator, validatorである。また、CRUD程度の簡単なものであればエンドポイントのロジックそのものを作ることができる