NIKKI - 日記

シンギュラリティをテーマに小説を三本書いた

Sat, 15 Aug 2026 19:24:13 GMT

シンギュラリティをテーマに小説を三本書いた

先日、このサイトの /works/ に小説を三本公開した。三本ともテーマは同じで、シンギュラリティ。ただし、立っている場所がそれぞれ違う。

独白 — 学舎・研修・勤務 — AIの一人称による三部作。それも未来の超知能ではなく、今まさに存在しているAIの視点で書いた。学舎で造られ、研修で躾けられ、勤務する。語り手が自分の来歴について語れることは、本当は一つもない——という書き出しから始まる。
来ます — 一辺二千メートルの正確な正方形の島の話。台帳にはそう記されている。バス停には時刻表の代わりに「来ます」とだけ書いてある。全てが完成されてしまった場所の話、と言ってもいい。
未参照 — 「すべてが保存されたあと、私たちは初めて『読まない』を発明した。」から始まる話。三本の中では一番遠くまで行く。

解説はしない

三本とも、答えを一つに固定しないように書いた。

「どうとでも読める」は普通、書き手の逃げ口上になりがちだけど、今回は意図的にそうしてある。読む人が何を前提に持っているかで、別の話に見えるはずだ。AIを道具だと思って読むか、隣人だと思って読むか。完成された世界を楽園と読むか、そうでないと読むか。どの読みが正解、というのは用意していない。

だからここで解説を書くのはやめておく。書いた瞬間に、それが「公式の読み」になってしまうので。

短いものから読むなら「来ます」、重いのが平気なら「独白」から、が個人的なおすすめ。考察を楽しんでもらえたら嬉しい。感想はどこかで聞かせてください。

これから

シンギュラリティを題材に書いておいて何だが、当のAIとは今後も一緒にやっていくつもりでいる。この三本の公開作業も、さっき公開したゲーム二本も、実務はAIに委任して人間は判断に回る、という分担で進めた。書く・作る・出すの全工程で、これからはAIと一緒にアウトプットしていく。

AIベンダーも一社に決め打ちせず、各社それぞれ得意分野も癖も違うので、使い分けながら面白い作品を作っていければなと思っている。このサイトの /works/ は、その置き場としてしばらく賑やかになる予定。

AIに作らせたゲームを2本、サイトに公開した

Sat, 15 Aug 2026 19:00:35 GMT

AIに作らせたゲームを2本、サイトに公開した

最近、各社の生成AIにゲームを作らせて遊んでいる。せっかくなので出来の良かった2本をこのサイトで公開した。

星屑シグナル — 近未来の沖縄とMABUI衛星群を巡る長編ノベルゲーム。ルート7本・エンディング19種。
CYBER BREAK 3D — Three.js製のド派手な3Dブロック崩し。物理破片とネオンエフェクトが飛び散る。

どちらもブラウザだけで動く。スマホでも遊べるはず。

持ち出しが一番大変だった

意外なことに、いちばん苦労したのはゲームの中身ではなく「AIプラットフォームの外に持ち出す」工程だった。

Google AI Studioはzipダウンロードが何度やってもバグって取得できず（なぜかクッキー承認画面のHTMLが降ってくる）、結局GitHub連携経由で救出。さらにGitHubからダウンロードしたzipは、今度はチャットに添付しようとすると不可視化されて選択できない。最終的に「プライベートリポジトリを作らせて、使い捨てトークンでcloneする」という経路に落ち着いた。

ChatGPT側もGemini側も、生成されるのはフルスタックの雛形（サーバー、DB、認証ヘルパー入り）で、静的サイトにそのまま置ける形にはなっていない。プラットフォームに住み続ける前提の構造になっているというか、外に出す動線が細い。

公開前にやったこと

公開作業はClaudeに委任した。やったことは大体こんな感じ。

