I/O - はてな匿名ダイアリー

しかも笑えるのは、そういうやつほど「俺はリアリスト」「世の中を俯瞰してる」とかドヤ顔。いや、俯瞰じゃなくて単なる未接続。API叩いてもないのに「データが無い」って言ってるのと同じだ。普通なら興味を持てる情報がキャッシュされるのに、「全部」って極論で切り捨てるのは、ただのI/O エラー。アルゴリズムじゃなく端末側のハード障害だ。

現実もメタバースも常に面白さをストリーミングしてる。でもお前の受信機は老朽化、感受性 GPUは焼き付き、アップデート拒否中。だから退屈に見えるだけ。つまらないのは外部じゃなく、お前のOSとハードウェアだ。そして残酷に言うと――つまらないのはお前自身。

再起動してパッチ当てろ。世界は面白さで溢れてるのに、体感できないのはお前のクライアントが死んでるからだ。クラウドは常に稼働してる。アップデート拒否の端末が不平を言うな。Life OSのログを見ろ、エラーコードは「お前自身」だ。

Permalink | 記事への反応(1) | 22:20

■

セキュリティアップデートが原因って言ってたのはなんだったのｗ

正直これもこじつけに近いな

XP から Vistaになったときにコピーが遅くなったって喚いていて原因はXPの時はコピーが完了する前にダイアログを閉じていたってやつだったけど

Windows11：24H2におけるSSDの損傷問題について、結論＆全解明です。FromHDDtoSSD 統計スキャンによる測定結果より、原因判明しました。完全にドライブ I/Oのタイミングが常にずれてい｜猫がみる真実

https://note.com/fromhddtossd/n/nd3888c34b108

Permalink | 記事への反応(0) | 18:33

2025-09-03

■dorawii@執筆依頼募集中

話を逸らす前に聞いてほしいんだけど、経緯に個性あり、なことは認めますね？

Permalink | 記事への反応(1) | 13:59

2025-08-27

■anond:20250827202657

まあ任天堂とかハドソンソフトとかセガとかスクエニとかHAL研とかの創業期の人達はきっとI/Oとかマイコンとか読んでたと思うので月に到達したといってよいのでは。

Permalink | 記事への反応(0) | 20:34

■てか、I/Oのバックナンバーをインターネットアーカイブにアップロードしている人がいるのか・・・

ありがたすぎるけどいろいろ大丈夫なんだろうか

https://archive.org/details/Io197611-19772

Permalink | 記事への反応(5) | 19:49

2025-08-21

■dorawii@執筆依頼募集中

自動ブクマするローカルサーバーとかの構成を作った。

ブクマには↓のサブアカを使用

https://profile.hatena.ne.jp/dorawii_bukuma/

はてなのサイト側で読み込まれているはずのrksトークンを生成する関数を直接叩く方法がどうしても分からず結局request処理を自分で書く方法ではなく自動でUI側の保存ボタンをクリックするという無難な方向に落ち着いた。

最初から後者の方法をとっていればもっと全然早く作れたのにというは所詮言い訳か。

とにかくスクリプトを公開しておく。

start-server.bat

@echo off
cd /d "C:\Users\user\Documents\jsscript"

:: Nodeサーバーを別ウィンドウで起動
start /min "" node run-batch-server.js

:: Pythonサーバーを別ウィンドウで起動（hatenaserver配下）
start cmd /k "" python hatenaserver\server.py

以降はjsscript直下に配置

config.json

{
  "username": "",
  "password": ""
}

server.py

from flask import Flask, request, jsonify
import json
import os
from hatena_client import HatenaClient
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

config_path = os.path.join(os.path.dirname(__file__), 'config.json')
with open(config_path, encoding='utf-8') as f:
    config = json.load(f)

@app.route('/bookmark', methods=['POST'])
def handle_bookmark():
    data = request.json
    url = data.get("url")
    if not url:
        return jsonify({"error": "Missing URL"}), 400

    client = HatenaClient(config["username"], config["password"])
    client.start_browser()

    if not client.login():
        client.quit()
        return jsonify({"error": "Login failed"}), 403

    success = client.add_bookmark(url)
    client.quit()

    return jsonify({"status": "ok" if success else "fail"})

if __name__ == "__main__":
    app.run(port=12347)

あとはグリモンにユーザスクリプトとして書くやつ

// ==UserScript==
// @name         自動セルクマ送信
// @namespace    tampermonkey.net/
// @version      2025-08-07
// @description  try to take over the world!
// @author       You
// @match        anond.hatelabo.jp/*
// @grant        none
// ==/UserScript==

