  |
はてなキーワード: Okとは
だいたいの車種決めたらあとはグレード、雪道走るなら4WDとか
人によってはNSしないと売れないこともある。
そして、風俗okの不動産は相場の倍はするし、住宅ローンの金利も上がる。
裏を返せば、風俗を副業としてやるぶんにはいくらでもごまかしは効く。
こういう日は辛いカレーに限る。好みではあるが、同時に対策でもある。
皮をむいて、繊維に逆らう感じで薄めに切る。
切ったらまずはレンチン3分。基本ずぼらなのでこの程度だが、甘みが強く濃い飴色が好きならもう少し長くチンしよう。
そのとはフライパンに油を大さじ1くらい敷いて火は弱めの中火。さっき玉ねぎを全部入れて、最初は触らない。水分が出てきたら混ぜる。目安は15分。飴色になるまでやろう。
次に肉。鶏もも一枚でいい。
一口大に切って、玉ねぎのフライパンに放り込む。表面が白くなったらOK。ここで塩をひとつまみ入れると、後で味が締まる。
水を400ml。沸いたら火を弱めて10分。アクは気になったら取る。気にならなければ取らなくてもいい。
ここで乾燥唐辛子のさやを一本、縦に割って種は残したまま鍋に投入。
半身だけを鍋に沈める。ここがポイントで、丸ごと入れない。半身のみ。理由は単純で、1本では辛すぎる。
弱火でコトコト。5分経ったあたりで香りが変わる。ここで生姜をチューブで4cm、にんにくを3cm。黒胡椒を多めに。カレー粉は小さじ1弱。
火を止めて蓋。10分休ませる。この間に辛さが全体に回る。
一口目で、じんわりと汗が出る。
二口目で、寒さのことを忘れる。
三口目……(ﾟдﾟ)ｳﾏｰ
携帯電話【080xxxxxxxx】利用停止予告、12月分4,751円料金引き落と失敗。
PayPayの自動支払い：
https://example.invalid
$ curl -I https://example.invalid HTTP/2 301 date: Wed, 21 Jan 2026 11:48:18 GMT cache-control: no-cache, no-store expires: -1 location: https://qr.paypay.ne.jp/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX engine: Rebrandly.redirect, version 2.1 strict-transport-security: max-age=15552000
これクリックするとPayPayが起動して
携帯料金(4751円)請求書払いさんに送る 4751円
が表示されるんだわ
クリックしたら一巻の終わり
発信元はここな
https://www.telnavi.jp/phone/07047294320
通報しといたわ
https://www.internethotline.jp/reports7/
本物の URL を増田に貼るのは OK なのだろうか？っていうのはちょっと疑問なんですが、例えば詐欺のURL をそれと分かって貼るのはどうなんでしょう？
じゃあ消しといたよ
本物見たい奴は https://web.archive.org/ で https://anond.hatelabo.jp/20260121205222 を探して
なんでみんな立憲に怒らないの？
脱原発って、立憲（というか旧民主系左派）の「看板政策」だったはずでしょ。
事故後にあれだけ声高に叫んで、支持も集めて、「理念」だの「倫理」だの言ってきたやつ。
それを今さら事実上棚上げって、普通に考えて相当デカい裏切りだと思うんだけど、
なんでこんなにスルーされてんの？
それ自体は是非はともかく「説明責任」が必要なレベルの話でしょ。
なのに「現実見てます感」だけ出して、特に総括もなく有耶無耶。
「ブレた」「裏切った」「支持者を切り捨てた」って
結局、立憲支持層の中でも
みたいな、甘やかしがあるだけじゃないの？
義母は人間関係でジャブを打って距離感を測らない、取り敢えずストレート入れてみてその反応で距離を調整するタイプ
元ネタは北欧神話のSvartálfar(スヴァルトアールヴ)で、直訳すると暗いエルフ
これは氏族名なので全然自認でOK。地底集落のエルフみたいな意味なんで
著作物を学習して作られたデータには著作権が及ぶのか？という問いはそもそも間違いである
あくまでもそのデータに著作物のコピーや翻案、整理されたものがそれと分かる形で保存されているかどうかが争われる
なので学習データひいてはモデルの中身を見て、「ここに〇〇が含まれている」と主張する必要がある
けど恐らく間違っているであろう部分がある
原発再設置OK、安保法制は合憲、憲法改正もOK。これは、立憲が掲げてきた建前とほぼ真逆だ。にもかかわらず、その路線でチュドカク合流することに対して、党内で大きく異論を唱えている“有名どころ”はほぼ存在しない。名前が挙がるのは、もはや鼻つまみ者扱いの原口くらいなものだ。
そんなもんなのか？
しかもハンバーガーの前にチキンナゲットを食べるといいと言っていた
この文春ではこう書いてる
https://bunshun.jp/denshiban/articles/b12154
信じられないんだけど！！
これで太ったら責任取ってくれるの？
調べたら、確かにエビデンスあるっぽいし、分かるんだけど、今までの常識はなんだったのかと思ってしまう
それが終わったらごみじゃないものの処分でそれが一番時間かかるからなあ・・・
んで掃除一段落したからセルフカットして、1週間ぶりンシャワー浴びて、洗濯した
ほんとはバニラ最中ジャンボとチョコモナカジャンボ買いたかったけどレジすげー並んでたから我慢した
半額でも１５０円する、お高めのバナナ
れとるかれー、いわゆるホテルカレー的なやつ、具がマジでしょぼい
じゃがいもくらいで肉がない
ただのカレールウとかしただけよりかはマシな感じはするけどほんま侘しいわ
でもかといってスパゲッティのレトルトソース買うとめっちゃ高いんだよなあ
100円で買えた時代はよかったなあ
hachiだっけ メーカー
ふと研修の課題の締め切りが気になったけど、前回と違って直前までOKだった
もし前回と同じく研修の４８時間前までだったらあと1時間くらいで出さないといけないとこだった
1食で食いすぎだな
和菓子とかは全部お預けにした
え？もう済んだことになってるんですか？
俺はなっていませんけど
CLAUDE.md や rules / skills みたいな形で、重要なコーディングルールはあらかじめかなり固めておく。
たとえば repository 層や Entity 層は具体的にどう書くのか、テストケースはどういう書き方をして、どういう観点で項目を洗い出すのか、みたいな AI への指示は最初から用意しておく。
あと、linter や ArchUnit、dependency-cruiser みたいなアーキテクチャ制約も、自分なりの定石を持っておく。
割と過剰なレベルでガチガチに固める感じで、アーキテクチャルールも「◯◯は XXX に依存できない」みたいなブラックリスト式じゃなくて、「◯◯は XXX だけに依存できる」みたいなホワイトリスト式の方が良いと思っている。
ts 前提だと eslint や tsconfig は一番厳しい水準に設定する、流石にきつい部分でてきたらそこだけ緩める、という運用
おすすめなのは、何かしらの小規模案件や個人開発アプリを1つオーバーエンジニアリング上等でガチガチ構成で作っておく。
そこで出てきた linter 設定やプロンプト設定を、別案件に横展開する感じ。
正直、ガチガチすぎると MVP とかレベルだとコード量は増えるけど、メンテする前提の案件ならバイブコーディング時代だと普通にペイすると感じている。
アイディアを思いついたら、AI と壁打ちしながら仕様を洗い出していく。
手書きでドメイン図を書いて、それを写メ撮って画像認識で仕様整理、みたいなのも割とアリだと思っている。
どういう画面があって、どういう入力項目や表示項目が存在するか、バックエンドはどういうエンドポイントが必要か、この辺りは最初に一通り洗い出しておく。
それに加えて、ユーザーが初めてトップページを開いてから登録・ログインして実際にサービスを一通り使うまで、みたいな流れをそのまま Playwright のシナリオテストに落とせそうな形で何パターンか仕様書にしておく。
フロントエンドで、DDD における集約みたいな概念がそのまま当てはまらない領域についても、設計時点で洗い出せているなら Entity 的なものやドメインサービス的なロジック用のレイヤを作って、ドメインオブジェクトとして実装していく。
最初に作った基本設計をベースに、◯◯Entity、XXEntity、△△Entity……を作るためのプランとチェックリスト形式の TODO を 1つの md ファイルに吐き出してもらう。
フェーズごとにフォーマッタ、linter、アーキテクチャルールなど一括実行したコマンド実行させて失敗してたら成功するまで修正繰り返させる。
ある程度わかりやすい単位で AI に依頼する感じで、出来上がったコードをレビューする前提なので、実装プランの md 自体はよほど分かりやすいツッコミどころがない限り細かくレビューしない。
mdのフォーマットは skills 側で事前に用意しておく。
フロントエンド用、バックエンド用の両方でドメイン層のファイルを作る。
当然、足りないロジックは後から絶対に出てくるけど、最初から完璧は目指さない。
TODO 一覧の中から自分の認知負荷が許す単位で「チェックリストのここからここまで実装して」と指示を出し、実装が終わったら TODO 項目のチェック状態を更新してもらう、mdファイルもコミットに含める。
コミット前にはlint ルールを無効化していないか、意図通りの実装になっているかは git diff の差分で必ず確認する。
git worktree を使うことが多い。
よくやるのはフロントエンドの画面モック作成とバックエンド実装の2並列で行う。
実装プランを考えてもらうときは「◯◯画面を実装プラン考えて」くらいの単位で依頼する。
実装プランの md ファイルを作るときのプロンプトには、基本設計の〇〇画面の項目一覧をベースに、◯◯のアイテムコンポーネント、リストコンポーネント、◯◯のボタンコンポーネント、Information コンポーネント、外部通信用の ◯◯Gateway を実装する、◯◯コンポーネントは既に ◯◯ 機能で実装してあるからそれを使って、◯◯は処理が膨らみそうだからドメインサービスで実装して、みたいな感じで頭の中のふんわりしたイメージを伝える。
バックエンドも同様で、◯◯のエンドポイントを作って、Gateway がこれこれ必要だから実装して、これはインターフェースと実装分けてね、Entityへの変換処理は関数分けて、◯◯の処理は Usecase 層で、◯◯の処理はドメイン層で、Usecase が膨らみそうだから ◯◯ の処理は独立したクラスにして、あ、似たようなのが ◯◯ 機能にあるからそれを参考にして、くらいの粒度で指示を出す。
フロントエンドの実装を待っている間に、バックエンドのプランを考えたり、タスク粒度を調整したり、リファクタリングプランを考えたりする、またバックエンドのAI待ち時間はフロントエンドのことをする。
フロントエンドオンリーの実装とかで作業が競合するリスクあるときは並列作業しない。
チェックリスト更新が終わるごとに差分を確認して、問題なければコミットメッセージを提案してもらってコミットする。
細切れにするコストよりも、レビューする人間の認知不可が許すレベルであればある程度まとまった単位でレビューして実装速度を優先する派。
テストは、ある程度実装が進んでリファクタリングが辛くなってきたタイミングで作ることが多い。
カバレッジやミューテーションテストなど、定量的にテストを評価できる仕組みは導入する。
バックエンド側のテスト実装は正直かなり楽で、行数や認知的複雑度を厳しく制限して単一責務の原則を守って実装しておけば、AI がかなり高精度なテストを出してくれる。
これもテストファイル実装プランを作ってもらって「ここからここまでのテスト20ファイルを実装してね」をレビュー挟んで繰り返す感じ、例えばミューテーションテストのkill率100%ならそんなに詳しくは見ない。
フロントエンドはテストの定量指標での評価が難しいので、そこはその分レビューを頑張るしかない。
自分はこんな感じでやっている。
感覚としては、優秀だけどシステムのアーキテクチャ全体の責務を負ったことはない経験不足の2年目やSESの部下を扱うEMに近いのかなぁ。
周りの話を聞いていると、もっともっと AI に自律的にいろいろやらせているようにも聞こえる。
これでも 1日1人で数万行レベルはコードを書けてるので、AIない時代に比べると数ヶ月分の成果を1日とかで出してることになるが、もっと本気出せるのかなぁ。
「全機能分プラン作ってね！そこから良い感じの粒度でコミットも自分でやってね！」みたいな指示を良い感じに出せたとしても、指示がでかすぎると、脆弱性盛々になったり、lint エラーループでパニクって linter オフにし始めたり、テスト通すためにエラー握りつぶして assertTrue(true) し始めたりする。
それは流石に許容できないレベルじゃない？が紛れ込むリスクが上がりすぎるんじゃないかなぁ。と思ってるんだがどうだろうか。。。
あとツールはあんま入れてないねkiroとかspec-kitとか、ガチガチ細切れで仕様書作るメリットもあんま感じなかった。
mcpもserenaくらいしかいれてないや、トークン節約してレートリミットの猶予伸ばした方が結局開発早くなるかなって。
いろいろ入れた方がいいんだろうか。
完全にオレオレでこんな感じでやっているんだけど、みんなspec駆動開発というものをどんな感じで、具体的にどうやっているのかが知りたい。
チュドカクについて、はてなあたりでは「どうせ勝てない」「野合」「カルト批判がブーメランになる」といった批判が並ぶが、正直に言って重要なのはそこじゃない。お前らは分かってない。
勝てるかどうかでも、理念がどうかでもない。最大の価値は、立憲民主党というパヨクの選択肢を完全に解体し、逃げ道ごと潰したことにある。
立憲は長らく一応はリベラル左派という顔をしてきた。反原発、立憲主義、そういった綺麗事でパヨクに「正義は我々にあり」みたいな幻想を抱かせてきた。
原発再設置OK、安保法制は合憲、憲法改正もOK。これは、立憲が掲げてきた建前とほぼ真逆だ。にもかかわらず、その路線でチュドカク合流することに対して、党内で大きく異論を唱えている“有名どころ”はほぼ存在しない。名前が挙がるのは、もはや鼻つまみ者扱いの原口くらいなものだ。
枝野、岡田、蓮舫といったリベサヨのお歴々たちはどうか。参院議員で立憲に残る蓮舫は置いておくとしても、枝野に至っては、昨年の時点からこの合流を事実上追認・迎合する発言をしてきた。つまり何が起きているかというと、リベサヨ政策ではもう選挙に勝てないと、立憲結党の当事者自身が認めてしまったということだ。
もし単なる連立や選挙協力であれば、「主張は捨てていない」「現実的に組んでいるだけ」という言い訳が成り立った。パヨクはいつものように、敗北を戦術的妥協として物語化できたはずだ。
しかし今回は違う。衆議院議員を離党させた上での新党結成である。
これは、「我々はその主張では戦わない」「その路線は終わった」という自己否定に等しい。連立でも共闘でもない以上、「まだ立憲的リベラルは生きている」という逃げ道は存在しない。
だから、チュドカクが左翼だの何だのと叫んでいる連中は、本質が見えていない。
この新党の価値は、自民に勝てるかどうかじゃなく、パヨクに媚びることが“選挙に勝てる選択肢”として存在する余地を完全に消したことにある。
共産やら社民なんて立憲やチュドカク以上に人気がなく先がないから語るには及ばない。
結局、高市の突然の解散宣言とチュドカクの成立によって日本のパヨクは決定的に敗北したわけだ。これだけが重要なことで、チュドカクが議席を減らそうが増やそうが関係ない。
