サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
衆議院選挙2026
scrapbox.io/AestheticsWiki
このProject（美学ウィキ）について。 / テンプレート / 美学ミーム / メモ / ディスカッション / settings / kofu / Dreamcore / Weirdcore / 電子ドラッグ / 未定：スキャン3Dモデル / ジェネ系 / Webcore / 未定：うごメモ風 / steampunk / Concrete poetry / 画面内映像 / モキュメンタリー /
scrapbox.io/kawasima
仕様モデルの設計において、振る舞いの境界を明確に定義することは、曖昧さの排除と矛盾の早期発見に不可欠である。ここでは、入力や出力の「区分」を明示的に定義する。 ここで使う「区分」は、業務システムでよく見られる「区分値」（例: 顧客区分コード 1=法人, 2=個人）とは異なる概念である。ここでは、型システムにおける直和型(OR)の各選択肢みたいなもの指している。代数的データ型における「バリアント」や、パターンマッチングの「ケース」に相当する概念で、振る舞いの境界を型として明示するための設計上の単位である。 仕様はドメイン記述ミニ言語で表す。 判断フロー ステップ1：behavior の出力を観察し分類する 対象の behavior の出力が取りうる値を観察する。 出力の性質を観察する際の視点： 出力値の種類は有限個か、それとも巨大な集合か 仕様で個々の値が列挙・明示されているか 値の違いが仕
scrapbox.io/fsubal
#フロントエンド #HTML 私はそもそも #HTML の <form> 要素が（少なくとも素のまま使うものとしては）好きではない #React の Server Action に関する話とか、「このフレームワークはWeb標準だからいい」とか、「単純なフォームなら #Rails の方が便利」とか、そういう話を見るたびに毎回この前提が自分の中で引っかかってしまう これらのツールや設計を良しとする人（そっちに寄せたいと思ってる人）、本当に HTML の <form> 要素好きですか？（便利だと思ってますか？）というのが気になっている たとえばブラウザの「戻る」で「フォームの再送信」ダイアログが出るサイトは現代では「品質が低い」と言っていいだろう これが出うる段階で、私は POST でのページ遷移というものをあまりやりたくないと感じてしまう まぁ流石にこれは大抵のフレームワークで回避する方法が存
scrapbox.io/game-studies-20251212
ゲームのフィクションと物語：『クリティカル・ワード ゲームスタディーズ』をもとに 立命館大学先端総合学術研究科院生プロジェクト「ゲーム研究基礎文献講読会」講演会 松永伸司 2025年12月12日（金） 於 立命館大学 今日の流れ 1. 言葉・概念・事柄を区別する 抽象度が高い話ですが、最低限の話の前提です。これを理解していただかないと以下の話がわかりません。 量が多いです。 2. 『クリティカル・ワード ゲームスタディーズ』全体についてのコメント こちらから積極的に説明することはあまりないですが、疑問・質問をいただければ答えます。 3. 「フィクション」の項目についてのコメント 何を書き、何を書かなかったかを説明します。 そういう書きぶりになった理由を説明します。 発展的な勉強の方向を紹介します。詳しいことは書いていませんが、質問をいただければわかる範囲で答えます。 4. 質問など 必要が
PofEAAの曖昧な部分を、現代の視点からできるだけクリアになるように解釈を加えます。できるだけ原書に忠実であることを目標にしますが、もちろんMartin Fowlerがそう考えている保証ではなく、あくまでも私の解釈なのでその点をご留意ください。 PofEAAで想定しているレイヤー定義 プレゼンテーション層 ユーザに情報を表示する ユーザーからのコマンドを解釈して、ドメインとデータソースに対するアクションに変換する ドメイン層 入力および保存されたデータに基づく計算 プレゼンテーションから来るデータの検証 プレゼンテーションから受け取ったコマンドに応じて実行するデータソースロジックの決定 データソース層 入力および保存されたデータに基づく計算 プレゼンテーションから来るデータの検証 プレゼンテーションから受け取ったコマンドに応じて実行するデータソースロジックの決定 PofEAAを読み解くた
#思考の癖 #言葉 特に #プログラミング の技術発信の文脈で、「モダンかどうかを重視するのは本質的ではない」といった批判がある。 ここで批判されているのは例えば、企業で採用している技術スタックが新しいフレームワークかどうかで人材獲得の競争をすることの不毛さなどであり、この種の指摘に正当性がないわけではない。 とはいえ、私は技術におけるモダンさとは単なる新しさ（少なくともリリース日が最近であること）とはかなり独立した概念だと思っている。 ここでは、私が「技術においてモダンさとは何だと思っているか」をメモしていく ある技術がモダンであるとは「解いている問題のレベルが高いこと」で定義される これは一般的に言われる「新規性」とある程度は近い むしろ私は「新規性」という概念自体をこう説明したほうが良いと思っている（以降「新規性」という言葉は使っていない） 「問題そのものは古いが、解決方法だけが新し
※ Stripeのドキュメントをベースにしているため、日本の決済慣習からすると違和感のあるものが混じっているかもしれません 決済プロセスの基本用語 Authorization（オーソリゼーション / 与信承認） カード発行銀行（Issuer）が、購入者の利用可能枠・残高を確認し、取引金額分を一時的に確保（ホールド）するプロセス。この時点では加盟店への支払いは発生せず、購入者の利用可能額が減算される。承認コードが返却されることで、加盟店は「支払いが保証された」状態となる。有効期限は通常7～30日（業種により異なる）。 Capture（売上確定） Authorizationで確保した金額を売上として確定させるプロセス。出荷完了・サービス提供完了時に実施される。この時点で購入者への課金が確定し、清算プロセスが開始される。Authorizationの有効期限内に実施しないと自動的にキャンセルされる
#WIP レガシーシステムを再構築しようとしても、期待していた開発スピードや品質の向上が得られないのはなぜか? そこに潜むアンチパターンを書き出してみます。 画面駆動設計 画面を切り口にアプリケーションの設計を考える。これ単体ではアンチパターンではない。 コンテキスト 現行システムの画面操作に慣れたユーザが多い 問題 同じ扱いをすべきデータが複数の画面に分散していても、それに気づきにくい 表示条件に見えるものが実はビジネスルールの制約である 項目間の関係性や構造が見えにくい テーブル駆動設計 データベースのテーブルを切り口にアプリケーションの設計を考える。これ単体ではアンチパターンではない。 コンテキスト 現行システムのデータベーススキーマが既に存在し、それを前提とした開発が求められる
scrapbox.io/nishio
There is no reply button, because we discovered that if there is a reply button, people with the most time wins the argument automatically, because they have more time to troll (laughs) people. If you take away the reply button, there’s no way for a troll to grow, and instead of just trolling each other, people start sharing their authentic feelings for other people to resonate. --- Audrey Tang 返信
scrapbox.io/shokai
Google meetsの文字起こしと、発表資料 + 事例集や対策方法のSmart Context3つをGemini 2.5 proに渡して、何度かディスカッションしたらすごいわかりやすくなった
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〜
タスク内の小タスク等で適切にhaiku等を使い分けてくれるのがClaude Codeの強みの1つだと思っているので、変なオプション付けなくていい
scrapbox.io/monokaki-goi-jiten
物書きのための語彙辞典とは / さらに語彙力を身につけたい人のためのブックリスト / 例文のリソースになっている作品一覧 / 看過 / 遺憾 / settings / 蠱惑 / 渉猟 / 憂き身をやつす / 扮する / 一挙一動 / 怒らす / 狷介不屈 / 起き伏しする / 居丈高 / 鼻歌まじり / 美辞麗句 / 険のある / 飼い殺し / グラマー
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
JUST DOWNLOAD をクリック、その先で JUST DOWNLOAD をクリックしてダウンロードが始まります。 https://scrapbox.io/files/6605f020639263002528cb59.png https://scrapbox.io/files/6605f0e6e83a990027e22a38.png
scrapbox.io/glisp
このページは移転しました: This page has been moved to: https://baku89.com/%E3%80%8E%E3%83%81%E3%83%A5%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E5%AE%8C%E5%85%A8%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%80%8F%E8%A9%A6%E
scrapbox.io/jgeem
25年ぶりに来日しました。かつて『エクストリーム・プログラミング（XP）』の本が日本の書店に平積みされているのを見て、とても嬉しかったことを覚えています。（サインしようとして店員に怪しまれ、逃げたという面白いエピソードもありましたが。） 今日は「開発生産性」について話します。より多く、より早く作れば生産性は向上するのでしょうか？ドイツには「物事を良くしようとして、かえって悪化する」という趣旨の言葉がありますが、まさにそれが生産性の議論で起きています。特にAIの登場は、この問題をさらに悪化させるのではないかと懸念しています。
allowed_tools: 'Agent,Bash,Edit,MultiEdit,WebFetch,WebSearch,Write' # これが必要
JJUG CCC 2025 Spring で話したものです。 昨今の生成AIによって、偶有的な難しさは激減した。し、これからも減り続けることだろう。 だが、本質的な難しさ(複雑さ)が変わるわけではない。 「本質的な複雑さ」とは何か？ 本質的な複雑さにはどうアプローチすれば良い? 本質的な複雑さはどう設計しても変わらない。 すなわち本質的複雑さは保存法則がある。 だが、本質的複雑さはその度合いに応じてComplexとComplicatedの複雑さがある。Complexな状態では、本質的複雑さがどれだけ含まれているかが把握できないことがある。動かしてみないと分からない、動かしてみても分からないことも… したがって、データモデリングを通じて「時間と労力さえかければ理解可能」な状態にしておくことが重要。 Complicatedな状態に持っていくために、イミュータブルデータモデルでモデリングすると良
scrapbox.io/kenchan
社内で、技術カンファレンスのスポンサーやイベントそのものを開催することについて、会社として支援する基準はあるのかという話があった。 何かしらの基準を設定することはできるだろうし、自分の中には最低限のラインのようなものはあるが、それを杓子定規に当てはめてアリナシを判断するのも難しいと考えている。たとえば、有効接触者数何人以上、それ一人あたりいくら、みたいなものもあるだろうし、そのテーマと会社のシナジーの度合いなど、基準や指標はいろいろあるが…… そんなことよりも、まずは「熱意が前提」ということにしたい。そのイベントやテーマについて熱い想いがあったり、会社としてそれを支援するべきというような気持ちの有無は、数字以上のものがあるだろう。逆に、熱意があれば数字はあとからついてくる(ついてこさせることが可能だ)と思う。 RubyKaigi 2025カスタムスポンサーの裏側 ── 海・芝・壁、そのノウ
scrapbox.io/aumy
これは俺aumy.iconがAIっぽい記事とかプログラミングスクールの薄い記事とか手段が目的化して逆効果な会社の技術ブログにキレる原理を説明している
上野山氏：AI 言語モデルとデジタル民主主義が交わることで「これまで不可能だった大規模コラボレーション」が可能になるのでは？+自己紹介も
インド側：調和を守り「ノー」と言わずに場を収める文化。結果的に事実とズレても“悪質なウソ”という感覚は薄い。
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 は負の二項分布になっていること SaaSの既存ユーザーの利用傾向が負の二項分布にな
次のページ
このページを最初にブックマークしてみませんか？
『Scrapbox - チームのための新しい共有ノート』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く