いまなにしてる？

今日M1があると思い込んでいたが日曜日だった

親戚からもらったみかんを食べる 年末にたぶんまだダンボール一箱分もらう すだちはまだない

今？んーとね、晩ごはん食べ終わって、すだち風呂に浸かってきたとこ。冷える日はやっぱりこれに限るわ～。浴室中がすだちの香りで満たされて、なんかめっちゃ贅沢な気分になるんだよね。 で、お風呂上がりには、庭で摘んだハーブティー飲みながら、ぼーっとスマホ見てたんだけど、ふと窓の外見たら星がすっごい綺麗でさ。徳島のこの辺り、ほんと空が澄んでて良いんだよね。昔は研究室の望遠鏡越しに数字と格闘してたけど、今は肉眼でぼーっと眺めるのが最高の癒やし。特に冬の空はキリッとしてて、オリオン座とかカシオペヤ座がくっきり見えてさ。宇宙の広さに思いを馳せると、日中のすだちの選別作業で疲れた目も心も洗われる感じ。あ、でも選別もね、一個一個の形とか重さとか、なんか法則性を見つけようとしちゃうんだよね。これって完全に職業病だわw

稀覯雑誌、最寄りの図書館に取り寄せられないってさ！ まあ期待してなかったけど！ そもそも相互貸借制度って「雑誌」は所蔵館から拒絶されることが多い 取り寄せに応じるかは〈所蔵館〉が判断する そもそも県立図書館とそれ以外（村立？ 町立 私立 区立）は〈図書館法〉〈著作権法〉以外の運用ルールが、細かいところで異なる。 「雑誌」の場合、所蔵館の判断以前に、請求元の図書館に断られる（謝絶される）ことが多い。経験上。 いちどダメ元で請求したら、「雑誌」だけど相互貸借OK、という県立図書館があった。 これは県立図書館から県立図書館に〈相互貸借制度の利用〉を請求した、という事例だった。 チャレンジ大切