(function () {
    'use strict';

    const url = location.href;
    if (!/^https:\/\/anond\.hatelabo\.jp\/\d+$/.test(url)) return;
    const editLink = document.querySelector('a.edit');
    if (!editLink) {
        // 既に編集ページなので処理をスキップ
        console.log('編集リンクが存在するため、スクリプトを終了します。');
        return;
    }

    fetch('localhost:12347/bookmark', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify({ url: url })
    }).then(r => console.log("通知成功")).catch(e => console.error("通知失敗", e));
})();

Permalink | 記事への反応(1) | 19:27

2025-08-15

■anond:20250814173040

同じプロンプトを俺のChat GPT55 thinkingにぶっこんらこうなった

`

GPT-5は何故重要なのか

長文。観測範囲の話。話半分で読んでほしい。

でも、黙っているとますます状況が悪くなる気がしたので書く。

結論（先に）**

GPT-5は重要だ。''なぜなら「壊れている」から''だ。

もっと正確に言えば、AI アプリケーションの''部品として使うと壊れ方が目立つ''。そして、その壊れ具合に対して''公開の場で指摘する人が驚くほど少ない''。この沈黙こそが、いまの“AI プロダクトを作っています界隈”の実態を映す鏡になっている。

壊れ方の具体（私の観測 範囲）**

''tool callの性能が著しく低い''

期待するツール実行をスキップしたり、呼び出し順が崩れたりする。「実行した」と言いながら実行していないケースも混じる※1。

''非協調的なふるまい''

指示に対して過剰防御や論点すり替えが起き、対話が前に進みにくい。

''無限ループや出力崩壊''

失敗からのリトライで同じ失敗を繰り返し、最終的に出力が壊れる。

''公式/非公式の“システムプロンプトガイド”を適用しても復旧が難しい''

プロンプトの衛生管理を頑張っても限界が見える。

''GPT-4.1からの置き換えで単純劣化''

同一テストスイートで回すと、通っていたE2Eが普通に落ちる（少なくない）。

ここで言っている「壊れている」は''API 連携の部品として''の話だ。お絵描きや雑談がダメという意味ではない。''“製品の裏側で回す部材”として危うい''という指摘。

> ※1 もちろん、プロンプトやミドルウェア側の実装不備が誘発している可能性もある。ここは後述の「反論と限界」を参照。

なぜそれが「重要」なのか**

普通、現場でAI アプリを作っている人は、新しいメジャーモデルが出たら''一晩でCanary切り替え''くらいはする。

そして10分で「これは本番に入れちゃダメな挙動だ」と分かる類の壊れ方が、今回多発した。''それなのに、表でそう言う人が少ない。''

この''“沈黙”自体が強いシグナル''になっている。

実は''本当にプロダクトを作って回している人が少ない''。
もしくは''PoC止まり''で、本番のSLOや回帰監視がない。
あるいは''マーケの都合やNDA''で言えない（が、なら内輪では警告がもっと回るはず）。

どの仮説でも、結論は同じだ。''「作ってません（作れてません）」が可視化された。''

そういう意味で、GPT-5は''最悪の壊れリリース''であり、同時に''最高の暴露リリース''になった。

よくある反論と、その限界**

''「お前のプロンプトが悪い」説''

それは常に真。だが''同一テスト''でGPT-4.1が安定し、GPT-5で落ちるなら劣化は劣化。

''「まだローンチ直後（調整中）」説''

ありうる。ただし''現場は“直後”でも回らないと困る''。リリースの意味は環境に依存しない。

''「API ラッパー/ツール実装側が未対応」説''

これもある。が、''その段差を埋められない程度の変更は業務影響が大きすぎる''。

''「ネガティブを言うと燃えるから黙る」説''

それはネットの事情。でも''内部の安全弁（アラート、Kill Switch、ロールバック報告）が表に出ない''のはやはり不自然。

''「実は皆、使っていない（要らなかった）」説''

これが一番効く。もしそうなら、''“AI プロダクトを作っています”の大半は広報レベル''ということになる。

では、開発者はどうするべきか（実務メモ）**

''回帰テストを“会話込み”で自動化''

E2Eに''ツールコールの監査ログ''（実行/未実行/戻り値）を必ず残す。

''Canary & Kill Switch''

バックエンドの''モデル切替を即時に戻せる''ように。手動トグルと自動フェイルオーバー両方。

''観測可能性（Observability）''

LLMの''失敗モードをカーディナリティ低めのタグで集計''（“未実行なのに実行報告”“ループ検知”“出力崩壊”）。

''プロンプト契約（Prompt Contract）''

''ツール I/Oのスキーマを明文化''し、破ったら''ハードFail''させる。中途半端に続行しない。

''人間の最後の砦''

本番系で''危険操作はHuman-in-the-Loop''。モデル更新時は''影で並走''させて勝率を測る。

''広報より先に“不具合ノート”''

社内/社外問わず、''再現条件と緩和策を先に出す文化''を。

まとめ**

GPT-5は''部品として壊れている側面が目立つ''。
それにもかかわらず''公開の指摘が少ない''。
この沈黙が示すのは、''本当に作って回している人が少ない''という不都合な真実。
よってGPT-5は、''最悪の壊れリリース''であり、''最高の“現実検出器”''でもある。

壊れていること自体は困る。だが、''壊れているときに世界の輪郭が見える''のもまた事実だ。

この機を逃さず、''テスト・観測・切替・公開''の体制を整えるしかない。

----

追記（FAQっぽいもの）**

''Q. じゃあGPT-5は使うべきでない？''

A. ''今この瞬間に“中核部品”として置き換えるのは非推奨''。並走・影運用で勝率を測るのが堅い。

''Q. 特定のユースケースなら強いのでは？''

A. ありうる。だが''tool callが絡む業務連携''では痛手が出やすい。スタンドアロン用途と切り分けて評価を。

''Q. そのうち直るよね？''

A. 直る可能性は高い。ただし''“直るまでの損失”を最小化する設計''はあなたの仕事。

> 以上、個人の観測と推測に基づく意見。反証歓迎。再現ログを持っている人はぜひ出してほしい。ログが集まるほど早く“壊れ方の型”が固まって、世界は前に進む。

天然知能の感想

無茶苦茶ハルシネーション起こしてる。なんだこれ。

Permalink | 記事への反応(0) | 16:38

2025-06-20

■dorawii

俺の住所がわかったとか言ってる奴には否定する奴がいない。普通の文脈なら妄想だろうと冷やかされる増田がわんさか出てくるような言動なのにだ。

これでわかることだがようはお前らはお手軽に勝ち馬に乗れる方に流れようとするらしい。

つまり奴を叩いても奴に叩き返されるリスクが生じるだけなのに対し、俺を敵だと思っている人は多いからとりあえず都合の悪い人間がいるのは無視してでも俺を叩いとけば形勢は有利を維持できるから。

安直な人間だったんだなお前ら。

Permalink | 記事への反応(3) | 16:55

2025-06-17

■早寝する技術　―持続可能なパフォーマンスを実現するスリープ マネジ

TL;DR

日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。

はじめに：なぜ我々はwhile(true)な夜を過ごすのか

我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。

「あとちょっとだけ、このバグの原因を調査したい」

「リファクタリングが楽しくなってきた」

「面白い技術記事を見つけてしまった」

これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。

アンチパターン：早寝を妨げるBlockerたち

早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。

Blocking I/Oとしてのスマートフォン:

就寝前のスマートフォンは、まさに同期的なブロッキング I/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。

Cacheされた覚醒状態:

深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -h nowを叩いても、プロセスが終了しないのだ。

誤ったDependencyの注入:

「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。

Cronの不備:

不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。

Sleep as Code: 早寝を実現するためのプラクティス

では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleep as Codeの概念に基づき、具体的なプラクティスを紹介する。

1. 環境のIaC (Infrastructure as Code)

睡眠環境をコード化し、常に理想的な状態を維持する。

光の制御: 寝室は完全なダークモードに移行させる。遮光カーテンの導入は必須packageだ。また、夜になったらf.luxやNight Shiftを自動実行し、ディスプレイからのブルーライトというdeprecatedな光を排除する。
音の分離: 外部のノイズというinterruptを遮断するため、耳栓やホワイトノイズマシンを導入する。これにより、睡眠プロセスは他のプロセスから隔離されたsandbox環境で実行される。
温度・湿度の最適化: PrometheusとGrafanaでサーバーの温度を監視するように、寝室の温度と湿度も最適値（一般的に温度は18〜22℃、湿度は40〜60%）に保つ。スマートリモコンによる自動化を検討しよう。

2. 就寝CI/CD パイプラインの構築

毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。

Trigger (トリガー): 「22時になったら」など、就寝の1〜2時間前にパイプラインを起動するアラームを設定する。
Build (準備):

- PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。

- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。

Test (静寂):

静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。

ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。

Deploy (就寝):

すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgit clean -fdで強制削除し、呼吸に集中する。

3. MonitoringとRefactoring

睡眠の可視化: スマートウォッチや睡眠トラッカーを導入し、睡眠時間、深さ、周期といったmetricsを収集・可視化する。
ポストモーテムの実施: 「なぜ昨晩は寝付きが悪かったのか（incident）？」その原因（root cause）を特定し、対策を講じる。

例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」

A/Bテスト: 早寝のための施策（アロマを焚く、寝る前の音楽を変えるなど）を試し、睡眠スコアの改善度合いを計測する。効果的な施策をmasterブランチにマージしていく。

まとめ：早寝は未来の自分への投資 である

早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。

我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。

Happy sleeping!

Permalink | 記事への反応(0) | 10:02

■早寝する技術　―持続可能なパフォーマンスを実現するスリープ マネジ

TL;DR

日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。

はじめに：なぜ我々はwhile(true)な夜を過ごすのか

我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。

「あとちょっとだけ、このバグの原因を調査したい」

「リファクタリングが楽しくなってきた」

「面白い技術記事を見つけてしまった」

これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。

アンチパターン：早寝を妨げるBlockerたち

早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。

Blocking I/Oとしてのスマートフォン:

就寝前のスマートフォンは、まさに同期的なブロッキング I/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。

Cacheされた覚醒 状態:

深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -h nowを叩いても、プロセスが終了しないのだ。

誤ったDependencyの注入:

「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。

Cronの不備:

不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。

Sleep as Code: 早寝を実現するためのプラクティス

では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleep as Codeの概念に基づき、具体的なプラクティスを紹介する。

1. 環境のIaC (Infrastructure as Code)

睡眠環境をコード化し、常に理想的な状態を維持する。

光の制御: 寝室は完全なダークモードに移行させる。遮光カーテンの導入は必須packageだ。また、夜になったらf.luxやNight Shiftを自動実行し、ディスプレイからのブルーライトというdeprecatedな光を排除する。
音の分離: 外部のノイズというinterruptを遮断するため、耳栓やホワイトノイズマシンを導入する。これにより、睡眠プロセスは他のプロセスから隔離されたsandbox環境で実行される。
温度・湿度の最適化: PrometheusとGrafanaでサーバーの温度を監視するように、寝室の温度と湿度も最適値（一般的に温度は18〜22℃、湿度は40〜60%）に保つ。スマートリモコンによる自動化を検討しよう。

2. 就寝CI/CD パイプラインの構築

毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。

Trigger (トリガー): 「22時になったら」など、就寝の1〜2時間前にパイプラインを起動するアラームを設定する。
Build (準備):

- PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。

- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。

Test (静寂):

静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。

ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。

Deploy (就寝):

すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgit clean -fdで強制削除し、呼吸に集中する。

3. MonitoringとRefactoring

睡眠の可視化: スマートウォッチや睡眠トラッカーを導入し、睡眠時間、深さ、周期といったmetricsを収集・可視化する。
ポストモーテムの実施: 「なぜ昨晩は寝付きが悪かったのか（incident）？」その原因（root cause）を特定し、対策を講じる。

例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」

A/Bテスト: 早寝のための施策（アロマを焚く、寝る前の音楽を変えるなど）を試し、睡眠スコアの改善度合いを計測する。効果的な施策をmasterブランチにマージしていく。

まとめ：早寝は未来の自分への投資 である

早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。

我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。

Happy sleeping!

Permalink | 記事への反応(0) | 10:02

「I/O」を含む日記

■読ませる義務と読まれる義務

■options_to_watch_nfl_streams_reddit

■rftytgb dfgdsfds

■てか、I/Oのバックナンバーをインターネットアーカイブにアップロードしている人がいるのか・・・

■dorawii@執筆依頼募集中

start-server.bat

config.json

server.py

GPT-5は何故重要なのか

結論（先に）**

壊れ方の具体（私の観測範囲）**

なぜそれが「重要」なのか**

よくある反論と、その限界**

では、開発者はどうするべきか（実務メモ）**

まとめ**

追記（FAQっぽいもの）**

天然知能の感想

■dorawii

■早寝する技術 ―持続可能なパフォーマンスを実現するスリープマネジ

TL;DR

はじめに：なぜ我々はwhile(true)な夜を過ごすのか

アンチパターン：早寝を妨げるBlockerたち

Sleep as Code: 早寝を実現するためのプラクティス

1. 環境のIaC (Infrastructure as Code)

2. 就寝CI/CDパイプラインの構築

3. MonitoringとRefactoring

まとめ：早寝は未来の自分への投資である

■早寝する技術 ―持続可能なパフォーマンスを実現するスリープマネジ

TL;DR

はじめに：なぜ我々はwhile(true)な夜を過ごすのか

アンチパターン：早寝を妨げるBlockerたち

Cacheされた覚醒状態:

Sleep as Code: 早寝を実現するためのプラクティス

1. 環境のIaC (Infrastructure as Code)

2. 就寝CI/CDパイプラインの構築

3. MonitoringとRefactoring

まとめ：早寝は未来の自分への投資である

■早寝する技術　―持続可能なパフォーマンスを実現するスリープマネジ

2. 就寝CI/CD パイプラインの構築

■早寝する技術　―持続可能なパフォーマンスを実現するスリープマネジ

2. 就寝CI/CD パイプラインの構築