24時間働く人たち、やばいｗｗｗ

sqlite が壊れるケースはありますか？ 気になります。異常なファイル移動や削除は除いて。

そうおっしゃっていましたが、今日Codexの新しいアプリが出て画像生成も可能になったんですか？ それなら、OAuth認証したクライアントでも許可されるんでしょうか？

このコメントは、韓国の開発者たちの閉じた考え方とGeekNewsの水準を物語っているように見えます。

CF Tunnelを設定してから、80番と443番ポートに溜まっていたfail2banのログがまったく出なくなったので、完全に外してそれ以降は気にしなくなりました。
ドメイン自体をCloudflareで購入し、SSOもCloudflareで設定して、SSOを通過できなければサービスを使えないようにして、すべての攻撃をCloudflareが代わりに受け止める構成にしています。
自分一人だけが使うサービスしか入っていないので、この構成でも十分実用的でした。
Cloudflareが障害になったら、その程度は受け入れることにしました。

Opus 4.6の性能低下を感じていたのですが、新モデルのリリースを控えていたからだったのかもしれません。
一度相対的に悪く感じさせると満足度が高まる魔法…

3、4番ですね。仕様を詳細に書くことには際限のない深さがあります。組織に合った程度というものがある、ということです。成功したサービスがどのように作られたかという歴史を見ると、99%のケースでは、仕様を正確に書くことにあまり力を入れすぎないこと自体が重要だったと認識しています。そこに埋没しないということです。サマナーズウォー、ダンジョン&ファイター、ジグバン、リネージュのようなものがどう作られたかを見れば分かります。

同感です。アジャイルは今でも有効です。現場を経験したことのない人たちが空中に向かって話しているようなものですね。

SQLite が壊れたら打つ手なし…。

調べてみたところ、キム・ホドンさんは2019年にもかなりストレスを受けていたようですね。文章を読んでみると、非常識な人やならず者のような人たちがあまりにも多かったですね。（今もいるのでしょうけど？）
https://hamonikr.org/Free_Board/63139

私も同意します。サービスにおいてDBが必要以上に重要視されることがしばしばあり、ときには正規化が崩れると大変なことになるかのように、過剰なくらい設計に投資することもありますよね。
DBを使うなという話ではなく、なぜ使うのか、そしてサービスの根本とは何なのか、という点をあらためて考え直すくらいの受け止め方でも十分に良いと思います。
結局、いつでもバランスが大事ですね。

韓国国内でアジャイルは、開発者へのスケジュール圧迫のための道具でしかなく、それ以上でもそれ以下でもない。

おっ.. いいですね。今までなかったので、ショートカットアプリだけ作って使ってたんですが

そうですね。事業の初期に利用者がまだ多くないときは、DBを導入したり複雑にしたりせず、基本的なファイルI/Oだけで事業が軌道に乗るところまで行ける、という提案として受け取ればよいのでは。

返信の珠玉のコメントはおまけです。

とても良い文章だと思います。特にああいう『数字』が入っている資料は貴重です。私たちが作るコードや、持ってきて使う技術スタックにどんなオーバーヘッドがあるのか、『大まかな感覚でも持っている』開発者を見るのが簡単ではない時代ですが、楽しく読みました。

たとえとして適切だと思います。私のプロジェクトも、実質的には人のIntentとSnapshotの2つだけで構成されています。
結局のところ、人の意図（例：キー入力、マウスクリック）をどのように計算し、どのような意味を持たせるかが、私のプロジェクトが進むべき道だと考えていました。

リリースされたのを見て書き込みに来ようと思ったら、もう投稿してくださっていたんですね。
性能がどれほどなのか気になります。

既存コードが残っているので、どのような実装かは直接確認できます。
https://gitlab.com/sebuls/libhwp

コンセプトは魅力的ですが、経験上こういう理想的な試みの中で成功したものはあまりなかったので…。
今のところは、AI機能も優れていて一番無難なのは Feedly ではないかと思います。