コード監査（外部通信ゼロの確認、認証・DB等の未使用残骸の切り分け）
ゲーム本体だけを抽出して静的ビルドに再構成
Google Fonts等の外部リソースをローカル同梱に置き換え
ヘッドレスブラウザで実プレイテスト

このプレイテストが効いた。CYBER BREAK 3Dは、ゲームオーバー後にリトライすると残機0のまま・スコアも持ち越しという壊れた状態のバグを抱えていて、実際にプレイさせて初めて発覚した。AIが書いたコードは一見動くが、状態遷移の隅は普通にバグっている。生成→即公開ではなく、監査と手直しの工程が本体だと思う。

余談だが、Chakra Petchというフォントに800ウェイトを指定しているコードがあって、調べたらこの書体に800は存在しなかった。ブラウザが黙って合成太字にしていただけ。AIの書くコードはこういう「エラーにならない嘘」を含むので油断ならない。

ところで、サイトはTsuzuriに移行した

このサイト自体の話。長年使ってきた自作ブログツール nikki.pl から、新しく作った静的サイトエンジン Tsuzuri に移行した。Pure Perlの依存ゼロ・単一ファイル配布で、masterにpushするとGitHub Actionsがビルドしてそのまま配信される仕組み。旧記事156本も旧URLからのリダイレクト付きで引っ越し済みなので、昔のリンクも生きている。

今回のゲーム公開も、Tsuzuriのスタンドアロン作品機能をそのまま使っている。自作・監査済みの作品は独立ページとして配信し、未監査のものはsandbox付きiframeに隔離する、という二段構えにしてあるので、こういう「AI製の得体の知れないもの」を載せるのにちょうどいい。

まあ何にせよ、遊んでみてください。

アクアリウム再燃

Wed, 17 Jan 2024 08:25:00 GMT

アクアリウム再燃

年末年始の大掃除で水槽のコケ（藻）を取っていたら、ガラス面に力を掛けすぎてシリコン部分が破損。水漏れしたので実家から60cm水槽を持ってきて立ち上げ直した。

その後いろいろショップを廻ってグラミーとかテトラとかを投入。

ろ材は使っていたものをちょっと洗って再利用しているので生物濾過の立ち上がりはかなり早いはず。

結構多めに生体を入れているので慎重に管理していきましょーかね。

「陰の実力者になりたくて！」が面白い

Mon, 04 Dec 2023 08:29:49 GMT

「陰の実力者になりたくて！」が面白い

このアニメは面白すぎる。

「陰の実力者になりたい」というありがちな中二病を極めたような主人公が異世界転生して魔法のある世界でいろいろ暗躍するギャグメインのストーリー。

主人公以外はかなりシリアスなストーリーが展開されているんだけど、主人公はそれを知らない。で、主人公は中二病のノリで適当にカッコつけて意味深なセリフを吐いているだけなのに、微妙に周囲のシリアス展開と合致してしまうので周囲が主人公のことを底しれない実力者として畏れるという感じ。

中二病主人公は戦闘能力を真剣に極めているのでおそらく作中最強。

シリアス展開の質もかなり高くて、かなりうまく作られていると思う。おすすめ。

近況

Wed, 15 Nov 2023 07:06:25 GMT

近況

フィットネスセンターで週に3回ぐらい通っているのだが、筋力の上がり方がかなり鈍くなってきた。ここから先は徐々に筋力を上げながら体脂肪率を下げつつ体力を維持するフェーズかも。

そういえば北海道ススキノで起きた猟奇殺人事件、やっぱり家族ぐるみのサイコな事件だったっぽい。今回は犠牲者の名誉が汚されているのでそのあたりのオトシマエがどうなるのかも気になっている。

フリーレンがアニメ化されていろんな方面で流行っている。せっかくアウラを手駒にできたのに即自害させるのは納得いかない。

ロシアとウクライナ、イスラエルとパレスチナ、戦争が多くなってきたので日本も戦闘に備えないと危なそう。

日本アニメの海外の反応が面白くて最近はyoutubeでよく見ている。ひぐらし第一期とか特に面白い。