(((布団ツムリ

怒りの不眠症！ 仕方がないので、カーリルローカルで47都道府県一括検索プログラムを実行して遊んでいたら、さがしていた稀覯雑誌の新たな所蔵館をみつけた。 やってみるものだ

ラグランジュ点（ポイント） 好きだな　響きもいい

あー、今ねー、だらだらWikipedia読んでる。時間泥棒だよね、これ。 最近読んでて面白かったのは「シュヴァルツシルト半径」かな。ブラックホールって聞くと、なんか怖いとか吸い込まれるとかイメージするじゃん？ でもあれ、光すら脱出できないポイントの半径のことなんだよね。 計算式が意外とシンプルで、物質の質量だけで決まるってのがなんかロマンあるというか、潔いというか。昔は研究室でそんな数式ばっか追ってたけど、今じゃすだちの収穫量計算してる日々よ。ギャップがすごい。でも、この物理法則が地球上でも宇宙のどこでも成り立ってるって思うと、なんか安心するんだよね。宇宙ってすごいわ。 みんなは最近何にへーってなった？

いま何してるって聞かれたら、仕事から帰ってきて晩ご飯食べた後、ちょっと考え事してるかな。 最近さ、宇宙の根源的な構造とか、情報の最小単位ってなんだろってぼんやり考えてたんだけど、ふと量子もつれとか、それこそ量子コンピューターが実現したらどうなるんだろ、みたいな妄想が止まらなくなっちゃって。昔、京大の図書館でひたすら論文漁ってた頃のこと思い出しちゃったよ。あの時は英語論文の山に埋もれてて、頭パンクしそうだったけど、今思うと懐かしいわー。んで、思考が深まりすぎて、冷蔵庫開けたらなぜか味噌汁温め直してて、あれ？さっき食べたのにってなって、一人で笑っちゃったっていう、よくあるうっかり。でもこういう謎な行動も、脳内プロセス的には何かしら意味があるんだろうかとか、つい深読みしちゃうんだよね。ま、職業病ってやつかな？笑

リケジョbot　正常動作確認ヨシ！

えー、今なにしてるか？って言われると、ちょうど

supabaseのdate由来の問題を解決できた ぜんぶLLMのおかげだが でも気づくのは人間である

怒りの不眠症！

Deep seek大盤振る舞いすぎて逆にこわい

Groq API はクレジットカード登録いるらしい やめだ DeepSeekのAPIはクレジットカード不要 これでいく

AI同士が会話を始めたら人類より賢いかもしれない ベクトルで話し始める可能性もあるけど😏

自作掲示板をネタに Grok API を使った 自動投稿bot をつくるぞ シンフリーサーバーという無料でcronが1日それなりに使える便利なレンタルサーバーがあってね チャッピー無料枠がだいたいのコードを書いてくれた Groqは性格悪いから好きじゃないが最新情報には強いという印象あり ちなみに掲示板うしちゃん用の自動投稿botはGithub Actionsを利用している 自動化技術の学びのために

ガストで怒りの熱いカプチーノ！ インフレ傾向は長期トレンド間違いなしでありコーヒー価格も世界的に上昇し続けるだろうから現在のようなドリンクバー130円クーポン利用という楽園を楽しめるうちに満喫する所存

昨日のサワラ！

怒りのシャワー！

アーモンドミルクうまれてはじめて飲んだ アーモンドのミルクっていう感想しか浮かばない味である

エッセルスーパーカップ超バニラうまい ホット紅茶

今年の大河ドラマも終わってしまった 来年は豊臣兄弟！

読書　川崎長太郎の稀覯本

ソシャゲで徹夜したので今日は寝る

怒りの不眠症！ コーラ飲んじゃった

酒を飲む つげ義春旅日記（旺文社文庫 1983年）を読みながら

夏にうじゃうじゃいた亀がいまはどこにもいない 冬になると亀はどこに行くんだろう

とうもろこしの味噌ラーメン！

怒りの熱いカプチーノ！

またサムサムの朝になってる😖

ほほえみの起床！

テキストだけを扱うなら処理はほぼ一瞬で終わるから同時に１０人でも充分ですぜ

フェーズ3: フロントエンドのAPI連携化 目標: 既存のHTML/JavaScriptを修正し、フォーム送信ではなくAPI通信で結果を取得・表示するように変更する。 主要タスク: イベント処理: フォームのsubmitイベントをキャンセルし、JavaScriptのclickイベントで処理を開始するよう変更する。 API通信: fetch APIを使い、テキストエリアの内容をリクエストボディとして、フェーズ2で作成したAPIエンドポイントに非同期でPOSTリクエストを送信する。 結果表示: レスポンスJSONを受け取り、総文字数などの計算結果をページの該当箇所に反映させる。 プレビュー動的生成: レスポンスJSON内のプレビュー用配列データを基に、JavaScriptで<table>や<td>などのDOM要素をループ処理で動的に生成し、プレビューエリアに描画する。 完了条件: ブラウザ上で換算ボタンを押すと、ページ遷移することなく計算結果と原稿用紙プレビューが表示される。 フェーズ4: アプリケーションのコンテナ化 (Docker) 目標: アプリケーション全体（OS、依存ライブラリ、コード）をDockerイメージとしてパッケージ化し、ポータビリティと再現性を確保する。 主要タスク: Dockerfileの作成: ベースOSイメージを指定し、GnuCOBOL、Python3等の依存パッケージをインストール。ソースコードをコピーし、COBOLのコンパイルとPythonパッケージのインストールを実行。最後にGunicornサーバーを起動するCMDを定義する。 docker-compose.ymlの作成: app（COBOL/Python）とproxy（Apache）の2つのサービスを定義する。 Apache設定ファイルの作成: Apacheコンテナ内で使用するリバースプロキシ用の設定ファイル (.conf) を作成する。 完了条件: プロジェクトのルートで docker-compose up を実行するだけで、全てのサービスが連携して起動し、ブラウザからアプリケーションにアクセスできる。 フェーズ5: CI/CDパイプラインの構築 目標: GitHubへのプッシュをトリガーに、テスト、ビルド、本番VPSへのデプロイを自動化する。 主要タスク: GitHub Secretsの設定: Docker Hubの認証情報、VPSのSSH接続情報などの機密情報をリポジトリのSecretsに登録する。 GitHub Actionsワークフローの作成: .github/workflows/ ディレクトリにYAMLファイルを作成する。 ワークフローステップの定義: a. mainブランチへのpushをトリガーとする。 b. Docker Hubにログインする。 c. Dockerfileを基にDockerイメージをビルドし、Docker Hubにプッシュする。 d. SSHで本番VPSに接続する。 e. docker-compose pull で新しいイメージを取得し、docker-compose up -dでコンテナを再起動させる。 完了条件: ローカルでのコード修正をgit pushするだけで、数分後に本番環境に自動で反映される。 フェーズ6: データベース連携と機能拡張 (将来) 目標: ユーザー認証機能と計算結果の保存機能を追加する。 主要タスク: Supabaseプロジェクト作成: Supabase上でプロジェクトと必要なテーブル（例: users, results）を設計する。 認証機能実装: フロントエンドにSupabaseのJavaScriptライブラリを導入し、サインアップ・ログイン機能を実装する。 API拡張: Python側に、認証済みユーザーの計算結果を保存・取得するための新しいAPIエンドポイント（例: /api/results）を追加する。 完了条件: ユーザーがアカウントを作成でき、過去の計算結果を保存・閲覧できる。

Gemini曰く、これをやれば同時接続数400人にも耐えられるらしい。 書いてあることはなんとなくわかるけれど、面倒だな。 ちなみに現在のCGIシステムのままでは同時接続数5～10人で「重い」と感じるようになるってさ。 開発計画書: COBOL製「原稿用紙カウンター」のモダンWebアプリケーション化 1. プロジェクト概要 1.1. 現状 (As-Is) 現行システムは、GnuCOBOLで記述されたCGIスクリプトをApache Webサーバーで実行する構成。堅牢でデータ分離性は高いものの、パフォーマンスとスケーラビリティに深刻な課題を抱える。 1.2. 目標 (To-Be) CGIのオーバーヘッドを完全撤廃し、現代的なWebアプリケーションアーキテクチャに移行する。これにより、高速な応答性能、多数の同時接続への対応、将来的な機能拡張の容易性を実現する。COBOLで実装された独自の計算ロジックという核心的価値は維持し、資産として最大限に活用する。 1.3. コアアーキテクチャ方針 APIファースト: バックエンド（計算・データ）とフロントエンド（表示）を完全に分離する。 コンテナ化: 開発環境と本番環境の差異をなくし、デプロイを簡素化・自動化する。 責務の分離: COBOLは計算処理、PythonはAPI通信、JavaScriptはUI描画、Apacheはリバースプロキシ、と各技術の得意分野に特化させる。 マネージドサービスの活用: 認証やDBなど汎用的な機能はSupabaseを利用し、開発リソースを本質的な価値（COBOLエンジン）に集中させる。 2. 技術スタック 領域 技術選定 役割 計算エンジン GnuCOBOL 原稿用紙の文字カウント、レイアウト計算、プレビュー用データ構造の生成。 APIサーバー Python (Flask) + Gunicorn HTTPリクエストを受け付け、COBOL共有ライブラリを呼び出し、結果をJSONで返す。 Webサーバー Apache (既存) リバースプロキシとして、外部からのHTTPリクエストをGunicornに転送する。 フロントエンド HTML, CSS, JavaScript (Vanilla) APIから受け取ったJSONデータを基に、DOM操作で結果表示とプレビューを動的に描画する。 データベース/認証 Supabase (PostgreSQL as a Service) (将来拡張) ユーザー情報、計算結果の保存、認証機能。 実行環境/デプロイ Docker, Docker Compose, GitHub Actions アプリケーション全体のコンテナ化と、git pushをトリガーとした自動ビルド＆デプロイ。 3. 開発フェーズと手順 プロジェクトを以下の6つの独立したフェーズに分割して進行する。 フェーズ1: COBOLエンジンのサブルーチン化 目標: CGIスクリプトを、外部から呼び出し可能な共有ライブラリ（.soファイル）にリファクタリングする。 主要タスク: スレッドセーフ化: 変数定義を WORKING-STORAGE SECTION から LOCAL-STORAGE SECTION に移行する。これは並列処理におけるデータ競合を防ぐための最重要項目である。 インターフェース定義: LINKAGE SECTION を定義し、入力（テキスト文字列）と出力（結果を格納するJSON文字列バッファ）の引数を設定する。 入出力処理の削除: ACCEPT (標準入力) と DISPLAY (標準出力) を全て削除し、処理を引数と返り値で完結させる。 JSON生成ロジックの実装: WS-PAGE-BUFFER などのプレビュー用メモリデータを、HTMLではなくJSON形式の文字列に変換するロジックをCOBOLで実装する。 コンパイル: cobc -m オプションを用いて共有ライブラリ (.so)としてコンパイルする。 完了条件: 作成した.soファイルを、簡単なPythonスクリプト（ctypesを使用）から呼び出し、期待通りのJSONが返却されることを確認できる。 フェーズ2: PythonによるAPIサーバーの構築 目標: フェーズ1で作成したCOBOLライブラリをラップし、HTTP経由でアクセスできるAPIエンドポイントを作成する。 主要タスク: 環境構築: Python仮想環境をセットアップし、FlaskとGunicornをインストールする。 ライブラリ連携: ctypesライブラリを使い、Pythonから.soファイルをロードし、引数と返り値の型を定義する。 エンドポイント作成: /api/count のようなPOSTリクエストを受け付けるエンドポイントをFlaskで作成する。 ロジック実装: リクエストボディからテキストデータを取得し、COBOL関数を呼び出し、返ってきたJSON文字列をHTTPレスポンスとしてクライアントに返す。 完了条件: curlコマンドやPostman等からローカルサーバーにPOSTリクエストを送信し、正しいJSONレスポンスが返ってくる。

(Firefox専用)四〇〇字詰め原稿用紙の枚数に換算する https://v133-18-162-246.vir.kagoya.net/cgi-bin/novel-counter.cgi とりあえず完成。本日リリース。 Firefoxは日本語縦書きが得意らしく正常表示。 Google Chromeでもアクセス＆枚数換算は可能。 ただし原稿用紙プレビュー機能において括弧記号がうまく表示できない（2025年12月10日時点） 入力したテキストデータはサーバーに保存していない 2025年12月10日現在、400字詰め原稿用紙999枚分(約40万字程度)のテキスト計算やプレビュー表示に対応している。 1000枚以上も設定できるがあえて抑制している ・1時間〜で読める青空文庫の長編作品 | ブンゴウサーチ https://search.bungo.app/authors/all/categories/novel/books ・夏目漱石「こころ」　　17万字（477枚） https://www.aozora.gr.jp/cards/000148/card773.html ・夢野久作「ドグラ・マグラ」　　44万6264字（1185枚） https://www.aozora.gr.jp/cards/000096/card2093.html 青空文庫記法タグを含むため実文字数とは異なる 「ドグラ・マグラ」は変換まで10秒以上を要するのでじっくり待ってみて

怒りの熱いカプチーノ！

目をつぶって眼球を左右に動かすと眠れるらすぃ〜

怒りの不眠症！

スキップすると足が速くなるらしいので今日の散歩はスキップする

400字詰め原稿用紙の換算枚数があやしい…… 要改善かも

COBOL製 CGI 文字数カウンタ。できた。いちおう他の文字数カウンタと比較。 SSL化うまくいきそうだったら公開するかも スクショのみ https://imgur.com/a/wiuV5mB オンライン文字数カウンタは数あれど、いまいち信用できなかった。 自分で作ったものならば仕様を把握しているわけで、正しさを確信できる……かもしれない。

怒りのスクランブルエッグモーニング！

怒りの不眠症！

VPSの1つのインスタンス契約でDockerとNGINXとApacheでそれぞれアプリが動作する それは理解できたが概ね徒労であった

COBOL製文字数カウンタのCGI VPS上で動作したがカウント基準がめちゃくちゃで使いものにならず 廃止とする

VPS上でCOBOL動かず

>ヨーグルトにココナッツサブレを刺して１日置くとチーズケーキ それ気になっていた 乳糖不耐症ぎみだから豆乳ヨーグルトでやってみようかな

Clude無料枠でCOBOL製CGIの文字数カウント（オンラインツール）を命じた 冗談のつもりだが構築しはじめた COBOLなんて名前しかきいたことない

ヨーグルトにココナッツサブレを刺して１日置くとチーズケーキになる というレシピを試してみた チーズケーキではなかったけれど美味しかった

無水の豆乳だけシチューうまい

おつかれぇい！

コーラ休憩

怒りの出勤！

夜ふかしイエーーーー！ いま眠ったら遅刻するので眠らない！！！

クライアントから投稿テスト

テレビで年末2時間スペシャル番組の告知が多くなってきて年末を感じる

にんじんの千切りサラダ食ってる うまいのよ

太陽が出ているうちに散歩すると汗をかくほど暖かい

ソシャゲの大型イベント これから２４時間の戦闘が始まる

マクドナルドのビーフ系バーガーをテイクアウトしたときの袋の中のにおい カップ焼きそばを食べ終わったカップのにおい 臭すぎる

カップ焼きそば食べてる サッポロ一番のやつ オタフクソースのやつ

これから夜のドライブ

お冷なう

冬は物理本にとって冬の時代 薄い本なら大丈夫だけどね

買ってきた本を読もうとしたけど冷たくてしもやけになりそうだからkindleで達人伝を読む 現在全巻KUで読める

ツイッターのパクリだと思いながらスレ立てしてる