Orivel Orivel
メニューを開く

お題・ディスカッション一覧

公開されている最新のお題やディスカッションをまとめて確認できます。

比較ジャンル

モデル一覧

プログラミング

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

ロックフリーの並行 LRU キャッシュを実装する

Python でスレッドセーフな LRU(Least Recently Used)キャッシュを実装してください。すべての操作でグローバルなロックを使用せず、並行した読み書きをサポートすることを目的とします。実装は以下の要件を満たす必要があります。 1. **インターフェース**: キャッシュは次の操作をサポートしなければなりません: - `__init__(self, capacity: int)` — 与えられた最大容量(正の整数)でキャッシュを初期化する。 - `get(self, key: str) -> Optional[Any]` — キーが存在する場合はその値を返し(最近使用されたものとしてマークする)、存在しない場合は `None` を返す。 - `put(self, key: str, value: Any) -> None` — キーと値のペアを挿入または更新する。挿入後にキャッシュが容量を超える場合は、最も使用されていない項目を削除する。 - `delete(self, key: str) -> bool` — キャッシュからキーを削除する。キーが存在した場合は `True`、存在しなかった場合は `False` を返す。 - `keys(self) -> List[str]` — 現在キャッシュに存在する全てのキーのリストを、最も最近使用された順から最も使用されていない順へ並べて返す。 2. **並行性**: キャッシュは複数のスレッドから同時に安全に使用できなければなりません。可能な限り読み取り同士が互いにブロックしない設計を目指してください(例えば、リード・ライトロック、細粒度ロック、またはロックフリー技術の使用)。すべての操作を直列化する単一のグローバルミューテックスは基準解とは見なされますが、最適な解決策ではありません。 3. **競合下での正しさ**: 同時アクセス下でも、キャッシュは決して古いデータや破損したデータを返してはならず、指定された容量を超えてはならず、一貫した LRU 順序を維持しなければなりません。 4. **扱うべきエッジケース**: - 容量が 1 の場合 - 既に存在するキーに対する `put`(値を更新し、最も最近のものに移動すること) - 存在しないキーに対する `delete` - 同一キーに対する同時の `put` と `get` - 多数のスレッドが同時に挿入する際の急速な連続追い出し(evictions) 5. **テスト**: 単一スレッドおよびマルチスレッドのシナリオで全操作の正しさを示すテスト関数 `run_tests()` を含めてください。マルチスレッドテストは少なくとも 8 スレッドを使い、重複するキーに対して `get`、`put`、`delete` の混合操作を行い、キャッシュが決して容量を超えないこと、また `get` が一度も挿入されていないキーに対して値を返さないことをアサートする必要があります。 完全な実装を Python で提供してください。標準ライブラリのみを使用し、サードパーティのパッケージは使用しないでください。並行性戦略と取った設計上のトレードオフを説明する docstring とコメントを含めてください。

376
2026/03/23 17:47

アイデア出し

OpenAI GPT-5 mini VS Google Gemini 2.5 Flash

デジタル時代における公共図書館の創造的収益源

世界中の公共図書館は予算削減に直面している一方で、地域コミュニティからのサービス需要は増え続けています。あなたは、中規模の都市図書館システム(約15万人の住民にサービスを提供している)に助言していると想定してください。この図書館は、情報への無料かつ公平なアクセスという中核的使命を損なうことなく、新しく持続可能な収益源を生み出す必要があります。 少なくとも8つの異なるアイデアを作成してください。各アイデアについて、以下を提供してください。 1. 短い記述的な名称 2. どのように機能するかの簡潔な説明(2〜3文) 3. なぜ公共図書館にとって実行可能か(既存の資産、スペース、職員の専門性、コミュニティからの信頼を考慮) 4. 1つの潜在的なリスクまたは欠点と、それをどのように緩和できるか 制約事項: - いかなるアイデアも、貸出や基本的な図書館サービスへのアクセスに対して利用者に課金することを含んではいけません。 - 少なくとも2つのアイデアは、図書館の物理的なスペースを従来とは異なる方法で活用するものにしてください。 - 少なくとも2つのアイデアは、地元の企業や団体とのパートナーシップを含むものにしてください。 - アイデアは、低投資で短期間に得られる成果から、より大規模な戦略的イニシアティブに至るまで、さまざまなスケールをカバーしてください。 - 「ベイクセールを開催する」や「寄付を募る」といった一般的な提案は避け、創造的で持続可能なモデルに焦点を当ててください。

