Azure DevOpsオンライン Vol.14 ～ DevSecOps https://tfsug.connpass.com/event/385605/
やさしいとこから始めるGitHubリポジトリのセキュリティ
Azure DevOpsオンライン Vol.14 ～ DevSecOps https://tfsug.connpass.com/event/385605/
なぜ、SOLIDのリスコフ置換の原則(LSP)はもはや不要なのか？
はじめに LSPは長くSOLIDの一角として扱われてきましたが、現在の設計実務から見ると、もはや独立した柱として強く意識する必要はかなり薄れています。これはLSPが間違っていたという話ではなく、LSPが効いていた時代の前提そのものが崩れた、という話です。バーバラ・リスコフとジャネット・ウィングの1994年論文は、上位型で証明できる性質が下位型でも成り立つという 行動的型付け を定式化しましたし、ロバート・C・マーチンも1990年代にはこれをC++のパブリック継承を律する原則として説明していました。 ただし、ここで一つ引っかかる点があります。もし現代の設計がそもそも継承を中心にしていないなら、その継承を安全に使うための原則を、なおも五大原則の一つとして抱え続ける意味はどこまであるのでしょうか。継承を主役から降ろした言語、継承を持ちつつも言語機能で危険を制御する方向へ進んだ言語、いずれもLSP
Claude Codeのghコマンドpermission問題をreadonly用ラッパーで解決する - $shibayu36->blog;
Claude Codeでgh apiを使って情報を取得しようとすると、毎回権限プロンプトが表示されてつらい。例えば以下のようなただコミット一覧を取得するだけのコマンドでも、毎回許可が必要になる。 gh api "repos/anthropics/claude-code/commits?per_page=100&page=1" かといって利便性のためにgh api全体に対してallowを設定するのは怖い。ghコマンドはissueの作成やPRのマージなど書き込み操作もできるため、意図しない操作をしてしまうリスクがある。readonly操作だけに絞って許可できればいいのに、と思っていた。 何かいい方法はないかと調べていたところ、ghコマンドにはGH_CONFIG_DIR環境変数でプロファイルを切り替えられる仕組みがあることを発見した。これを利用してreadonly専用のghプロファイルを用意し、
【狂気の実証実験1】AIエージェントに電気ショック権限を付与したら生活が更生した - Qiita
概要 本記事では、 「自分の意思では生活習慣を改善できない人間が、AI Agentに“罰”を与える権限を渡したらどうなるか」 という実証実験について紹介します。 リマインダーも、ToDo管理も、コーチングサービスも続かない。 理由はシンプルで、守らなくても痛くないから。 そこで本記事では、 CLI型Agentに「コーチング役」を与え 1日の行動を自己申告し悪習慣を検知した際に Pavlok（電気刺激可能なウェアラブル）を通じて 物理的な罰 を与える という、やや狂気じみた構成を 最小実装 で試しました。 結果として、 「物理刺激権限を付与する前提のAgent設計にすることで人は大きく変われる」 という強い手応えがあり、構想・実装・効果を共有します。 想定読者 自堕落な生活を是正したいけど治せない方 習慣化アプリ・リマインダー・ToDo管理に何度も挫折してきた方 「結局、人は痛い目を見ないと
おい、論理で人が動くと思ってるのか - じゃあ、おうちで学べる
はじめに 数年前の、ある金曜日の夜のことだ。会議は完全な失敗に終わった。会議室を出て、エレベーターのボタンを押しながら、私はこの文章を書こうと決めた。書き上げるまでにずいぶん時間がかかってしまったので、当時の思いとは少し違っているかもしれない。 あの会議で「論理的に正しいことを言ったのか」と問われれば、言った。間違いなく言った。データも揃えた。根拠も示した。反論の余地がないほど、正しいことを言ったはずだった。 だが、誰も動かなかった。 私の発言が終わった瞬間、会議室の空気は凍りついた。誰も何も言わない。居心地の悪い沈黙が流れ、やがて別の話題へと移っていった。正しいことを言ったはずなのに、私は敗北感を覚えた。 当時、私はシニアエンジニアになったばかりだった。部下はいない。それでも「組織全体の技術選定に責任を持て」と言われる。命令する権限はない。しかし説得しなければならない。予算を握っているわ
「FastAPI + htmxが最強説」- AIエンジニアがモック作るならReactは不要、Streamlitも捨てよう
FastAPI + htmxが最強説 - Pythonエンジニアがモック作るならReactは不要、Streamlitも捨てよう この記事はLivetoon Tech Advent Calendar 2025の12日目の記事です。 宣伝 今回のアドベントカレンダーでは、LivetoonのAIキャラクターアプリのkaiwaに関わるエンジニアが、アプリの話からLLM・合成音声・インフラ監視・GPU・OSSまで、幅広くアドベントカレンダーとして書いて行く予定です。 是非、publicationをフォローして、記事を追ってみてください。 本題 どうも、LivetoonCTOのだいちです。 今回はスタートアップでプロトタイプ開発する時の技術選定について書きます。結論から言うと、FastAPI + htmxという組み合わせがモック開発において最も効率的で効果があると思います。 モックごときでReactを
【検証】夜泣き対応で絶望したので、娘の泣き声を最新LLMに「翻訳」させてみた - Qiita
はじめに 生まれたばかりの赤ちゃんは、まだ言葉を知らない。 代わりに泣くことで、世界と会話しようとする。 でも、その"言葉"を聞き取るのが、想像以上に難しい。 眠いのか、お腹がすいたのか、ただ抱きしめてほしいだけなのか。 毎回ゼロから推理ゲームが始まる。 夜中の3時。 泣き声の理由が分からず、抱っこしながらため息をついたとき、ふと頭に浮かんだ。 「この"泣き声の翻訳"、いまのAIならできたりするか？」 普段PdMとしてプロダクトの課題を見つけている私にとって、育児は未知の不便だらけで、手を入れたくなるUXの塊だった。 もし、この泣き声をAIが解析して「これはミルクだよ」「ただの寝言だよ」と教えてくれたら、どれだけ心が軽くなるだろうか？ そう思い立ち、試してみた。 自己紹介 株式会社SapeetのAI SaaS事業部でプロダクトマネージャーとして働いている畔柳です！ 早速私事なのですが（笑）
子どもに発達障害があることが分かった、簡単にいえば死にたい｜はやかわ
死にてえーーーー 支離滅裂に適当に思うまま書く。 子どもが発達障害（おそらくASD（自閉症））だった。 なるほどな…人生こうきたか…という気持ち。絶望しかない。 正直、私は王道のレールの上を歩んできた人生だった。 小学校受験で有名私立に合格、習い事も複数させてもらい、中高は部活や生徒会に入り楽しく過ごし、大学受験も第一志望の早慶レベルに合格し、JTC総合職になんなく就職。 20代で結婚して帝国ホテルで結婚式を行いモルディブで新婚旅行、家を買って車を買い、不妊治療の壁はあったものの第一子を出産。 学生時代の友達も趣味の友達も途切れずたくさんいるし、新しくできたママ友も多くいる。仕事も不満はない。全部うまくいっていると思ってた。 この後は、そこそこの年収をさらにそこそこに乗せ上げるよう動いて、週末子どもをどこに連れて行こうかな、旅行はどうしようかな、みたいなことだけ考えてればいい…と思っていた
参議院採決投票検索
このサイトは何？ 参議院の過去6年間（第200回～第217回国会）に審議された議案の投票結果を検索できます。 ただし、「起立採決」や「異議の有無」の方式で表決が行われた場合、誰がどのような投票をしたのかのデータがありませんので、掲載していません。 ※参議院での表決は原則として「押しボタン式投票」により行うこととされています。（参議院） しかし、第201回～第216回国会では、新型コロナウイルス対策のため押しボタン式投票が中止され、一部議案を除いて「起立採決」による表決が採用されました。（毎日新聞） （東京新聞） 7月19日公開時、押しボタン式投票中止期間を第202回からとしていましたが、正しくは第201回からの誤りでした。お詫びして訂正します。
関連のモデリング - kawasima
ドメインモデリングにおいて、エンティティ間の関連（リレーションシップ）をどのように表現するかは、システムの保守性や拡張性に大きく影響する重要な設計判断となる。 なぜ関連のモデリングが重要か 関連の設計が不適切だと、以下のような問題が発生する： 不変条件の検証が困難になり、データ整合性が保てない パフォーマンスの問題（N+1問題、過剰なメモリ使用） ドメインロジックの複雑化と保守性の低下 集約境界の破壊によるトランザクション管理の困難 データベースレベルでは、多対多の関連は交差テーブルを用いて表現されるが、ドメインモデルではより多様な表現方法が存在する。それぞれの設計選択は、パフォーマンス、メモリ使用量、コードの複雑性、ドメインロジックの表現力などに異なる影響を与える。 スキーマの例 まず、典型的な多対多リレーションのデータベーススキーマを見てみよう： code:sql -- 学生 CREA
シンプルは作れる！イミュータブルデータモデルの真髄 - kawasima
JJUG CCC 2025 Spring で話したものです。 昨今の生成AIによって、偶有的な難しさは激減した。し、これからも減り続けることだろう。 だが、本質的な難しさ(複雑さ)が変わるわけではない。 「本質的な複雑さ」とは何か？ 本質的な複雑さにはどうアプローチすれば良い? 本質的な複雑さはどう設計しても変わらない。 すなわち本質的複雑さは保存法則がある。 だが、本質的複雑さはその度合いに応じてComplexとComplicatedの複雑さがある。Complexな状態では、本質的複雑さがどれだけ含まれているかが把握できないことがある。動かしてみないと分からない、動かしてみても分からないことも… したがって、データモデリングを通じて「時間と労力さえかければ理解可能」な状態にしておくことが重要。 Complicatedな状態に持っていくために、イミュータブルデータモデルでモデリングすると良
【C#】何故 C# を好むのか。～他の言語と比較しながら～ - ねののお庭。
世の中には多くの C# に関する誤解が蔓延っています。 偏見にも満ちています。 そして技術的に正しい批判ではなく、根本的に技術的に誤った批判ばかりで正直悲しい。 技術的に正しい形の批判なら「お、そうだな。そしてそれの解決策はですねぇ...(ﾆﾔﾆﾔ)」となるのですが...。 そして C# 界隈から一歩出ると、「え、C# で作ってるの！？なんで？？」とか言われる事が非常に多い始末。 C# 大好きマンとしては非常に嘆かわしい。 嘆かわしい限りなので、ここでなぜ C# を私が好むか、そして何故ソフトウェアの開発に向いているかを語りたいと思います。そして誤解が解けたら嬉しい。ついでに C# を書きたいと思ってくれたら嬉しい。 想定読者 前書きという名の予防線 事前知識: C# と .NET C# はパフォーマンスの高い言語 C# はビルドも高速 C# はオープンソースかつクロスプラットフォーム 言
統合失調症の感覚を説明する
以前統合失調症だった。今は寛解して、普通の社会人をしている。 広末涼子がクレイジーな話でちょっと思い出したので書く。 はじめに統合失調症というのはいつも狂っているわけではなく、狂う時期と落ち着いている時期がある。 統合失調症患者はネットでは「やべー奴」として処理されているが、見た目には普通だし、会話をしていても意外と普通なので、あまり気付かないと思う。（「変わった人なのかな」と思う程度かも） 落ち着いている人はかなり長い間落ち着いているので、本人からカミングアウトされるまでわからないと思う。また、相当信頼されてなければ病気のことは言われないはず。意外と社会に多い。 これは統合失調症全般を解説したものではないのでそこは注意してほしい。 身バレしたくないので個人特定に繋がりかねない部分はかなりボカしている。具体的に話さないつもり。 感覚について統合失調症のいわゆる狂う時期（前駆期・急性期）にな
【保存版】親が亡くなったらやること全52項目を解説！一覧チェックシート付き - リハコ
「もしも、親が亡くなったら、どうしたらいいの？」 人生で、必ず直面しなければならない、親の死。 いつかその日が来ることを覚悟して。もしくは今まさに、親が亡くなった直後で、この記事を読まれているのではないでしょうか。 初めに、お伝えします。 親が亡くなった後にやることは、文字通り“山程”あります。 あなたがやることを、下記のリストに全部まとめました。 悲しみに暮れる暇もないまま、このように数々の手続きに忙殺される日々が待ち受けています。 とはいえ、しっかりと考えずに手続きを行ってしまうと、 「葬儀会社にぼったくられたり、相続問題で大損した…」 「葬儀で使う遺影の写真は、希望のものを使ってあげたかった…」 「お世話になったみんなに見送られたかったのを知らずに、家族葬にしてしまった…」 などと、後悔してしまうことは、案外少なくありません。 そこでこの記事では、親が亡くなったあとに知りたいことを全
全ビジネスマンが使えるClaude3.7 sonnet と draw.ioで始める図の作成。｜遠藤巧巳 - JapanMarketing合同会社 AIネイティブな会社の作り方
3.7 sonnet → drawioが今のところベストな図の作成方法。特にdrawioにすることで修正ができることが従来との違い。パワポ作成やブログなどの際に図を多用できる。これはわかりやすくビジネスマン全員が使える組み合わせ。 https://t.co/GzZRYhgt1V pic.twitter.com/xmWryTqnk6 — 遠藤巧巳 - AIエージェント受託開発 (@ai_agent_dev) March 1, 2025 図の作成のベストは2025年3月時点ではClaude3.7 sonnetです。ChatGPT,Geminiでもできますが、クオリティが低いと人の修正時間が増えます。この図の作成クオリティのためだけにClaudeを契約しても良いと思います。 何が違う？これまでは図の作成はsvgで行うことが普通でした。しかしsvgだと人の修正ができないため、ほんの少しの違和感でも
The Clean ArchitectureがWebフロントエンドでしっくりこないのは何故か / Why The Clean Architecture does not fit with Web Frontend
2025/02/28(金) JSConf.jp おかわり Node学園46時限目
aposd-vs-clean-code/README.md at main · johnousterhout/aposd-vs-clean-code
JOHN: Hi (Uncle) Bob! You and I have each written books on software design. We agree on some things, but there are some pretty big differences of opinion between my recent book A Philosophy of Software Design (hereafter "APOSD") and your classic book Clean Code. Thanks for agreeing to discuss those differences here. UB: My pleasure John. Before we begin let me say that I've carefully read through
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
# 参考資料 - 紹介図書 - https://amzn.to/3Qtd8NO - https://amzn.to/3QsXou3 - https://amzn.to/437f99X - https://amzn.to/41v6i0M - https:…
開放閉鎖原則(open-closed-principle)ってもはや意味ない - きしだのHatena
SOLID原則というのがあるのだけど、原則といつつ やりすぎに注意なみたいなことを言われ、自分で塩梅を探らないといけないなら全然原則じゃないやんということであまり好きではないのだけど、その中でもここではOにあてはまる開放閉鎖原則って意味ないよねって話を。 開放閉鎖原則の原典はメイヤーの「オブジェクト指向入門」で、第2版には次のような記述があります。(初版も書いてることはだいたい同じで、2版のほうが整理されて記述も多くなってます) モジュールは開いていると同時に閉じているべきである ただ、このメイヤーの文脈でいうようなモジュールの拡張ってやらないよねと。 ここでメイヤーの文脈での拡張というのは、モジュール自体に手をいれずに、機能の追加や変更ができるというものです。継承使っていい感じに機能追加ができる設計が「拡張に開かれている」ということです。 でもまあ、そんなライブラリの拡張をやらないですよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設計原則と普遍的な判断軸 | ドクセル