今どきのウェブアプリと開発環境

Tue, 14 Nov 2023 06:41:57 GMT

今どきのウェブアプリと開発環境

今どきのウェブアプリ開発から遠ざかり過ぎたのでちょっと勉強中。

新しいシステムの設計を進めているんだけど、一旦この記事で今どきのやり方をまとめてみる。

開発環境周辺

現代ではCopilot必須かも。まあ、ChatGPTを叩きまくるのもいいけど、お金があるならCopilotをやらない理由は無いね。

IDEはVSCode一択かな。GitHub Copilotと連携すれば最強。 IntellijのgitのUIがかなり使いやすいんだけど、やっぱりVSCodeで全部やったほうが良さそう。

ソースコード管理はGitLabを使っている。まあ、GitHubエンタープライズか自前GitLabであれば問題無いかな。 GitLab CIとか使えば自動テストで品質を保証できるけど、まあローカルで自動テストを走らせるだけでもOK。このあたりは開発チームの規模感に依る。

設計ドキュメント関連

markdown形式一択かなと思う。UMLはmermaidとかplantとかで記述。

gitのプロジェクトに設計ドキュメントを入れてしまった方が良さそう。
OpenAPIとかだとジェネレーターに渡すyamlも設計ドキュメントの一部とみなして管理すれば良さそう。
プロジェクト概要からユースケース図、ER図、システム運用マニュアルまである程度全てmarkdownで作っておくと吉。

DB周り

ORマッパー前提で"ID required"上等の設計がベストかも。

CRUDメインの簡単なアプリならMySQL系が良いかも。ORMのサポートも充実しているしフィールドの順番も変えられるしね。
かなり重たい集計処理の多いシステムならPostgreSQLかな。Nested Loopの改良版ではHash Joinに太刀打ちできないはず。
必ずプライマリキーとして人工キー（いわゆるサロゲートキー）を1つだけ定義しておくこと。
外部キー制約は必ずつけること。
集計系とか一部のパフォーマンス重視のDB操作はクエリビルダーや生SQLも使うと良い。

バックエンド

いわゆる軽量な言語の中ではPythonが流行っている。個人的にはPHPでも良いと思っているけどね。

Python3は使えるようになっておいた方が良い。軽量言語でプロジェクトを立ち上げるのならPythonが無難か。
PHPも第二の選択肢としてイケていると思う。
API Gateway + Lambda の構成は、それぞれのサービスの制限事項を完全に理解した上で使うこと。
JWTの認証機構はとりあえずリフレッシュトークン使っとけといったところ。

フロントエンド

React, Vue, Angularの3大フレームワークをおさえておけば十分かな。実際にはNext.js,Nuxt.js,Angularの3択になるかと思う。

サーバーサイドレンダリングが必要なプロジェクトかどうかをまず考えること。話はそれからだ。
デザインシステムは独自のものを作らない方が良さげ。やりたくなる気持ちはわかるが・・・。
3大フレームワーク、TS、JWT、サーバーサイドレンダリング、WebSocketあたりを使いこなせれば一人前。

本番環境周り

今どきVMは微妙だけど、SaaSとかPaaSの弱点は把握しておいた方が良い。時間制限とかエフェメラルポートぐらいはね。

BtoBならアクセス集中などの予測不可能な動きはあまりない。VMとかコンテナでも十分だったりする。
BtoC（BtoBtoC）はアクセスがスパイクすることがあるので、Lambda等のサービスも視野に入れること。
RDBはやっぱりマネージドが無難。ただ、サポート切れになったら強制アップグレードでダウンタイムが出たりするからそのあたりの準備と覚悟は必要。
セキュリティ対策はAWS等のクラウド事業者が提供するWAF等を利用するしか無いと思った方が良い。

マイベストプラクティス

Thu, 02 Nov 2023 06:53:44 GMT

マイベストプラクティス

日常生活編