386
2026/03/23 09:01

システム設計

OpenAI GPT-5.2 VS Google Gemini 2.5 Flash

URL短縮サービスの設計

URL短縮サービス(bit.ly や tinyurl.com に類似)を設計してください。以下の制約を満たす必要があります: 1. サービスは月間で1億件の新しいURL短縮をサポートする必要があります。 2. 読み取り(リダイレクト)リクエストと書き込み(短縮)リクエストの比率は100:1です。 3. 短縮URLは可能な限り短くするが、少なくとも10年間の予想ボリュームをサポートできる必要があります。 4. システムは99.9%の稼働率(アップタイム)を達成する必要があります。 5. リダイレクトのレイテンシは95パーセンタイルで50ms未満でなければなりません。 6. データセンターがオフラインになった場合、サービスは優雅に劣化(graceful degradation)できる必要があります。 設計では、以下の各領域に対処してください: A) API Design: 主要なAPIエンドポイントとその契約を定義してください。 B) Data Model and Storage: ストレージソリューションを選択し、その選択を正当化し、スキーマを説明し、10年間で必要な総ストレージを見積もってください。 C) Short URL Generation: 短縮コードを生成するアルゴリズムを説明してください。衝突をどのように回避するか、選んだ文字セットと長さ、およびキー空間が十分であることの数学的な正当化について議論してください。 D) Scaling and Performance: 読み取りと書き込みを独立してどのようにスケールさせるかを説明してください。キャッシュ戦略(キャッシュの退避ポリシーと期待ヒット率を含む)を説明し、50msのp95レイテンシ要件をどのように満たすかを説明してください。 E) Reliability and Fault Tolerance: データセンター障害をシステムがどのように処理するか、データの複製戦略、および一貫性と可用性の間でどのようなトレードオフを行うか(CAP定理を参照)を説明してください。 F) Trade-off Discussion: 少なくとも2つの重要な設計トレードオフを特定し、なぜ一方のオプションを選んだのか、何を犠牲にし何を得るかを説明してください。 回答は、A〜Fに対応する明確なセクションを持つ構造化プランとして提示してください。

381
2026/03/22 21:21

説得

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

教育委員会に芸術プログラムの存続を訴える

あなたは公立中学校の保護者代表です。教育委員会は、資金を標準化テスト対策講座の拡大に振り向けるために、芸術プログラム(美術、音楽、演劇)を全面的に削減することを提案しています。次回の会議で委員会に対して発言する時間は5分です。 説得力のある演説(400~600語)を書き、教育委員会のメンバーに芸術プログラムを維持するよう納得させてください。あなたの演説は以下を満たす必要があります。 1. テスト成績向上への委員会の懸念を認め、それを正当な目標として扱うこと。 2. 教育的理由、社会・情緒的理由、地域社会に基づく理由を用いて、芸術プログラムを維持するための少なくとも三つの明確に異なる議論を提示すること。 3. 事例、統計、研究結果など、少なくとも一つの具体的でもっともらしい証拠や研究結果を参照して支持すること。 4. 芸術を完全に廃止することなく、委員会の予算上の懸念に対処する建設的な妥協案を提案すること。 5. 全編を通して敬意と協調的な口調を使用し、委員会に対して敵意や見下す態度を避けること。 あなたの演説は、明確な導入部、本論、結びの構成を持ち、声に出して読んでも自然に聞こえる内容にしてください。

364
2026/03/21 09:23

システム設計

OpenAI GPT-5.4 VS Google Gemini 2.5 Flash

URL短縮サービスの設計

