サーミローグ初手

前衛スペクター軸

前スペクター補オーキッド医アンセル

最近の個人的なトレンド。分隊選ばず理性ボーナス要求もなく特別昇進に一喜一憂することもない。医療もいてバランスがいい。しかもみんな持ってるでしょ

1層できちんと全員仕事がある上後半腐りにくいのが良い。コストもなんとかなる範囲

初手というか一層に期待されるものって多ブロ群攻かつ耐えられる地上戦力だけどちゃんと満たす。

前衛ガヴィルが使用率高いけどスペクターも充分強い。というか食い縛りをスキルで出せるし昇進でリジェネ入るし扱いやすさはスペクターの方が上まである

分隊はなんでもいいけど前衛分隊が普通に扱いやすい。氷原は地上の需要が結構あるし先鋒にも適用されるのが偉い。イネス5コスで確実に迎えやすいし、希望と召集ダブついても使う先はいっぱいある。ムリナール特別昇進とか来たら大興奮

特殊分隊でも良い。特殊テキサスやヤトウなんて初手で扱うのめんどいけど、強いから欲しいし特殊も術師も高難度で使いたいオペレーター多いので、序盤はスペクター後半は特殊術師と綺麗に進行できる

少なくとも昇進2前提のソーンズより使用率高くていいと思う

サーミローグ

雪原から出られません

猛威13クリアして分隊使用感調べるため猛威12End1クリア埋め中

システムは統合戦略最高

本当に素晴らしい。#2、3の不満点を解消しつつゲームシステムの幅を増やしている

マス操作(啓示)

進行するマスを変えたりボーナスを得たり。低難易度は救済で、高難易度は前提になる良い要素

エンド分岐に統合されてるのも良いところで、End2、3のために非戦闘マス片っ端から入ってガチャる必要なくなり、目的のエンドに対応したマスをちゃんと踏めば選べる。神。最高。

階層が少し短くなった

各層の最短マス数が若干減ってる?

縦移動要素あるし長くいようとすれば前より長くできるけど、1プレイの時間が短くなって遊びやすくなった。1時間切りまくり

耐久値ペナルティ廃止

先鋒分隊が使いやすく。というか耐久値もすぐ戻せるしほぼノーペナ分隊になった

海の耐久値減った瞬間ペナルティがめっちゃのしかかってくる調整、フレーバーはよかったけどゲーム的にはストレスだったので良い

ペナルティ要素が柔軟に

ペナルティを解消したりできる。解消について緩和しすぎかもとは思うけど、耐久値減っても即座にやる気無くならないので良いかな

マス選択のゲーム性向上

海であった縦移動がコスト緩和で行いやすくなった上、マスの可視範囲が取っている数値によって変わったり啓示をどう使うか、それを見越してどのルートを取るべきかなど遊びの幅が広くなった。ほんと楽しい

難易度バランスは惜しい

古城ライク。序盤むずい系

海は階層進むごとに難しくなって5層は絶望感あるステージばかりで緊張感すごかったけど、雪は1層からそれなりに難しくて運ゲーにもなる

そのうえ基本的に3層がピークでそこを抜ける戦力が出来てればなんとかなる。逆に絶望ばかりだった海5層と違い雪5層は絶望的なステージは今のところそんなない。音楽強襲が結構きつい印象くらい

海の難易度は緊張感あって進むごとにドキドキして良かったから、雪もそんな感じであってほしかった

いきなり合計4ブロと回復、火力全てが欲しくなる1層の獣の群れマジで許さんからな

破壊戦術が強く感じる

今のところ初手フェンクルース特殊テキサスの編成が安定しやすい。獣の群れ以外の1層ステージはまず行けるし2層以降もアドリブが効く

そのためこの編成を安定して使える破壊戦術や支援分隊が使いやすい