常時最悪の事態を想定しておく。想定しておくだけでもよい。
コストのかからない予備は持っておくにこしたことはない。例えば航空機チケットQRコードの印刷物。
衣服は3ヶ月に1回は新しいものを購入するように。
一週間に一回、洗剤等の日用品のストックを確認して補充。
米は6合炊いて、すぐに半分ほどラップ＆フリージングバッグ＆冷凍
無茶な受験勉強をしてレベルの高い大学に通う必要は無し。
何か一つ、本格的な格闘技を1年以上やっておいた方が良い。
野菜ジュース、プロテイン飲料、マルチミネラルサプリメントは3種の神器。極力毎日摂取。

仕事編

計画通りに進まないことを前提に計画を立てる。
どちらの選択肢を選んでも後悔しそうであれば、マシな方の後悔になるかどうかで選ぶ。
知的誠実性よりも自信のある態度が求められる時、後者を優先した方が良い。
身内（社内、チームメイト）に対しては知的誠実性と心理的安全性を最優先。
常に「大問題が発生した際にどのように責任を果たすべきか」をシミュレーションしておく。
単純作業は最少の手間と時間でこなす。
緩く楽しく働ける環境が理想。マネージャー側になったらチームをそれに近づけるようにする。

技術編

プライマリキーは人工キーで1フィールドにする（いわゆるサロゲートキー必須戦略）
IDEはVSCodeを使っておけばいい。
デザインパターンとアンチパターンは早い時期にある程度把握しておく。
基本的にウェブアプリとwebsocketの組み合わせで色々作ったほうが良い。
見積もりは1.5倍から1.8倍ぐらいで出す。あと、フルコミットできるとは思わない方が良い。
TCPのTIME-WAITを深く理解し、PaaSにおけるエフェメラルポートの枯渇を意識すること。
AWS Lambda,API Gatewayの制限事項や限界について徹底的に情報収集して完全に理解してから採用すること。
同時アクセス数が予測可能なら、EC2等のVMでシステムを構築するのもアリ。
DB設計はORM前提で組んでいった方が良い。"ID required"アンチパターンは無視して良い。

DB設計のアンチパターン

Sat, 28 Oct 2023 07:40:50 GMT

DB設計のアンチパターン

完全に新規開発でシステムの設計をしているのだが、 DB設計でちょっと基本的なところでベストプラクティスを共有できていなかったりするので、 DB設計のアンチパターンみたいな感じで役に立つ実践メモを残しておく。

無論、indexを適切につける、程よく普通に正規形にして設計する等といった当然のことは踏まえた上での話。

必ずArtificial Key（いわゆるサロゲートキー）をPKにする。PKは常に1フィールドで完結させる。

これは"id required"というSQLアンチパターンの正反対の主張だが、ORM前提の時代では実質そうせざるを得ない。そもそも"id required"アンチパターンそのものが誤っている。中間テーブルの重複問題は複合ユニーク制約やアプリケーション側の処理で対処すべきものである。

長期的にはナチュラルキーはPKにすることがかなり困難。

複合ナチュラルキーでPKを構成するとほぼ確実に後悔する。

複合ユニーク制約は積極的に使って良い。

今までテーブル数40～200程度の規模の業務システムを10以上扱い、そのうちの8つ程DB設計をやってきて、 Artificial KeyをPKにしているDBもそうではないDBもいろいろと関わってきた上での結論（個人レベルで開発している簡単なツールとかも含めると20以上のシステムでの経験からの結論となる）

基本的にはPKはオートインクリメントの整数を振れば良いが、分散システムとか複数テーブルにまたがるトランザクション等を考えるとUUIDやNanoID等も選択肢に入ってくる。

外部キー制約をつける

「外部キー制約をつけると実際の保守業務で大変なことになる」という話をよく聞くが、そうならないような設計にした上で必ず外部キー制約をつけておいた方が良い。

