← 2026-03-07 の一覧へ戻るホーム
ペイフォン・ゴー

2026/03/03 1:45

ペイフォン・ゴー

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

要約

このプログラムは、カリフォルニア州の公衆電話を利用する者に対し、各電話機で最初に使用した順序に応じて段階的なポイントを付与します。

  1. サインアップ：参加者はアカウントを作成し、ユニークな9桁のプレイヤーIDを取得します。
  2. 公衆電話の利用：提供されたマップで公衆電話を探し、フリーダイヤル番号 888 683‑6697 をダイヤルして接続後にプレイヤーID を入力します。
  3. ポイント配分：
    • その電話機で最初に呼び出した人に20ポイント
    • 次の呼び出しには10ポイント
    • 三番目の呼び出しには5ポイント
    • それ以降は1ポイント（毎回）
  4. 公衆電話がすでにクレーム済みの場合でも、呼び出し者はポイントを受け取ります（少額になります）が、その電話機の記録としてログされます。
  5. 同じ公衆電話から複数回通話した場合、最初の呼び出しのみポイントが付与され、それ以降の通話では追加ポイントはありません。
  6. システムは、公衆電話のユニークな電話番号を運営者管理データベースと照合することで使用された公衆電話を特定します。
  7. 公衆電話リストはカリフォルニア州公共事業委員会への公開情報請求によって作成され、誤りが含まれている可能性があります。
  8. 未掲載または不正確なエントリーに遭遇した場合は、[email protected] まで位置情報、プレイヤーID、および実際の電話番号を添えてメールしてください。
  9. このイニシアチブは「ラブレター」としてカリフォルニア州の縮小する公衆電話ネットワークに向けられ、認知度を高め、保存政策への影響力を持つことを目的としています。

本文

仕組み

  1. アカウントを作成し、固有のプレイヤーID（9桁の番号）を取得します。
  2. マップでカリフォルニア州内の公衆電話（ペイフォン）の一つを探します（見つけやすいものもあれば、そうでないものもあります）。
  3. 電話受話器を取り、(888) 683‑6697（フリーダイヤル―コインは不要）にダイヤルし、プレイヤーID を入力します。
  4. ポイント：
    • 最初のペイフォンからの通話 → 20ポイント
    • 二回目の通話 → 10ポイント
    • 三回目の通話 → 5ポイント
    • それ以降のすべての通話 → 1ポイント

よくある質問（FAQ）

「どのペイフォンから電話したかはどうやって判別するんですか？」
各ペイフォンには固有の電話番号があります。(888) 683‑6697にダイヤルすると、システムは発信者IDを確認し、当社データベースと照合します。

「ペイフォンがすでに他人に使われている場合は？」
それでも電話できます。ポイントは少なくなりますが、その電話のログには追加されます。

「同じペイフォンから二度通話することは可能ですか？」
はい、可能です。ただし、1つのペイフォンにつき一度しかポイントを獲得できません。

「ペイフォン一覧はどこから入手したんですか？」
カリフォルニア州公共事業委員会への公開情報請求で取得しました。公衆電話はまだライセンスがあるものの、番号は減少しています。

「なぜペイフォンなのですか？」
カリフォルニアにはまだいくつか残っているため、その数が減少していることを示す一種の愛の手紙と考えてください。

「ペイフォンから電話したのにシステムが認識しませんでした。」
データベースにない番号のペイフォンや、既に存在しなくなったものもあります。情報は州政府から取得していますが、完全に正確である保証はありません。

問題が発生した場合は、以下の情報を [email protected] までメールしてください：

  • ペイフォンの所在地（住所・交差道路または写真）
  • プレイヤーID
  • 実際に使用した電話番号（分かる場合）

数日以内にデータベースを確認し、更新いたします。

同じ日のほかのニュース

一覧に戻る →

2026/03/07 6:52

「このCSSは、私が人間であることを証明します。」

## Japanese Translation: （以下に翻訳文を記載します） **著者は、選択的な大文字化、CSS を用いた対象的なケース変換（`text-transform: lowercase`）、慎重に使われる em ダッシュなどの微妙なタイポグラフィック・選択が、ファイルを `tr` でパイプするような鈍い自動化手法よりも優れていると主張しています。大文字化は「最初の傷」として描かれますが、実際には予想ほど痛みを伴わず、必要に応じて単語が大文字で流れ出します。著者は粗末な `cat post.md | tr A‑Z a‑z | sponge post.md` の手法を却下し、よりクリーンな効果を持つ CSS を推奨しています。 em ダッシュは貴重とされますが、作家の真実の自分を露呈させないように隠したままである必要があります。モノスペースフォントはテキストの美学を損なうため拒否されています。小さなスクリプト（`uv run rewrite_font.py`）は文字形態を微調整するための取るべき手段として強調され、意図的に単語を誤字すること（例： “their/there”、 “its/it’s”）がスタイルの一部であると述べられていますが、“Definately?” のような問題のあるペアは避けるとしています。 作家はノーリグ・コーパスを参照し、単語選択を導くとともに、ターゲットとなる単語から「u」を迅速に除去することで手法の精密さを示しています。全体的なトーンは、書くことが外見だけでなく思考・推論・関与を反映するものであると強調しています。 以前の拒否（“No. Not today.”）はスタイリスティックオーバーホールへの抵抗を示しています。次に計画されている変更は、作家自身の自我感覚を変える唯一の真に重要なステップとして描かれています。 技術的読者――特に文書スタイリング、フォント操作、編集ワークフローに関わる人々――に対して、このメッセージは自動変換から離れ、意図的なタイポグラフィック決定へ移行することを奨励し、デザイン標準や編集実務の再構築につながり得ると述べています。

2026/03/07 7:55