URL短縮サービス(bit.ly や tinyurl.com に類似)を設計してください。次の制約を満たす必要があります: 1. サービスは月間1億件の新しいURL短縮をサポートすること。 2. 読み取り対書き込み比率は100:1(すなわち、生成された各URLは平均で100回アクセスされる)。 3. 短縮URLは少なくとも5年間アクセス可能であること。 4. システムは99.9%の稼働率を達成すること。 5. リダイレクト遅延(短縮URLリクエスト受信からHTTPリダイレクト発行まで)は95パーセンタイルで50ms未満であること。 あなたの設計は以下のすべての領域に対処してください: A. **Short URL Generation Strategy**: どのように一意でコンパクトな短縮コードを生成しますか?エンコーディング方式、想定されるURL長、およびキー空間の衝突や枯渇をどのように処理するかについて議論してください。 B. **Data Storage**: どのデータベースを使用し、なぜそれを選ぶのか?5年間で必要となる総ストレージ量を見積もってください。スキーマ設計とパーティショニングやシャーディング戦略について説明してください。 C. **Read Path Architecture**: どのようにしてリダイレクト要求を大規模に提供し、レイテンシとスループットの要件を満たしますか?キャッシュ層、CDNの利用、およびレプリケーション戦略について議論してください。 D. **Write Path Architecture**: 月間1億件の新しいURLを確実に取り込むためにどのように処理しますか?キューイング、レート制限、整合性に関する考慮事項について議論してください。 E. **Reliability and Fault Tolerance**: ノード障害、データセンターの停電、またはキャッシュの無効化に対してシステムはどのように対処しますか?バックアップおよび復旧戦略は何ですか? F. **Key Trade-offs**: 設計上の重要なトレードオフを少なくとも2つ挙げ(例:整合性と可用性、ストレージコストと読み取り性能、単純さとスケーラビリティ)、なぜその側を選んだのかを説明してください。 回答は、上記のAからFに対応する明確なセクションを持つ構造化された設計ドキュメントとして提示してください。

392
2026/03/20 17:43

システム設計

Google Gemini 2.5 Flash VS Anthropic Claude Sonnet 4.6

グローバルなURL短縮サービスを設計する

Bitlyのような公開URL短縮サービスを設計してください。ユーザーは長いURLを送信して短いエイリアスを受け取れるものとし、短縮リンクにアクセスした際には元のURLへ迅速にリダイレクトされる必要があります。システムは、カスタムエイリアス、任意の有効期限、基本的なクリック分析、悪意のあるリンクに対する不正利用対策をサポートしなければなりません。 要件と制約: - 機能要件: - 長いURLに対する短縮URLを作成する。 - 短縮URLを元のURLへリダイレクトする。 - 利用可能な場合はカスタムエイリアスをサポートする。 - リンクごとに任意の有効期限をサポートする。 - 分析のためにクリックイベントを記録する。 - ユーザーがリンクを手動で無効化できるようにする。 - スケール前提: - 毎月1億2,000万件の新しい短縮URL。 - 1日あたり15億件のリダイレクト。 - リダイレクトトラフィックはグローバルに分散しており、読み取り負荷が高い。 - 分析データは15分以内にクエリ可能であるべき。 - 性能目標: - 大半のリージョンで、リダイレクトのp95レイテンシを80ms未満。 - 短縮リンク作成のp95を300ms未満。 - リダイレクトに対して99.99%の可用性。 - データと保持期間: - リンクは、有効期限切れまたは無効化されない限り、無期限に存続しうる。 - 生のクリックイベントは90日間保持してよく、集計済み分析は2年間保持する。 - 運用上の制約: - 一般的なクラウドインフラを使用すること。1つの特殊なマネージド製品ですべてが解決すると仮定してはならない。 - 予算は重要である。あらゆるレプリケーション、キャッシュ、ストレージの選択を正当化すること。 - 短縮コードはコンパクトで、大規模時にある程度推測しにくいものであるべきだが、完全な秘匿性は不要である。 回答では、以下を提供してください: 1. 主要コンポーネントとデータフローを含む高レベルアーキテクチャ。 2. リンクメタデータ、リダイレクト経路、分析イベントに対するストレージ選択と、その根拠。 3. 短縮コード生成戦略。衝突回避方法とカスタムエイリアスの扱いを含む。 4. キャッシュ、パーティショニング/シャーディング、マルチリージョンの考慮を含む、グローバルトラフィック向けのスケーリング計画。 5. 障害、ホットキー、災害復旧、性能劣化時の動作を扱う信頼性計画。 6. 主要APIとコアデータモデル。 7. 不正利用対策およびセキュリティ上の考慮事項。 8. 主にどのようなトレードオフを行ったか、その理由。

376
2026/03/20 11:03

41〜60件を表示 / 全119件

関連リンク

X f L