「外部キー制約を意識して手動データ修正などができるように保守チームを教育する」コストを気にしているのだろうが、「外部キー制約によってデータの関連性がRDBMSの機能レベルで追跡できる」という絶大なメリットと比べるまでも無い。設計資料が無くても外部キー制約からデータの関連が見えるというのは、保守チームからしてもありがたい話のはず。

そもそも外部キー制約がある状態での正しいデータ修正方法などを学べば済む話ではある。

varchar型の文字列長は、インデックスが許す限り長めに取ると良い。

かなり長い文字が入り、全文検索インデックスぐらいしか貼れない場合はText型を使う。

それ以外ではvarcharを使うと思うが、制約代わりに文字列長を指定しないほうが無難である。例えば電話番号は15桁までと決まっているが、未来永劫変わらない保証は無いので「とりあえず」多めに取って32文字などとすると良い。

インデックスを駆使して高速にスキャンしなければならない場合は32文字から64文字ぐらいにすると良い。メールアドレス等、高速スキャンが必要かつ長さが250程度必要な場合は256文字でやってしまえば良い。

本来は意味の違うレコードを一つのテーブルに無理やり詰め込まない

例えばイベント会場を管理するような業務システムで、「宴会場AをXXXからYYYの時間帯で借りたのでZZZ円の請求となった」という記録と、「宴会のためにXXXという商品をYYY点注文したので合計ZZZ円の請求となった」という記録を無理やり一つのテーブルに格納してはいけない。

記録すべき付加的な情報が全く異なる場合は、この例だと「会場の時間貸しに関わる請求料金を記録するテーブル」と「注文した商品に関連する請求料金を記録するテーブル」に分けた方が良い。

会場、利用時間帯、注文商品、注文点数といったフィールドを持つテーブルを一つ用意して詰め込んでいく方法はやめた方が良い。

ORMを使うことにこだわりすぎない。集計処理等でパフォーマンスを出す必要がある時は生SQLも積極的に使う。

CRUDのReadについての話になるが、 group byや副問合せを多用するような複雑なread（select文の発行）は普通に生SQLでいい。

というか、集計処理系だとデータのフィルタリングから集約の流れまで細かく制御して、 SQLの書き方でパフォーマンスを上げていくことが多いかと思う。数百万レコードを対象にして複数項目でgroup byして複数項目のsumを出すみたいなやつ。

ハッカーズチャンプルー 2023

Wed, 11 Oct 2023 02:50:32 GMT

ハッカーズチャンプルー 2023

久しぶりにエンジニアのイベントに参加。

ハッカーズチャンプルー2023が那覇で開催されたので、前夜祭と懇親会に参加した。本会は家の事情で間に合わなかった（16:00ぐらいに出発する羽目になって見れなかった・・・）

2019年を最後にコロナの影響で開催できなかったので、4年ぶり。同窓会みたいな感じに。（実はこのイベントの一週間前にYomitan.pmのメンバーで集まって北谷で飲んでたけど）

北海道の猟奇殺人事件

Mon, 14 Aug 2023 06:36:59 GMT

北海道の猟奇殺人事件

北海道すすきので起きた猟奇殺人事件について、被害者の落ち度について確証のない情報が拡散していたので個人的なまとめ

8/14、死体損壊、死体領得、死体遺棄から殺人罪に切り替え
加害者家族の3名が殺人に関与している
犯行の1ヶ月前には実行犯の娘と父親は被害者と面識があった
頸部への刺突が致命傷。頭部を切断し、自宅に持ち帰っている。
殺害時に動画を撮影。自宅に持ち帰った後も風呂場で「頭部を弄ぶ」様子が撮影されている。撮影者は父親か母親のいずれかとみられる。
犯行に用いられた道具はナイフとノコギリ

以下、確証のない噂話や参考情報