**C# の文字列が Dapper で SQL Server インデックスを静かに破壊する理由** Dapper を使って SQL Server データベースへクエリを投げる際、文字列結合や文字列補間（string interpolation）でクエリを作成することはよくあります。 しかし、この一見無害な手法がインデックスの性能を黙って破壊してしまうケースがあります。 --- ## なぜ起きるのか 1. **暗黙の型変換** `string` と `int`・`bool` など非文字列型を結合すると、SQL Server は列値を `nvarchar` に変換せざるを得ません。 2. **インデックス回避** この暗黙変換により最適化器は既存の数値や日付インデックスを利用できず、フルテーブルスキャンが発生します。 --- ## 問題を引き起こす典型的なパターン | パターン | 何をしているか | インデックスへの影響 | |---------|-----------------|----------------------| | `WHERE Id = " + id`（文字列結合） | `Id` 列を `nvarchar` に変換 | フルスキャン | | `$"SELECT * FROM Users WHERE IsActive = {isActive}"`（補間） | ブール値も同様に `nvarchar` へ変換 | フルスキャン | | `WHERE CreatedDate >= @date.ToString()` | 日付を文字列へ変換 | インデックスが失われる | --- ## 修正方法 1. **インライン値ではなくパラメータを使用する** ```csharp var sql = "SELECT * FROM Users WHERE Id = @Id"; connection.Query<User>(sql, new { Id = id }); ``` 2. **型の一貫性を保つ** 列が期待する正確な型（`int`、`DateTime` など）で渡す。 3. **C# で暗黙変換を避ける** 必要なら明示的にキャストまたは変換し、安全かつ意図した変換のみ行う。 --- ## 簡易チェックリスト - [ ] Dapper に渡す値は文字列化せず、型付きである。 - [ ] 変数データと SQL フラグメントのインライン結合を行わない。 - [ ] すべてのクエリに `@ParameterName` プレースホルダーを使用する。 これらのガイドラインに従えば、インデックスの整合性を保ちつつクエリを高速かつ効率的に維持できます。

## Japanese Translation: **概要:** .NET/Dapper アプリケーションでは、C# の文字列を `nvarchar(4000)` として渡すと、SQL Server が `varchar` 列に対して暗黙の型変換（implicit conversions）を実行します。これにより、インデックス検索がスキャンに置き換わり、論理読み取り数が単桁から数万に膨らみ、CPU/I/O の使用率が急増します（例：`CONVERT_IMPLICIT(nvarchar(255), [Sales].[ProductCode], 0)`）。 正確性には影響しませんが、実行計画や Query Store の警告で明らかになります。特に `SQL_Latin1_General_CP1_CI_AS` などの照合順序では顕著です。 **修正:** パラメータを ANSI として明示的に宣言し、列サイズと一致させます。 ```csharp var p = new DynamicParameters(); p.Add("productCode", productCode, DbType.AnsiString, size: 100); await conn.QueryFirstOrDefaultAsync<Product>(sql, p); ``` または匿名オブジェクトを使用する場合： ```csharp new { productCode = new DbString { Value = productCode, IsAnsi = true, Length = 100 } } ``` スキーマ変更、インデックス更新、クエリ書き換えは不要です。パフォーマンスの改善は即座に実感できます。 **監査ヒント:** Query Store で `@nvarchar(4000)` を検索し、varchar 列へ文字列を渡す匿名オブジェクトをコード内でスキャンしてください。 **ベストプラクティス:** 将来のリグレッション防止のために、`DbType.AnsiString`（または `IsAnsi = true`）を使用した理由をコメントしておくことが推奨されます。 この簡単な調整でサーバー負荷を低減し、コスト削減とスケールアップが実現します。結果として開発者・ユーザー・広範な .NET/SQL Server コミュニティ全体に恩恵をもたらします。

2026/03/07 6:19

**IPリースの陰影ある世界**

## Japanese Translation: IPリースは、誰もがクリーンで匿名のIPv4アドレスを取得し、ジオロケーションデータを操作できる隠密レンタル市場を生み出しており、IPベースの評判システムの信頼性を損なっています。ブロックを保有し、標準的な地域インターネットレジストリ（RIR）手順外でサブリースすることで、これらのサービスはWHOISトレーサビリティとRIRアカウンタビリティチェーンを迂回します。リース会社は料金を払ってブラックリスト化された範囲を「クリーン」し、ドロップダウンまたはCSVアップロードで任意の住宅または商業ジオロケーションを割り当て、WHOIS国フィールドまで操作することができ、MaxMind、Cloudflare、Googleなどに偽情報を供給します。 主要なVPNおよびプロキシプロバイダー（例：NordVPN、ExpressVPN、CyberGhost、PIA）は、LogicWeb、IPXO、INIZ、IPFoxi、Heficed、AnyIP/IPv4Deals などのリース会社からIPを調達しています。これらのプラットフォームは多くの場合、同じサイトで生IPスペースと完全なプロキシサブスクリプションの両方を販売し、エンドツーエンドの匿名化パイプラインを構築します。一部のプロバイダーは住宅ISPと直接提携してトラフィックを実際の加入者ネットワーク経由でルーティングし、合法的なオペレーターとプロキシとの境界を曖昧にしています。 業界は法的グレイズゾーンで運営されており—IPリースやジオロケーション操作を明示的に禁じる法律がないため—実効性の低い執行とインセンティブの不整合が生じています。リースが拡大するにつれて、インターネットセキュリティの基盤であるIP評判リスト、WHOIS帰属、およびジオロケーションデータベースはさらに侵食され、大規模な位置・所有権・評判の偽装が可能になります。これはユーザー（ボット検出やレート制限での誤検知）とIPベースのセキュリティ決定に依存する企業を脅かし、最終的にはインターネット全体の説明責任と安全性を弱めます。