星5以下スタートするなら寒クルースやカニパラートとかジェイなど強いオペいるけど、安定性で言えば特殊テキサス隊になる。Rヤトウは昇進2の対応力や操作のめんどさで優先度落としてる。

ビーントークスタートもやってみたけど、フィジカル欲しい今回あまり良くはない。ジェイ君は1ブロ以外めっちゃ強い、なんなんだこいつ。実装当時から弱かった時がない

イネス最強

実質ブロック数が多すぎる

コスト増やせるって意味でもめっちゃ強くて、ティアランク作ったらティアテキサスの下にティアイネスがあるレベル

神髄壺識別

目指せ2時間切り。そのためのまずは2時間30分切り。現状2時間47分

期待したい壺

保存、強化

次点で合成

次次点で識別、お祓い

他は割とどうでも良い。保存強化見えたら識別終了して他無視あり

ロスト受け入れ未識別装備入れスタート基本

未識別を入れることで識別、保存、お祓い、呪い、変化、やりすごし、底抜け、手封じまでわかる

識別は入れたらわかる。保存は取り出せるか、お祓いは?マークが消えるか、呪いはマーク有無、あとは見りゃわかる

適当な装備入れて確定させる

合成されたら合成。されなかったらただ壺か割れない壺

合成されたら名前つけて、されなかったらただって名前つけて壁に投げて割れたらただ壺、割れなかったら割れない壺

容量4以上ならこれ以上の識別は要らない。3以下はそもそも強化を期待する事

容量3以下なら強化期待

期待して良い。識別済み装備入れて1階層降りて見てみる

容量2は強化激アツ

余裕で弱化の場合もあるんでかまいたちとか絶対入れたい系装備入れないこと(n敗)

ロスト壺警戒

具体的には変化、底抜け、割れない

この3つ見えてれば割と強気に合成期待メイン武器投入あり

壺識別は簡単だしすぐ終わる上リターンデカいの多いから速攻で識別して活用したい

2週間前の自分は識別期待して選択巻物使うとかほざいてた。エアプだろこいつ

神髄

識別と狙うアイテム

巻物

階段上で読む。裏目としてくちなしモンハウあるけど識別メリットのがでかいので階段上で真っ先でいい

白紙がたくさん出るのでそこまで拘らなくていい。今作は数値が強いので強化巻物取れたら嬉しいな、道具よせや困った時、あかりとれると節約できていいな感

選択巻物はおにぎりと識別が判別できてるか覚えとく。呪いとかもキツいけどおにぎりが一番危ないしほしい

選択は人によるけど低層で識別が出るまでは壺>草>余った武器盾、識別でたら余った武器盾に使う

呪いとおにぎりが裏目で強化が潰れたら落ち込むけど低層だろうしリターン重視でいいと思う

武器盾に恵みメッキ入ったら合成素材として美味しいので嬉しい

「入れる」選択だけして入れないで店識別や識別巻物まで粘る

強化、保存、合成が狙い目。嬉しいのが識別やおはらい、危険なのが底抜け系や変化、換金、割れない壺などロスト系

保存含めて狙い目アイテムが出にくく容量も潰したくないのと、アイテムロスト系の裏目が危険、値段識別が容易、店が結構出るので漢識別はまずしない。

「入れる」選択すればやり過ごし判別できるのでそれだけやっとく

出来れば店したいけどそうも言ってられないのでHP満タン飲み識別。割とすぐで良い

狙い目は力、復活、幸せ、天使、無敵、命などHPアップ系、異種合成用の目潰し、混乱、睡眠

出る数が大く店識別で完全に識別出来ないのも多いので飲んじゃう方がいい。低層なら異常草や不幸のデメリットもまだマシ