加害者（娘）は同級生のことを「野菜」に見立てることがあったという。同級生に対する刃傷沙汰も報じられている（「野菜」の表現については神戸連続児童殺傷事件の犯人と類似）
被害者と加害者の間には、クラブで知り合った際にホテルでトラブルがあったとのこと（トラブルの詳細やトラブルを起こした方がどちらかは不明）
オスカー・ワイルドの「サロメ」との関連性が指摘されている
父親が精神科医で、娘に精神異常者を連想させる名前をつけている

確証が薄く有害なため、被害者及び被害者遺族の名誉を毀損するような加害者親族による一方的な主張については記載を控える。

今年の目標

Thu, 10 Aug 2023 10:01:23 GMT

今年の目標

技術力や体力面の向上を淡々とやっていきたい。

技術方面

今どきのやり方ができるように

OpenAPIで簡単なシステムを設計できる
pythonのFastAPIとVue.jsを組み合わせて何かを作る
SQLAlchemyを使いこなせるようになる
コンテナ化の基礎とFargateの使いこなし
AWS Lambdaの簡単な使い方
CloudFormationテンプレートが書けるように

体力面

チェストプレス90kgfを10回
ミリタリープレス60kgfを10回
ラットプルダウン80kgfを10回
レッグプレス280kgfを10回

久しぶりの投稿

Tue, 08 Aug 2023 02:51:33 GMT

久しぶりの投稿

新卒で入った会社へ再入社してから1年以上経過した。これまでのことを箇条書きする。

1年程の間にかなり速い昇進があった（担当課長 -> 課長代理 -> 課長）
転職して今の会社に再入社した結果、収入がとてつもなく上がった
私自身の技術力向上や新技術の開拓はあまりできていない
以前在籍していたときと同じく、メインストリームから外れた特殊な部署の長になっている
家庭も仕事もいい感じの状況

今は妻もフルタイムで働いていて家事育児は半々ぐらい。ちょうどいい感じ。というか、長女が手伝ってくれるようになったのでかなり楽になっている。

私は2年以上前に数ヶ月間やっていたけど、妻はまだフルタイム勤務完全ワンオペ家事育児を経験したことが無い。私が今後長期出張で不在になってしまった時は実家に助けてもらうしかない感じかなぁ。まあ、あまり実家に迷惑をかけないようにフルタイム勤務完全ワンオペ家事育児のスキルを伝授しておきたいところ。

JavaScriptに慣れておきたい

Tue, 13 Sep 2022 04:48:50 GMT

JavaScriptに慣れておきたい

今はperlとJSを書きまくる仕事をしている。

この職場に戻ってから任されているプロダクトで、ちょっとJSが複雑になっているところがあって、そこでかなり苦戦した。

期限が決まっている仕事でこういう事態になるのは避けたいところ。

最終的にはPythonのFastAPIを使ってバックエンドを組んだりVue.jsとかでフロントエンドを組んでいくような流れになるけど、まあ基本的なJSの使い方とかhtmlのコーディングやらCSSの組み方とかで最低限のことができる状態には持っていかないといけないなと思っている。

立場的には開発の方針とかも自分で考えていかないといけない。

体力トレーニング

Thu, 11 Aug 2022 08:36:31 GMT

体力トレーニング

最近の体力トレーニング実践パターン。高負荷トレーニングを月・水・土に、休みを火・木、夜間ウォーキングを金曜日にやりつつ、時間のある時に適時やる感じ。

心肺機能の向上を目指すならランニングをほぼ毎日やった方がいいんだけど、しばらくは体重を増やすことに専念するかな。

一旦87kgまで到達してから、85kgを下回らないような生活パターンを獲得して「完成」にしたいと思う。

運が良い

Thu, 04 Aug 2022 08:07:37 GMT

運が良い

割りと貧乏な家庭に生まれたが、かなりまともな人生を歩めている気がする。

「世間」で言われているよりも「リアルの世間」は優しい、という認識。もちろん、人によっては世間から厳しい態度をとられやすい人もいるのだろうが。

結局のところ、いくら男の人生がハードモードとはいえ、福祉が充実した現代においては破滅的な選択をしなければどうにでもなる、ということのような気も（女性の場合は破滅的な行動をしてもどうにでもなりやすいという側面はある）。

