サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
新内閣発足
scrapbox.io/shokai
以下は/Nota/サプライチェーン攻撃を学ぶ会2025秋の振り返りからのほぼコピペです サプライチェーン攻撃を学ぶ会 2025秋を振り返るshokai.icon Deep Researchで自分が知らない分野を調査し、Cosenseに書いて理解する等の方法で作ったページ郡と、それらを一旦まとめた文芸的データベース4つぐらいを眺めながらしゃべりまくった Google meetsの文字起こしと、発表資料 + 事例集や対策方法のSmart Context3つをGemini 2.5 proに渡して、何度かディスカッションしたらすごいわかりやすくなった ダイジェストレポートのダイジェストレポート 対策は、寝かせる・隔離・検知の3つである 寝かせる リリース直後のライブラリをインストールしない 隔離 開発環境をコンテナ化し、ホストとDocker内を分離 開発環境とproductionの設定値を分離し、
scrapbox.io/ruby-jp
https://kaigionrails.org/2025 オンラインとオフラインのハイブリッド 日程：2025.09.26 (Fri.) - 27 (Sat.) 会場：JP TOWER HALL&CONFERENCE https://kaigionrails.org/2025/events/ アフターイベント 10/07(火) 12:00〜13:30 【昼開催】After Kaigi on Rails 2025 from ピクシブ【オンライン】 10/07(火) 19:30〜21:30 【リジェクトConライク】Re:cycle〜Kaigi on Rails 2025編〜 10/07(火) 19:30〜21:30 基礎から振り返るKaigi on Rails 2025 10/09(木) 19:00〜21:30 Kaigi on Rails 2025 感想戦 10/10(金) 19:00〜
全開発者をMax planにする必要なし 株式会社HelpfeelはOrganization作ってTeam planで契約しています と思ってたけどこれTeam planじゃないらしいshokai.icon でもMax planでもない 一体なんなんだ？普通のOrganization？ 運用 25人ぐらいで月$1000未満 2025/4から、これを書いている2025/6/25時点までずっとそう monthly limitをかけておく とりあえず$1000に設定している 起動時のオプションで全ての作業をOpusにするみたいな暴挙をせず、Claude Codeのmodel選択に任せる タスク内の小タスク等で適切にhaiku等を使い分けてくれるのがClaude Codeの強みの1つだと思っているので、変なオプション付けなくていい アカウント開けても使わない人もいる DevinやGithub or
scrapbox.io/kawasima
Web上のコンシューマサービスにおいて、会員の契約プランによって出来ることが異なるものを考える。 ゴールドプラン: 会員限定スペシャルコンテンツが見れる、ポイント倍率5倍 シルバープラン: ポイント倍率2倍 ブロンズプラン 契約は月更新サブスクリプションを想定する。 このような場合、まず考えるべきは、セールス・マーケティングの世界(プランや契約)と、どのサービスが利用できるかの世界(権限)を切り離すことである。プランは短期的な売り上げをあげるために、新プランや使える機能の細かな調整が入ることが想定される。その度にプログラム修正が入っては大変だし、トラブルの元なので、その会員がどの機能を使えるかの制御にはプランを使わないように設計する。 このマーケと権限制御の分離ができていれば、「ゴールドプランのサービスがお試しで使えます！」などのキャンペーンも、アプリケーションとしては会員の権限(会員ラン
ユーザなどのリソースエンティティのパージするわけではないデータ削除(a.k.a. 論理削除)をどう設計するか、は単純でありながら、イミュータブルデータモデルの基本形を学ぶ良い題材なので、順を追って説明する。 リソースの検討 まずユーザがアクティブなユーザと削除されたユーザで扱いが異なるかどうかを考える。この段階で物理設計としてどうするかを考えると検討ポイントが十分考慮されないことにつながるので注意しよう 。(イミュータブルデータモデル#5e3a5f1da8e5b200009c0499) 扱いが異ならない場合を考えてみよう。 code: (mermaid) classDiagram direction LR class ユーザ { <<Resource>> ユーザID : SERIAL PK 名前 : VARCHAR メールアドレス : VARCHAR ユーザ区分 : ENUMアクティブ/削
ドメインモデリングにおいて、エンティティ間の関連（リレーションシップ）をどのように表現するかは、システムの保守性や拡張性に大きく影響する重要な設計判断となる。 なぜ関連のモデリングが重要か 関連の設計が不適切だと、以下のような問題が発生する： 不変条件の検証が困難になり、データ整合性が保てない パフォーマンスの問題（N+1問題、過剰なメモリ使用） ドメインロジックの複雑化と保守性の低下 集約境界の破壊によるトランザクション管理の困難 データベースレベルでは、多対多の関連は交差テーブルを用いて表現されるが、ドメインモデルではより多様な表現方法が存在する。それぞれの設計選択は、パフォーマンス、メモリ使用量、コードの複雑性、ドメインロジックの表現力などに異なる影響を与える。 スキーマの例 まず、典型的な多対多リレーションのデータベーススキーマを見てみよう： code:sql -- 学生 CREA
scrapbox.io/denpa
ATOMS3 Lite, ATOM Lite, ATOM Matrix のいずれか（以降、M5Atom と記述）
scrapbox.io/glisp
I haven’t gotten her permission yet, but I went ahead and translated it anyway because I really love this text. このテキストはネットアートの先駆者の一人、オリア・リアリナの2012年の論考『Turing Complete User』をchatgpt.iconの助けも借りつつ勢いで翻訳してみたものです。まだ彼女の許諾は取っていませんが…。
scrapbox.io/jgeem
#共有する 開発生産性カンファレンス https://dev-productivity-con.findy-code.io/2025 2025/07/03 Keynote: 開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった はじめに：25年ぶりの来日と生産性への問題意識 25年ぶりに来日しました。かつて『エクストリーム・プログラミング（XP）』の本が日本の書店に平積みされているのを見て、とても嬉しかったことを覚えています。（サインしようとして店員に怪しまれ、逃げたという面白いエピソードもありましたが。） 今日は「開発生産性」について話します。より多く、より早く作れば生産性は向上するのでしょうか？ドイツには「物事を良くしようとして、かえって悪化する」という趣旨の言葉がありますが、まさにそれが生産性の議論で起きています。特にAIの登場は、この問題をさらに悪化
Claude Codeがデフォルトで作る設定ファイルでは権限足りてないshokai.icon ghは使えるけどWebFetchもWebSearchもcurlもwgetも使えない githubはghコマンドで見れるけど、github pages含む普通のwebサイトは見れない状態 しかしClaude Code Gihtub Actionsは権限が無くて実行できなかった作業を知識で取り繕って成功したフリをするので、なんかwebにアクセスできているように見えるアウトプット出してくる めちゃくちゃ問い詰めると白状する なかなか認めてくれないけど、npmのURL渡して最新バージョンを正確に答えさせたりすると認めてくれる https://docs.anthropic.com/ja/docs/claude-code/settings#claudeが利用可能なツール にあるツールを許可する code:.g
JJUG CCC 2025 Spring で話したものです。 昨今の生成AIによって、偶有的な難しさは激減した。し、これからも減り続けることだろう。 だが、本質的な難しさ(複雑さ)が変わるわけではない。 「本質的な複雑さ」とは何か？ 本質的な複雑さにはどうアプローチすれば良い? 本質的な複雑さはどう設計しても変わらない。 すなわち本質的複雑さは保存法則がある。 だが、本質的複雑さはその度合いに応じてComplexとComplicatedの複雑さがある。Complexな状態では、本質的複雑さがどれだけ含まれているかが把握できないことがある。動かしてみないと分からない、動かしてみても分からないことも… したがって、データモデリングを通じて「時間と労力さえかければ理解可能」な状態にしておくことが重要。 Complicatedな状態に持っていくために、イミュータブルデータモデルでモデリングすると良
scrapbox.io/kenchan
社内で、技術カンファレンスのスポンサーやイベントそのものを開催することについて、会社として支援する基準はあるのかという話があった。 何かしらの基準を設定することはできるだろうし、自分の中には最低限のラインのようなものはあるが、それを杓子定規に当てはめてアリナシを判断するのも難しいと考えている。たとえば、有効接触者数何人以上、それ一人あたりいくら、みたいなものもあるだろうし、そのテーマと会社のシナジーの度合いなど、基準や指標はいろいろあるが…… そんなことよりも、まずは「熱意が前提」ということにしたい。そのイベントやテーマについて熱い想いがあったり、会社としてそれを支援するべきというような気持ちの有無は、数字以上のものがあるだろう。逆に、熱意があれば数字はあとからついてくる(ついてこさせることが可能だ)と思う。 RubyKaigi 2025カスタムスポンサーの裏側 ── 海・芝・壁、そのノウ
scrapbox.io/aumy
これは俺aumy.iconがAIっぽい記事とかプログラミングスクールの薄い記事とか手段が目的化して逆効果な会社の技術ブログにキレる原理を説明している
scrapbox.io/nishio
デジタル民主主義の未来 | トグルホールディングス株式会社 AIは民主主義にどう変革をもたらすのか─オードリー・タン氏らが語る、AIと市民参加の新たな関係性 - AIポータルメディアAIsmiley https://www.youtube.com/watch?v=pI9eXpWi2Bs 上野山氏：AI 言語モデルとデジタル民主主義が交わることで「これまで不可能だった大規模コラボレーション」が可能になるのでは？+自己紹介も タン氏 「數位」はデジタルと複数の意味がある 「デジタル大臣兼“多元性”大臣」として職務記述を書いた see Audrey Tangの詩的デジタル大臣職務記述 AIが高度化して人々を置き去りにするのではなく、多くの人々にベネフィットを与える AI の“垂直”な高度化ではなく“水平”な価値配分を重視 松尾氏 上野山氏は最初のPh. D. 学生、安野 貴博氏も卒業生、鈴木
インド側：調和を守り「ノー」と言わずに場を収める文化。結果的に事実とズレても“悪質なウソ”という感覚は薄い。
scrapbox.io/shinobe179-public
あいかわらずTeamsを使っているが、やはりTeamsのテキストコミュニケーションに関する機能は、Slackに劣っている。その上、頼みの綱のMicrosoft 365他サービスとの連携も非常にしょっぱい（これさえ上出来なら目をつぶれそうなものだが）。ただ以前同記事を書いたときからはいくらか改善が見られるようにも思うので、引用しつつ書いていこうと思う。
scrapbox.io/aereal-tech
仕事でいわゆるトレードオフ案件みたいなのに出喰わしたらトレードオフとか積極的に言いたくないので「これは恋に仕事に大忙しですね」って言いがちなんだけど、別にこの場では恋してないし、どちらも仕事なので適切じゃないけど、欲張り感は出ていい https://x.com/aereal/status/1014786145199116288 恋 = 内発的動機、仕事 = 外発的動機ないし使命、という対比……のつもりで使っていると思われる考え方。 どっちを捨てるべきとか、どっちが偉いとかではなく、ことができれば三方よしで良いじゃん、最高を目指そうよというスローガン。 ちゃおの登場人物はみんなそうしている。 「好きなことで生きていく」にも近いかもしれない。 refs. 好きな技術《コト》で、生きていく技術@YAPC::Hiroshima 2024 だからまあ、冒頭の南場社長の怒りというのは、単に給料泥棒に対
2025/4/24に開催した #アーキ部 『丁度ええ! ロギング』の内容を編集したものです。 ロギングにまつわる問題の構造 ロギングにまつわる現場でよく見られる問題には以下のようなものがあります。 ロギングガイドラインを定義して、開発者に周知し実装してもらったが、実際運用してみると、役に立たないログが多すぎる。 担当者が異なると、ログ出力する粒度が微妙に異なり、解析に時間がかかる。 ログの形式や内容が統一されておらず、分析ツールでの活用が難しい。 ロギングベストプラクティスは探すといくつか見つかります。 https://www.dataset.com/blog/the-10-commandments-of-logging/ https://betterstack.com/community/guides/logging/logging-best-practices/ https://new
scrapbox.io/yuiseki
エビデンスベースドマーケティングの手法をプロダクトマネジメントに応用する方法論 以下の前提を持つ 対象のプロダクトが という収益構造を持つこと MRR = MAU x PUR x ARPPU 対象のプロダクトが という構造を持つこと MAU = U_total x P_existing + (N_consumers - U_total) x P_new U_total: 累計ユーザー数 P_existing: 既存ユーザーがその月にアクティブになる確率 N_consumers: マーケット全体の消費者数 P_new: 未利用者がその月に新たにアクティブになる確率 対象のプロダクトの各ユーザー別の利用頻度がポアソン分布になっていること 対象のプロダクトの既存ユーザー全体での利用頻度の傾向 P_existing は負の二項分布になっていること このとき、以下が成り立つ : 一定期間における既存
scrapbox.io/fsubal
#フロントエンド #React などのライブラリを総称するのに「仮想DOM」というのは古いので、できる限り使わない 2025年時点で正式な代替があるわけではない これ系の UI ライブラリのジャンル（React とか Vue とか…）を総称するときは「宣言的 UI」が通りがよい しくみそのものを総称する代わりの用語はあまりない 「差分検知」としか言いようがない だからこそ「仮想DOM」という単語が雑に使われ続けていると思われる 初心者への説明の際に嘘も方便として使われることはあるだろうが、ほぼ嘘であるという認識は持ったほうが良い 少なくとも React を作っている人々は「virtual dom」という用語を避けるようになった 2018 年ぐらいから dan 先生がこういうツイートをするようになった https://twitter.com/dan_abramov/status/998320
scrapbox.io/honey32
#ソフトウェアアーキテクチャ（主にReact）について いわゆる「スクリーミングアーキテクチャ（叫ぶアーキテクチャ）」とか「コロケーション原則」を目指す・守るべき 「実装手段」のみに着目して分割するのは、それに真っ向から反するアンチパターン ただし、コード生成のためにコードを読ませるタイプのツールなど、技術的制約から仕方なく同種のファイルをまとめるのは仕方がない 例: aspida に読ませる型定義ファイル群とか あと、極めて抽象的なユーティリティは、 utils 直下とか、 /utils/hooks /utils/dom のようなところに分けても良いだろう 特に、「〇〇という関心事のためのユーティリティ」と言うことができないので。 例:safeNullable<A, B>(fn: (a: A) => B) => (value: A | undefined | null): B | und
こんにちはshokai.icon shokaiです Cosenseを開発しています Cosenseを9年作り続けて煮詰めたプロダクト設計の極意 という話をしようと思っていたけどshokai.icon ユーザー観察や意思決定の話は社外に出しにくい どうにも説教くさくなる なにより、最近は開発が楽しすぎて、それどころではない！！ というわけでいつも通り近況を話します 1. 最近開発したもの 2. 年始からDevinを使い始めた 3. Smart Context これはHelpfeel Tech Conf 2025の発表資料です 右側のメニュー内のStart presentationを押すとスライドになります Cosenseとは このサービスです 1ページ1トピックで書いたページをリンクさせ合って、複雑な情報を表現できる 51万ユーザー 2000万ページ 約9年開発してる Helpfeel（プロ
バリデーション解体新書 2025/4/8に開催した #アーキ部 『バリデーション解体新書』の内容を編集したものです。 バリデーションとは何か? 広義には、 何らかの処理を実施するにあたって、入力データが想定する条件を満たすかを検証する行為 と言える。 この定義で、アプリケーションのどこでバリデーションをしているのかを考えると、以下のように各層にそれが見られる。 このように実装される場所が散らばるので、「バリデーション」や「入力チェック」を分類して開発ガイドラインを作ることが多い。 例えば、大規模Java開発向けのTERASOLUNA開発ガイドラインを見てみると、 ユーザーが入力した値が不正かどうかを検証することは必須である。 入力値の検証は大きく分けて、 1. 長さや形式など、文脈によらず入力値だけを見て、それが妥当かどうかを判定できる検証 2. システムの状態によって入力値が妥当かどうか
Not_junk_ 東京大学の「レポートでchatgpt使ってもいいけど、使ったら参考文献にプロンプトとか全部書けよな」とかいう謎ルール
scrapbox.io/nazosauna
意図的にバグの起こりやすいプラグインを紹介したりデマを流したり変な設定をさせるサイトがあります 有料動画編集ソフトの悪質な広告まとめ 動画編集に興味を持ってもらいつつ、バグを起こさせて有料ソフトへ誘導するという理にかなっている話です 悪質なサイトを参考にした場合、エラーやバグが100倍くらい起こりとても重い環境になります 厳密には「意図的に」なのかそうではないのかは分からないと言われるかもしれませんが参考として、 拡張編集0.93rc1は致命的なバグ持ちのテスト版であり最新版（といえる） 拡張編集0.93rc1のバグ L-SMASH Works r940以下はバグ持ちで更新が止まった古いバージョン L-SMASH Worksを最新版に更新する バグが酷い最新版とバグのある古いバージョンを紹介しているサイトは果たして偶然なのかわざとなのか 今から導入もしくは入れ直しをする人向けに、新しめの情
老人喰い ――高齢者を狙う詐欺の正体 https://amzn.to/4hv6W35 人殺しの論理 凶悪殺人犯へのインタビュー https://amzn.to/4kIsFaq シャーデンフロイデ 他人を引きずり下ろす快感 https://amzn.to/4bJ2egJ 人はなぜ物語を求めるのか https://amzn.to/4htYIYV 近代の呪い https://amzn.to/4iMVHn
新しいプログラミング言語を学ぶ時に、まずはチュートリアルやマニュアルの通りに淡々と入力して結果を観察する「守破離の守」「写経」的な作業が必要になる。
「コンパイラが間違ってることを疑ってコンパイラの出力した機械語をチェックすること」と「人間が間違ってることを疑ってC言語の記述をチェックすること」の期待リターンが後者の方が高くなる 「LLMが間違ってることを疑ってLLMの出力したソースコードをチェックすること」と「人間が間違ってることを疑ってLLMに与えた自然言語の記述をチェックすること」だと2025年3月現在はまだ前者の方がリターンが大きそう
Devinを見る会で「何かすごいでかいことやってるな〜」と思って、出張で忙しくてじっくり見てなかったんだけど、後からじっくり見たらなんと1つのスレッドで4.5万円溶かしていてひどい面白かったので紹介するページ
次のページ
このページを最初にブックマークしてみませんか？
『Scrapbox - チームのための新しい共有ノート』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く