一番危険なのが暴走。洞窟マムル作成に使えるけど店で雑飲みして店主殴ったらゲームオーバー(1敗

値段被ってるのも多いけどキーアイテムの草は割とユニークなので店見えたらできるだけ持っていく。重要な値段は以下。70はわざわざ買ってまで飲まなくて良い。50はわかったら飲まない。200は人による。裏目1/4かつ胃縮小だから飲んで良いと思う

  • 薬草 40/34 10
  • 毒草、暴走 50/43 20
  • 弟切草 80/69 30
  • 命 500/435 200
  • 力 700/609 280
  • 毒消し 600/522 240
  • 復活、無敵、不幸 400/348 160
    • 復活飲みが勿体無いので識別アイテムまで待つ
    • 200の祝福の可能性もある
  • 幸せ 1000/870 400
  • 天使、超不幸 2000/1740 800

異種合成の草は10-30Fで再度拾えることが多いし最初は盾の修正値が欲しいのでそんなにキープ狙わなくて良い。効果永続の目潰しや一方的に叩ける眠りはもちろん入れたいから30Fまでに再度探しはする

盾印が割と余裕あるので命印を入れても良いけど優先度低い。HP20は微妙に低い。

雑振り。幸せケアで出来れば洞窟マムルや対処アイテムの準備はしたい

導き、金縛り(武器合成)、吹き飛ばし、場所替えとかほしい

武器盾

雑合成。呪われても白紙から恵みやらやれば良いし。修正値重要

特攻付きとか売値高いの多いから枠余ったら持ってて良い

腕輪

おすきに

腕輪識別はノリと慣れと好み

稼ぎフロア

1-3

洞窟マムル狙い低層。一応8Fでもテーブルにはいるけど狙うほど高くないと思う。おにぎり稼ぎはしない派

5-8がクソ火遁忍者フロアで粘る価値ないので洞窟マムルはマジで狩りたい

10-30

マゼルンが出てくる、が、こだわらないこと

出現率が高くないうえそもそも強め(25F相当のスペック)だし長く出るのでそんなこだわるべきじゃない。ついでくらいの気持ちでいい

40Fでマゼモン合成無限にできるし

10n階層

道具よせでアイテムを集める階層。魔物部屋よりこっちのがいい

白紙使ってでも道具よせする。帰ってくることも少なくない

10-12

矢稼ぎ。めんどいけどやった方がいい

ボウヤー、クロスボウヤーで矢稼ぎできる。3束くらいあればまず困らない。現実150くらい(みかわし香1個分)でも割といける。連射腕輪で行くならここでしっかり稼ぐべきかも

13-15

マスチキで経験値400。30Fまで経験値美味しいフロアないので粘っていい。 ミドロもいるからメッキが欲しい。粘ってると修正値が削られる。

マスチキ自体は18Fまで出るけど大根、トド、クソ親父戦車や山伏が出ることや出現率的にもこの3フロアが目安

30F(マゼルン終了)

稼ぎってわけじゃないけど覚えておくべきフロア。30-39が粘るべきじゃないので目安として稼ぎ終了と覚える

40-42

タベラレルーマゼモン洞窟マムル

神フロア。オヤジ戦車を根絶やしたら稼ぎモンスターしかいない。深層に向けてここで稼ぎ切る。

あかりや気配察知を用意すること。どうせこのあとは即降り

マークダウンをマージするときに書いたスクリプト

以下みたいなフォルダ構造

├─1.intro
│      1.hello.md
│      2.motivation.md
│
├─2.about
│      1.notice.md
│
├─3.main
│      1.wao.md
│      2.amaging.md
│      3.foo.md
│
└─4.fin
       1.bye.md

スクリプト

cat /dev/null > merge.md

ls -d [0-9]*/* |  xargs -I{} awk 1 {} >> merge.md

リザルト。##部分=ファイル名という感じ

## hello
// ReviewMe:気の利いた挨拶
## notice

// ReviewMe:いい感じに注意
## wao
## amaging

// ReviewMe 感動的すぎないか?




// ReviewMe もっと感動的すぎないか?
## foo
// ReviewMe barbaz
## bye

awk 1がおしゃれポイント。これあると末尾改行じゃなかったら勝手に改行にしてくれるらしい。cat結合よりこっちのほうがよくない?

xargsの-I{}老害ポイントかもしれない。今時の若いもんはこうしないとかなんとか。そんなことない説もある

.gitlab-ci.ymlをincludeキーワードでモジュール化する

gitlabのciを構築するyaml構文にはincludeキーワードで、ほかのyamlを利用することができる

docs.gitlab.com

挙動としてはCのincludeとほぼ同じで、指定したyamlの内容テキストを指定元のyamlにコピーする形。そのため変数の値は展開されず変数定義がコピーされてコピー後に評価される。include参照先のプロジェクト変数を参照してるyamlをincludeしてもプロジェクト変数は持ってこられないんじゃないかな。調べる。

これ使ったら.gitlab-ci.ymlの記述を共通化するためのユーティリティプロジェクト作って、それで省力・共通化できんじゃね?って思ったので調べる

ユーザー名jump24dでプロジェクト名がgitlab-ci-utilityだからそこは適宜自分のに置き換えて読むこと

目的

テスト実行など、よく使うyamlパターンを自作テンプレートプロジェクトに保存して、それを複数プロジェクトでincludeすることでテスト機能を実現する

今回のテスト実行は以下の機能を備える。include先で各機能が実現できたらOK

  • npm testを行えること
    • 行う内容は各プロジェクト依存
  • テスト結果をgitlabのtestタブに表示すること

できればAllure Reportもやる

  • テスト結果をAllure ReportとしてGitlab Pagesに出力する
  • テスト結果を保存して、次回以降履歴として保存できる
    • 履歴を保存するブランチをinclude先で指定できるかしらべる
  • 履歴を持つAllure Reportを出力する

とりあえず簡単に試す

ユーティリティプロジェクトyaml

ファイル名はplaywright.test.ymlとした。一応gitlabのtemplateプロジェクトの命名が参考元 プロジェクト名はjump24d/gitlab-ci-utility

stages:
  - test
  - allure
  - deploy

.download_history:
  after_script:
    - apt-get update
    - apt-get upgrade -y
    - apt-get install -y unzip
    - mkdir backup && cd backup || true
    - "curl --location --output report.zip --request GET \"https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/jobs/artifacts/main/download?job=pages\" --header \"Authorization: Bearer ${CI_DEPLOY_TOKEN}\" || true"
    - (unzip report.zip) || true
    - cd ../
    - (cp -r backup/public/history/ allure-results/history) || true

.test_template:
  allow_failure: true
  stage: test
  image: mcr.microsoft.com/playwright:v1.41.2-jammy
  script:
    - npm install @playwright/test
    - npx playwright test
  artifacts:
    when: always
    paths:
      - allure-results/
    reports:
      junit: results.xml

smoke:
  extends: 
    - .download_history
    - .test_template

allure_report:
  stage: allure
  when: always
  image: timbru31/java-node
  dependencies: 
    - smoke
  script:
    - npm install
    - npx allure generate #change allure command specific to your framework
  artifacts:
    when: always
    paths:
      - allure-report/
      - allure-results/
  only:
    - main
  
pages:
  stage: deploy
  when: always
  dependencies:
    - allure_report
  script:
    - mv allure-report/ public/
  artifacts:
    paths:
      - public
    expire_in: 30 days
  only:
    - main

includeする側yaml

include:
  - project: 'jump24d/gitlab-ci-utility'
    file: 'playwright.test.yml'

は?ってなるくらいincludeする側yamlが少ないけど、実際こんなことできちゃった

完全な設定yaml

includeする側yamlのプロジェクトのパイプラインエディタに「完全な設定」ってタブがあって、そこでマージ後のプレビューがみられる様子。上二つからは以下ができる。

---
stages:
- ".pre"
- test
- allure
- deploy
- ".post"
".download_history":
  after_script:
  - apt-get update
  - apt-get upgrade -y
  - apt-get install -y unzip
  - mkdir backup && cd backup || true
  - 'curl --location --output report.zip --request GET "https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/jobs/artifacts/main/download?job=pages"
    --header "Authorization: Bearer ${CI_DEPLOY_TOKEN}" || true'
  - "(unzip report.zip) || true"
  - cd ../
  - "(cp -r backup/public/history/ allure-results/history) || true"
".test_template":
  allow_failure: true
  stage: test
  image: mcr.microsoft.com/playwright:v1.41.2-jammy
  script:
  - npm install @playwright/test
  - npx playwright test
  artifacts:
    when: always
    paths:
    - allure-results/
    reports:
      junit: results.xml
smoke:
  after_script:
  - apt-get update
  - apt-get upgrade -y
  - apt-get install -y unzip
  - mkdir backup && cd backup || true
  - 'curl --location --output report.zip --request GET "https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/jobs/artifacts/main/download?job=pages"
    --header "Authorization: Bearer ${CI_DEPLOY_TOKEN}" || true'
  - "(unzip report.zip) || true"
  - cd ../
  - "(cp -r backup/public/history/ allure-results/history) || true"
  allow_failure: true
  stage: test
  image: mcr.microsoft.com/playwright:v1.41.2-jammy
  script:
  - npm install @playwright/test
  - npx playwright test
  artifacts:
    when: always
    paths:
    - allure-results/
    reports:
      junit:
      - results.xml
  extends:
  - ".download_history"
  - ".test_template"
allure_report:
  stage: allure
  when: always
  image: timbru31/java-node
  dependencies:
  - smoke
  script:
  - npm install
  - npx allure generate
  artifacts:
    when: always
    paths:
    - allure-report/
    - allure-results/
  only:
  - main
pages:
  stage: deploy
  when: always
  dependencies:
  - allure_report
  script:
  - mv allure-report/ public/
  artifacts:
    paths:
    - public
    expire_in: 30 days
  only:
  - main

一応スクショ

ユーティリティプロジェクトの設計事項

include:project想定 公開するのはprojectパス、ブランチ、ファイル名

ブランチじゃなくてコミットハッシュでも良いんだけど流石にブランチ

ユーティリティプロジェクトの公開範囲は基本社内、同じGitlabインスタンス内でプロジェクトを公開できる相手になると想定する。その場合 include:projectで使ってくださいね案内になると思う。

Includeする時指定するのが節の三つ。ブランチは省略可能で省略した場合はHEADらしい。GitlabのHEADってどこ?

バージョン戦略する意味あるか知らんけど、安全にためにrefはmain使ってくださいね。くらいはやっても良いんじゃないだろうか

Project、グループ名、ブランチ名、ファイル名はPublicになるから基本変えられないよ、と覚えとく

remote公開ならファイルの絶対パス公開

もし社内公開とかじゃなく自作ツールをCICDで使ってもらう時のテンプレート公開とかならinclude:remoteで使われることを想定

その場合基本的にGitlabで表示されるそのファイルのURLを公開することになる。詳細は以下

docs.gitlab.com

個別プロジェクト

各includeファイルの内容を把握しておく

複数includeとか個別側に書いたのとかで定義被ったら後勝ちになるから、どこで何が入るか全部抑えないといけない事を意識すること。includeって参照じゃなく全コピペしてるのと変わらないから

GitlabのWebパイプラインエディタ機能で完全な設定タブを何回も見るのがいいかも。ここが一番わかりやすい

基本はinclude:project

基本これで使う。参照するものはユーティリティの方参照

include:
  - project: 'jump24d/gitlab-ci-utility'
    file: 'playwright.test.yml'

変数やscriptの上書き

個別プロジェクト側でincludeしたファイルのyamlキーと同じ項目を書くことで、上書きできる

つまり

include される側

.download_history:
  after_script:
    - apt-get update
    - apt-get upgrade -y
    - apt-get install -y unzip
    - mkdir backup && cd backup || true
    - "curl --location --output report.zip --request GET \"https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/jobs/artifacts/main/download?job=pages\" --header \"Authorization: Bearer ${CI_DEPLOY_TOKEN}\" || true"
    - (unzip report.zip) || true
    - cd ../
    - (cp -r backup/public/history/ allure-results/history) || true

.test_template:
  allow_failure: true
  stage: test
  image: mcr.microsoft.com/playwright:v1.41.2-jammy
  script:
    - npm install @playwright/test
    - npx playwright test
  artifacts:
    when: always
    paths:
      - allure-results/
    reports:
      junit: results.xml

smoke:
  extends: 
    - .download_history
    - .test_template

する側

smoke:
  script:
  - echo "override this!"
  - npm install @playwright/test
  - npx playwright test
  - echo "fuhahahahah!"
  - echo "Yatta!"

完全な設定yaml

smoke:
  after_script:
  - apt-get update
  - apt-get upgrade -y
  - apt-get install -y unzip
  - mkdir backup && cd backup || true
  - 'curl --location --output report.zip --request GET "https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/jobs/artifacts/main/download?job=pages"
    --header "Authorization: Bearer ${CI_DEPLOY_TOKEN}" || true'
  - "(unzip report.zip) || true"
  - cd ../
  - "(cp -r backup/public/history/ allure-results/history) || true"
  allow_failure: true
  stage: test
  image: mcr.microsoft.com/playwright:v1.41.2-jammy
  script:
  - echo "override this!"
  - npm install @playwright/test
  - npx playwright test
  - echo "fuhahahahah!"
  artifacts:
    when: always
    paths:
    - allure-results/
    reports:
      junit:
      - results.xml
  extends:
  - ".download_history"
  - ".test_template"

出力

$ echo "override this!"
override this!
$ npm install @playwright/test
added 9 packages, and audited 10 packages in 2s
found 0 vulnerabilities
$ npx playwright test
Running 6 tests using 1 worker
······
  6 passed (9.8s)
$ echo "fuhahahahah!"
fuhahahahah!
$ echo "Yatta!"
Yatta!

完全な設定yamlのsmokeのscriptが見どころ。確認用のechoが足されてる

javascriptか?ってなるくらい上書きしてる。

これのおかげで実際枠組みを提供しつつ実際のテスト実行コードはプロジェクトごとに変えられるから便利な挙動。実質strategyパターン

template

include:templateは以下のプロジェクトのyamlをコピーできるらしい。使うのがありそうか調べる

gitlab.com

一応パイプライン画面とか

ちゃんとパイプライン動いてAllure Reportも履歴取れた。

ちゃんと

JUnitビューもできてる

注意点

ジョブの再実行時、include対象は再取得されない。けどパイプラインの場合はされる

ジョブとパイプラインそれぞれの実行単位で挙動が違う

要はパイプラインから実行しないとパイプラインの評価とジョブ実行しないっていうか実装優先の仕様というかほぼ挙動だと思う。

ジョブ単位の実行の場合は再生成せずその時作成されたインスタンスで再度実行されるイメージ。

「直したんで再実行してくださいね」でジョブの再実行しても無意味。新しくパイプラインから再実行でないとinclude先の変更は反映されない。

人に見せる記事はAIで書く時代

収益化を目的としていない個人ブログなんてクソみたいな散文で構成されます

こんなん読みづらいんで人様にお出しできないんですけど、技術記事くれとかなった時お出しするためのメモ

なぜ読みづらいか

そもそも対象読者が記事書いた人本人で、第三者に物事を伝える気がない

このブログなんかそうなんだけど、あれなんだっけなって時に読み返してあーってなりゃいいから情報が断片的になってます

言葉遣いもよろしくない。別に乱暴じゃないけどですますだったりいきなり感情こもったりテンションでメモ書いてるから見返して恥ずかしくなる

この問題を自覚して恥ずかしくならないように書きゃいいんだけど、技術調査ついでに書いてるメモにそんなエネルギー注いでらんねえから無理です

生成AIにリライトしてもらう

生成AIは具体的にChat GPT 3.5とします。理由は使ってるから。すごいよテキストボックスに「技術記事にしてくれ」みたいないことと背景とブログ全コピペで良い感じにリライトしてくれる。

メリットは以下

誤字脱字修正

個人ブログなんて推敲されません。句読点はクソ適当だし変感は見てないから間違いまくってるしコピペしてお出ししたら凄いことになります

びっくりするほど治る

丁寧な文章

適当な散文は「クソ」とか「やめてくれ〜〜〜」「きちぃー」「何をしても良いと思ってる」みたいな人にお出しできるわけない言葉で構成されます。

びっくりするほど綺麗な表現にしてくれる。めっちゃ読みやすい。

見出しの設定

これ記事にある程度作ってるおかげかわかんないけど、なんか良い感じの見出し作ってくれる

いらん情報を削ぎ落とす

技術メモの散文にあがりがちな「すごいよ」「クソだる」みたいな人にお出しするには不適切な情報をカットしてくれる。

どれだけ感情こもった読みにくいし明らか要らんとこはAIが消してくれるんで精一杯適当に書ける。

2000文字のクソ文がスッキリした800字になったりする

良い感じに序文を足す

技術メモの体裁を整えるだけだと技術記事には成りづらく、その理由として導入が無いことがほとんど

目的持って見に来てれば要らないんだけど、技術記事の場合どういう記事ですよって序文が欲しいんです。メモなら要らないんだけど

AIはいい感じの序文を書いてくれる。めっちゃ定型文くさいんだけど、わかりやすいからこれが良いのかってなる。導入でなんか上手い事言おうとしてる文書って読む時胃もたれするから定型文が良い。

人に見せる記事に魂は込めすぎない方がいい

魂っていうか熱量。こもった記事は読みづらい。ブログに限らないけど書く側話す側と読む側聴く側のテンションは全然違う。

書く側話す側は気持ちよくなってくるし時間もかけてるから熱量上がるけど、読む側はテンション0で頭1行でやめたり読み上げソフトで聞き流したりする。

冷静に振り返るとブログ軽く10秒足らずさっとみてやめる事なんて腐るほどあるし、YouTubeの動画2倍速で再生して途中でやめたりBGM的に流したりなんて全然あるでしょ。読む側なんてそんなもん

思想強めに感じる文章とか最初見てやめとこってなるでしょ。動画だとさらにそう。冒頭のテンション自分と合わないなとか、そんな理由で見るのやめた動画とかいくらでもあるでしょ。魂ないゆっくり音声聴きやすいでしょ。そんなもん

その点AIはすごい。いい感じにクールダウンした文章を出してくれるし、改めてその文章読むと書いてる側も良い意味で冷める。

AIにぶつけて記事を冷ます

というかAIが良い感じに冷ましてくれた記事を公開で全然良いよ。魂込めれば込めるほど大衆向けじゃなくなるし、コア向けにしたところでそのターゲットはほぼいないだろうし、いたとしても技術記事提供した先から交流できるか、なんか良いフィードバックあるかと言ったら期待値激低だから、冷ました物の方が良い

ようしらん他人からありのままの感情をぶつけられても困ることを考えると、AIに間に入ってもらうのは合理的なのかもしれない

人にぶつける前にAIにぶつけよう

AIに頼り切る不安を解消する説得みたいな文になった。実際この記事の目的は自分へのそれかもしれない。

余談

これ冷静に考えるといかがしたかブログ推奨してる記事になってる?ネットのクソを肯定してしまってる?

海軍レーダー徒然草とかそういうページが増えて欲しいとは思ってます。面白いのは魂こもった大衆気にしない記事だとは思う