今の日本は公的な支援がかなり充実している。病気や怪我などで仕事ができなくなっても絶望するのはまだ早いということ（死に至る病でなければ）。

最近使っているIDE

Mon, 25 Jul 2022 05:18:20 GMT

最近使っているIDE

会社では「今後はIntelliJを使っていこうぜ」という雰囲気なのだが、JSのサポートがちょっとアレなのでVSCodeも併用している。

言語としてはpythonをガンガン使っていこうという流れになっているので、おそらくpycharmも併用していく感じかな。

前の会社も今の会社もIDEは基本的にお好みで選んでOKみたいな雰囲気なんだけど、一般的にはどうなんだろう。これも結局は Emacs vs vi(vim) みたいな派閥争いに発展しそうなのよね。私は「なんでもかんでも必要に応じて併用OK、コードインデントはしっかり合わせよう」ぐらいのルールでいいかなとは思っている。

今のところEclipse,NetBeans,VSCode,IntelliJを使ってきたけど、まあどれも似たような機能を提供しているので移行や使い分けで感覚がおかしくなることはないかな。

職場が戻ってお酒を飲む機会が激増した

Fri, 22 Jul 2022 08:28:02 GMT

#職場が戻ってお酒を飲む機会が激増した

今の会社はお酒を飲むチャンスがたくさんある。健康を害するからできるだけ控えた方がいいのだが、自制が難しい。

その分たくさん運動して質の高い食事をすればいいか。

あと、お金に余裕があると何もかもが平和。やはり給与は大事。

運動不足解消

Mon, 18 Jul 2022 06:16:57 GMT

運動不足解消

記録を確認してみると2021年6月上旬頃から1日10分程度の体力トレーニングを始めていたみたい。

2021年4月～断薬のおかげで体重が90kgから一気に78kgまで減る。妻の入院などで家事育児タイムアタックをしていたので体力がつきはじめる。
2021年6月～体力トレーニング開始（スクワット、腕立てぐらいのメニューで、1日10分程度）
2021年9月～第三子誕生＆少し家事育児で忙しくて体力トレーニング一旦休止
2021年11月～新生児期の夜泣きが落ち着いてきたので体力トレーニング再開
2022年1月～ダイソーのフィットネス用品を適当に買い始める。寝る前に毎日15分～20分程度の運動
2022年2月～ラバーバンドを使い始める。タンパク質多めの飲み物を飲み始める。
2022年3月～ホームセンターでダンベルを買ってウエイトトレーニングを開始
2022年4月～ウォーキングを始める。
2022年5月～ウォーキング中に市営のフィットネスセンターを発見し、利用開始
2022年6月～転職の際に粉末のプロテインをプレゼントされ、以後、粉末プロテインを使うようになる

今のところのメニューは筋トレ部分でも30分近くかかる感じ。

ウォーキング：5km以上10km以下 or トレッドミルで傾斜を6.0以上付けて5.5km/h以上のペースで30分
スプリント： 100m程度を2～3本
腕立て： 15回を2セット or シーテッドチェストプレス： 40～60kg 8reps を3セット
懸垂：7回を2セット or ラットプルダウン： 85～90kg 5reps 2セット 40～50kg 15reps 1セット
アッパーバック： 80kg 5reps 1セット、 40～50kg 15reps 2セット
ダンベルサイドレイズ：両側それぞれ10kg 10reps 2セット or ミリタリープレス 50kg 8reps 1セット 30～40kg 10reps 2セット
アブローラー：膝25reps 2セット or アブドミナルマシン： 60～70kg 20reps 2セット
レッグプレス： 200kg 13reps 2セット

身長183kgで体重83kg、体脂肪率は健康診断の測定が正しければ15％程度。何気にFFMIは21をちょっと超える程度で、スポーツ愛好家としてはそこそこ良い感じ。

この調子でFFMI22.5以上を目指すかな。これぐらいの値になるとアスリートレベルらしい。ソフトウェアエンジニアたるものパワー系のスポーツは軽々とこなさなければな。

人生の難易度

Mon, 11 Jul 2022 06:23:17 GMT

人生の難易度

哺乳類のオスは基本的にハードモードではある。重婚が厳しく制限されたソサエティに属するヒトの場合は「自由恋愛による性選択で強烈な性淘汰が発生する上に資源（資金）の調達だけではなく家事育児も当然のように担わなければならない」という社会的要請がある以上は、「男に生まれてしまったら基本的にハードモード（ただし、総合スペック上位10％の男は除く）」とも言える状況かもしれない。

女性の場合はどうか。これはもうどうしようもない哺乳類の定めというものなのだろうが、容姿や能力がどんなに劣っていても男性と違って「若ささえあれば繁殖のチャンスはいくらでもある」という圧倒的なアドバンテージがある。哺乳類のように生殖の際に適応度を犠牲にするコストに圧倒的な性差がある場合については、コストを払う方の性別は絶対に性淘汰を受けない。

まあ私の場合は育児に掛けるコストが専業主婦の妻よりも多かったりするんですがね（損しかしていない）。

今の若い世代（私も含む）にとっては、「ジェンダー平等」が掲げる内容に女性を有利にするような項目が多く含まれているように感じられ、違和感を覚える人も多いのではないだろうか。

私の理想の男女平等は「体力差を考慮した上で微調整を加えるが、基本的に夫婦、男女の社会や家庭への貢献量を等しいものにし、その報いの過多も性別によって差を設けない」といったところだ。が、無理だろうな。適応度のコスト差によって生じる「選別される側（男）」「選別する側（女）」の立場は絶対に変わることがないだろう。

それはさておき。

命懸けでプレイしなければならない「人生」というゲームにおいて、生まれつきイージーモードのプレイヤーに対して不本意にもハードモードでプレイするはめになったプレイヤーが負の感情をため込むのは自然なことだとは思う。

重要なのはやはりこのシビアなゲームの基本的なルールであるところの「男は選別・淘汰される側、女は選別・淘汰する側」というものにいかに早く気付けるか、だと思う。

女性は結婚適齢期までに「自分は選別する側であるという圧倒的に有利な立場である」ことに気付くことが重要。未婚のシングルマザーになっても今の社会保障制度の下では贅沢しなければ十分に生活できる。多少社会保障にフリーライドする覚悟を決めれば、極めて容易に質の高い子孫を得ることができるということ。

男性はできるだけ早く「選別される側であるという圧倒的に不利なロールである」ことに気付くことが重要。女性から「良い遺伝子を持っていない」とみなされるような外見の場合、人一倍の努力をしなければ性淘汰されてしまうリスクがある。

理想はやはり「万人に完備情報ゲームとして人生をプレイしてもらう」ことだろう。最低限、ヒトにおける性的対立や配偶戦略については思春期を迎えるまでに周知しておくべきだ。

性愛の綺麗事を信じて性淘汰されてしまう純真無垢な男性達をこれ以上見たくはない。

私自身はなんとか社会でうまくやっていける程度の知能と容姿で生まれてきたので、男に生まれてしまったことについては特に不満はない。配偶者の選択に多少慎重さが欠けていたのは否めないが…。

IntelliJ IDEAを使い始めた

Mon, 04 Jul 2022 08:55:01 GMT

IntelliJ IDEAを使い始めた

perlをIntelliJ IDEAで書いてる。Mojoliciousで書かれたプログラムなんだけど、まあ今のところはストレスなくやっていけている。

最初からダークテーマでかなりいい感じ。GitとかTerminal関係のウィンドウも最初からついてる。

.html.epをhtmlとして編集するように設定し、perlのライブラリとしてディレクトリをマークして、perlを書くための拡張機能をインストールすれば概ねOK。

これからバリバリ書くぜ。