 
|
はてなキーワード: インデックスとは
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
| コンビニ | SD | xD | MS | CF | USBメモリ | CD/DVD | 赤外線 | その他 |
| セブンイレブン | ※１ | ○ | Duo | ※２ | ○ | ○ | IrDA | |
| ローソン(デジカメプリント) | ※１ | ○ | PRO, Duo | ○ | ○ | ○ | × | スマートメディア、MMC、SR-MMC |
| ローソン(多機能コピー) | ※１ | × | × | ○ | ○ | × | × | |
| ファミリーマート | HC | ○ | PRO | ○ | × | × | × | |
| サークルKサンクス | HC | ○ | PRO | ※２ | ○ | × | IrSimple/IrSS |
セブンイレブン（というかゼロックス）最強。書いてはいないが、ネットプリントと他サービスとの連携もある。
サークルKサンクス（というかシャープ）も意外とやってる。デジカメ写真でオリジナルカレンダーとか。
ファミマがんばれ。
2010/05/16 23:40
こんにちは。昨日会った者です（これで特定するには情報不足だけど、まあわかるよね）。
で「幅優先探索でやる」という方針自体はいいと思うし、データ構造の作り方も基本は押さえていると思います（斜め読みしかしてませんが）。
ただ、コーディングの発想が「C で作る」という大方針から見て、少しちぐはぐな印象も受けます。データ構造の設計や操作の部分、汎用のライブラリを作ろうというのならあれでもいいと思うのですが、わざわざ汎用のライブラリを使わずに自分で専用の道具を一から作ろうというのなら、問題の性質を考慮して能率良くやることが大事です。
ところが、ここに載っているコードを見ると、見かけが C らしくなく、C++ や Java の劣化版のような印象を受けます。記法（マクロを大文字化しない、ルーチン名を大文字で始めるなど）だけの問題ではなく、データ構造の設計思想が「C で書く」という方針と矛盾しているように見えます。
もう少し具体的に言うと、そもそも C というのは現在 Web 系の世界などで流行のスクリプト言語類とは逆で、汎用言語でありながら低レベル（ハードウェアに近い）処理が簡単にできることに特色があります。つまり、組み込みを想定してプラットフォーム非依存のコードを書いたり、ハードウェアの特性を考慮して低レベルな最適化をやりたいというときに適しています。
そこでこの問題ですが、これを C でやるということは、処理速度や使用メモリ量の最適化が要求される状況、つまり迷路の大きさが途方もなく大きいような状況を想定すべきです。もっと言ってしまえばこの問題、たとえば画像処理などで似たような発想が要求されることがあります。このため、どうすれば時間のかかる処理を切りつめることができるかを考えてやらねばなりません。
このプログラムの場合、時間のかかる処理の代表格である malloc() が大量に使われています。これはいかにもまずいです。このような大量データを処理する場合の定石は、あらかじめ必要なだけメモリを確保しておいて、自分で割り当てることです。具体的には、必要と想定される量だけメモリを配列の形でどかっと確保しておいて、配列のインデックスをポインタ代わりに使います。そして、足りなくなったら倍々のような感じでメモリを realloc() してやればよいのです。
なお、そのような観点で言って、木の各節点の子の数は高々 4 （スタート地点が内点でないとすれば 3）であることを使っていることはよいと思います。ここで「子のリスト」とかを作ってしまっていたらこれはもうアホもいいところですから（容量の節約にすらなりません）。
そんな感じでしょうか。
とにかく、この手の問題は、アルゴリズムさえわかっていれば可読性もヘッタクレもないので、「短く書く」というような表層的なことよりも、何が求められているのかをよく考えて、柔軟に設計思想を考えることが大事だと思います。
2010/05/17 13:54
Oさんですね。専門的なコメントありがとうございます！cで書くと言いつつObjective-Cっぽい発想で書いていました。マクロの命名もその影響で、関数はImage Magickなどに似た命名規則になっている気がします。mallocを使いすぎると時間がかかるということは全然意識していませんでした。今度作るときはメモリ管理を自前で用意する発想を取り入れてみたいです。参考になるコメントありがとうございました！
『ベン・トー』(1～7.5巻) アサウラ/集英社 スーパーダッシュ文庫/580～660円
『ゲート 自衛隊 彼の地にて、斯く戦えり』(1～4巻) 柳内たくみ/アルファポリス/各1785円
『ひきこもりの彼女は神なのです。』(1～2巻) すえばしけん/ホビージャパン HJ文庫/650～670円
『ソードアート・オンライン』(1～8巻) 川原 礫/アスキー・メディアワークス 電撃文庫/578～683円
『猫の地球儀 焔の章』『猫の地球儀 その2 幽の章』秋山瑞人/アスキー・メディアワークス 電撃文庫/焔の章536円、幽の章557円
『とある魔術の禁書目録(インデックス)』(1～22巻) 鎌池和馬/アスキー・メディアワークス 電撃文庫/578～641円
『ストレイト・ジャケット』(全11巻) 榊 一郎/富士見書房 富士見ファンタジア文庫/546～756円
『僕の妹は漢字が読める』かじいたかし/ホビージャパン HJ文庫/650円
『這いよれ! ニャル子さん』(1～7巻)逢空万太/ソフトバンククリエイティブ GA文庫/630～641円
ついでなんでこっちにも一言言っておくか。もう疲れたのでこの辺は緩く書くよ。
結論から書くと、信頼回復と隠れルールは関係がない。そして隠れルールの明文化はその目的を達成せず、単に自由度を狭めるだけで誰の利益にもならない。
これは自明。pixivの価値を高めるものであれば規約違反の写真でも許容され、価値を貶めるものであれば規約内の作品であっても削除される。
pixivがボランティアじゃなく営利企業である以上、こんなの当然だろと思うけど、それを許せない人はいるらしいね。
「pixivを許せない人間が、ルールの曖昧さを叩く武器にしているだけ」という方が正確だと思うけど。
機械検索の走りといえばgooだった。yahooのインデックス検索全盛においてクローラーが広大なインターネットの情報を片っ端から集めてインデックス化するgooは革命だった。
おいなんで唐突にpixivと関係ない昔語りしてんだよ？と思うかもしれない。そんなことはない。
なぜgooとgoogleで、後者を使うようになったか。それはgoogleの方が検索結果の精度が高いからだ。
なぜgooはgoogleより検索精度が低いのか、それはスパムによる検索結果の汚染が酷かったからだ。
クローラーが集めた情報のインデックス化には一定のルールがあり、その穴を付く手法としてSEOが蔓延、結果として機械検索はスパムによってガンガン汚染されていった。
客は水準の高い検索結果のあるサイトを使えるサイトとみなして、gooを去り、googleに乗り換えた。
その時googleは何をしていたのか？そう、隠れルールに作ってスパムを排除したんだ。中にはスパムでない人間も巻き添えになったんだ。でも多くの客は精度の高いgoogleを信頼した。
スパマーたちはこう思っただろう「普通の人間が作ったサイトと、俺たちの作ったサイトのどこが違う！googleはインデックスルールを明文化しろ！俺たちも検索結果に出る権利がある！」
望まれないスパマーたちを隠れルールで排除することで、googleは検索結果の精度を高めた。その自衛をしなかったgooは検索結果を汚染されて客を失った。
pixivが隠れルールによって運営に不都合な作品や、大多数の客が望まない作品を排除することも、サービスの価値を守るための、自衛行為とみなせる。
そして悪意あるスパマーたちも、悪意ある投稿者たちも考えることは同じだ。次のルールの中にある「穴」を探し出してサービスの価値を毀損する。このイタチごっこが永遠に続く。
「穴」を塞ぐためにどんどんルールが組み替えられ、投稿できる作品の幅は狭まっていく。運営は本来の「お絵描きたのしす」と全く違うところに人手を取られ、客も投稿ルールと睨み合う時間が増える。
これ、誰が得するの？
逆に隠れルールを撤廃してあらゆる作品を受け付けた場合、悪意や宣伝などの作品が溢れかえり、結局pixivの価値はなくなって使われなくなる。
「pixivに都合のいい作品だけ残しますよ」と明文化したならば、叩きたい人たちはこぞって武器にしてpixivを叩くだけだろう。
結局、削除されたことで、或いは気に入らない作品が削除されないことで憤る人たちは「pixivを屈服させたい」という真の目的が達成できないことに憤ってるに過ぎない。共感する余地も、同情する価値も一片もないと思うけどねぇ。
どう考えても悪手だろ！ってのを連発しすぎて信頼を失ってるのはどうにかすべきではあるね。
俺はそういう運営よりも、嫌いなものを悪意で歪曲して解釈したがる人たちの存在の方が気に食わないから、こういうこと書くんだけど。
まぁルールの明文化はイタチごっこになるだけだし、悪意ある人間の本当の「目的」を挫くことはできない。
結局信頼するかどうかなんてその人の問題だし、営利企業を100％信頼する人間はただのバカだ。信頼と利便性を天秤にかけて使い続けるかどうか決めればいいだけじゃないのかなー。
http://anond.hatelabo.jp/20110709123151
http://anond.hatelabo.jp/20110716093416
組織的なセルフブクマは、現実の序列を越えて、注目される存在になろうとする手段。
はてぶで、組織的なセルフブックマークを繰り返すとはてぶスパムになるし、インターネット全体で組織的なリンクの受け渡しをするのも微妙だよね。
はてぶを作ったときの想定としては、インターネットは一人でするもの、友達の影響を受けるかもしれないけど、同じ感性で共感できたから面白いので、ブクマとだれかの感性をフィルターしたものとして、1ブクマだった。
仲良しグループ、有名になりたい会社などで、共感フィルターを通さずに継続的に一定数以上のブクマがされる状況って、はてぶの機能としての限界だったのかもしれない。
ソーシャルな流れで、自分と感性のあったブックマーカーをさがすといいと言われている。その人ブックマークを参考にすれば、共感できていないものはフィルターをすり抜けない。特定の人のブックマークを差し引く機能とかグルーピングランキング機能とかをはてなさんなら実装しそうな気もする。
統計的な路線から人を媒介とした路線に移ろうとしているのだろうけど、もともと、人為的なサクラ行為を越えた、おもしろいものやムーブメントを探すための統計的技術だったはずだった。
けれども、そんなにおもしろいものは日常の中にはなかったのかもしれない。
10年以上前のインターネットだったら、たとえば、「ニセ首相官邸」なんていうわかりやすいニセものパロディサイトがあったとしても、検索上位に存在できたけど、今となっては、Googleのフィルタリングで、そもそもにせものは検索結果の最下位に甘んじるしかないのだろう。
当時は、Googleで、表示されなくてもYahooもあったし、Altavistaだの、東芝のFleshEye、NTTのGoo、千里眼とかいろいろと検索サイトを選択する余地があったので、まだよかったのかもしれない。検索サイトごとにルールや規約がちがっていて、別の序列が表示されたからだ。
現実社会とは別の序列が存在したころは、インターネットはフロンティアだった。現実社会とインターネットの序列が同じになったとき、わざわざインターネットでヒマをつぶそうと思うひとはなくなるのではないだろうか。
某国産携帯向けSNSで、会社の社長に会ったら、すっごいゴージャスなアバターでベンツに乗って女の子たちにちやほやされてたとしたら、それでも平社員の増田クンは、某国産携帯向けSNSに遊びにいくのか。
インターネット上で正体がわからないけどおもしろいものが存在できないようになってくると、組織的なセルフブックマークをしている個人も組織も現実の序列の中に戻っていくしかなくるのかもしれない。そんな人や会社が現実にもどってみると、普通の地域情報紙だったり、しがないライターだったりするのかもしれない。組織的なセルフブクマは過渡的なもので、世界中の情報がすべてインデックスされてしまっときには、意味をなさないものになっているのかもしれない。
スパム行為という内容が出ているが、これは語意と内容が合っていない。無差別に多額の請求になるように故意に送付するものと聞き及んでいるが、もし問題があるなら、その部分は管理者がカットすべきだと思う。
http://anond.hatelabo.jp/20110601132716 より、多数のブログに似たような記事をポストしているのは明らか。こういうのはスパムブログと呼ばれます。また、必要以上に多数のブログを作成すること自体、検索エンジンにインデックスさせる行為であり、検索エンジンスパムと呼ばれます。
http://taikenkun.at.webry.info/
http://blog.goo.ne.jp/taikenkun
http://taiken01.at.webry.info/
http://taikenkun.cocolog-nifty.com/blog/
http://plaza.rakuten.co.jp/taikenkun/
これも似たような記事。多数のブログサービスを使ってマルチポストしてる模様。スパムでしょう。
サブアカウントを4個まで取得できます。これにより、5つのアカウント（はてなID）を使ってはてなを利用することができます。
http://anond.hatelabo.jp/20110601132716 より、アカウントの取得は限度を超えてる。一法人であるタイケン学園がその関係者を何人か名義として使って不正にアカウント取得したのでしょう。九州電力かよ。
可能性はゼロではないが、ありえない。
第一に、情報の進行速度なんて閾値超えるまではゆっくりとしたものなので、
大概が閾値越える前に潰せる。
情報としては存在するかもしれないが、やがてインデックスされなくなり、検索もされなくなる。
第三に、そういったトラブルがあった場合、ウォッチャーは犯人側に食いつく。
語られてた”キャラクター”に対して炎上しているのだから、無関係の本人に食いついたところで美味くもなんとも無い。
”キャラクター”に最も近い、語っていた人間に興味がシフトするのは自然な事。
第四に、あんたの人脈はこんな事ぐらいで崩壊するほど脆いの？
馬渕教室、新生ホームサービス株式会社、日本eリモデルなどのSEOを担当していると思われる株式会社マイスタンダード（代表取締役 武智建樹）は、ブラックな企業らしいです。
日本のブラックハットSEO会社一覧に株式会社マイスタンダードが掲載されています。
インデックス削除URL タイトル サービス名称 会社名 代表者名 住所 備考 http://www.seo-rankup.com/otameshi.html 業界最安値！関連検索ワード削除１キーワード１万円 関連検索ワード削除 お試しプラン 株式会社マイスタンダード 武智建樹 大阪府大阪市淀川区西中島7-7-3-702
ブラックハットSEOとは、SEO（検索エンジン最適化）における用語で、悪質な（非倫理的な）手法を駆使して検索結果ページ（SERP）の上位に表示させる技術または施策のことである。
ブラックハットSEOの典型的な手法としては、ユーザーに気づかれないようにWebページ内にSEO目的のキーワードを大量に埋め込んだり、ユーザーがアクセスしてきた際にWebクローラが巡回したWebページとは異なるWebページを表示させるような仕組みを埋め込んだり、コメントスパムなどの強引な手法で大量のバックリンクを獲得しようとしたりする方法がある。検索エンジンの多くはこうした手法はポリシーに反するものとしており、通常は何らかのペナルティが課されるが、悪質なWebサイトと判断されず検索結果ページの上位に表示される場合がある。
http://www.sophia-it.com/content/%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF%E3%83%8F%E3%83%83%E3%83%88SEO
都民？
都知事選の顔ぶれをみるとなんかもう終わった感つよいよ。
82歳に未来の心配とかしてもらいたくねえけど、ご時世がら冒険すんのも怖いんだよね。
谷山雄二朗（たにやま・ゆうじろう、38歳） 無所属 インターナショナル・デジタル・パートタイマー[1]
古川圭吾（ふるかわ・けいご、41歳） 無所属 訪問介護会社役員[2]
石原慎太郎（いしはら・しんたろう、78歳） 無所属 東京都知事
東国原英夫（ひがしこくばる・ひでお、53歳） 無所属 前宮崎県知事
小池晃（こいけ・あきら、50歳） 無所属（日本共産党推薦） 前参議院議員
姫治けんじ（ひめじ・けんじ、59歳） 平和党核兵器廃絶平和運動 建物管理業
若いの一応調べてみる。情報なさそうだけど。
つか、やっぱりなんの情報もねえ。
http://www.yomiuri.co.jp/election/local/2011/kokuji/yf13.htm
こんなインデックスもない情報でどうやって選べっていうんだよ。
タイトルも写真もないAVであたりを探すようなもんだぜこんなの。
準備するもの
・イライラを抑える好物
・夜更かしセット
・多少のパケット料金
１、ワンセグ圏内まで移動する
４、データ放送を立ち上げる
（通信接続するかとか聞かれる）
７、MBSアニメインデックスでまとかマギカの待ち受けFlashを選択
Ｑ、これがなんか役に立つの？
Ｂ、テレビ局なので多分ダウンロード数とかのアクセスログとってる。
試してみた人ならわかるだろうけど、会員登録でいくつかの有料コンテンツがダウンロードできるようになってるから、ちゃんと調査してるはず。
なので放送時間帯でワンセグからのアクセス数が伸びれば、視聴率があるという結果が示せる。
視聴率があるものをわざわざ中止はしないだろうから、再開につながるんじゃなかろうかという思いつき。
MFAはGoogle AdSenseのために作られたサイト。ページを機械的に大量生成したりして、そこにアドセンスを出してクリックさせる。
こんな内容のないゴミサイト、早々にグーグルのインデックスからはずされてしかるべきで、実際、多くのゴミサイトはインデックスからはずされてる。
でも、内容はゴミでもグーグルの収益源になりえるぐらいのクリック率が高いゴミサイトの場合は、グーグルにとっては生かす価値ありと判断される。
これはグーグルの構造の問題でなかなかやめることはできない。Google自らが自分たちの最大の価値である検索結果を濁らせるというジレンマをかかえてる。
今、検索サイトとしてのグーグルは正念場かな。（こんなことはグーグルの頭のいい人たちはとっくにわかっていて、だからアンドロイドとか別の道をさぐってるんだろうけどね）
1981忘年会でLL一筋な人が酔っぱらって「大規模データ処理がさ〜」なんて言うもんだから遠くで話聞いてたらお子様レベルの内容で噴飯ものだった件について書く。
LL馬鹿「この前会社に頼まれて20GBのテキストデータを処理しちゃってさ〜 まじで難儀したよ〜」
Aさん「へーそうなんすか」
LL馬鹿「でもMySQLのインデックス適切に張れば大丈夫 インデックス大事よマジで」
LL馬鹿「MatzRubyだと遅いから1.9YARVで処理したら2倍処理が速かったね YARV凄いよYARV」
Bさん「pythonだともっと速いっすよ！テキスト処理ならpythonいいっすよ！」
LL馬鹿「あーわかるそれ！でもインデント嫌いなんだよオレw」
20GBって、、、、20TBならまだわかるけど、、、、、
後で知ったが妙にクールにLL馬鹿の話を受け流してたAさんはHadoopやらバリバリの人らしい
はあ、、、LL一筋の人ってLLが世界の中心でLLで何でも解決できるとか思っちゃってるみたいだし恥ずかしい生き物だと思いますよ
それでいて「Javaは本質的なコードが少ないから駄目言語」とか言っちゃう
オレも数年前までPerl最高な世界にどっぷり使ってたけど排他的で馴れ合い丸出し日本人コミュニティにうんざりしてJava勉強しだしたけどまじで正解だった
なんつーか時代に乗れてる感じ？
時代を作ってる感覚にすら襲われる瞬間もある
大規模データを処理するってのはそういうことですよLL一筋諸君
そろそお前らも時代を作る側に来いよ
さて寝るか
ちなみに、あなたが言いたいPIがなんのことかわからないけど パールインデックスの事であるならば、
不特定多数との性交渉を持つ風俗における、月経ベースの避妊を行わず、毎日SEXした場合には当てはまらんだろ。
パールインデックスはあくまで、通常のカップルにおける避妊率の話で、風俗のように毎日の恒常的なSEXにおける統計ではなかろ。
失敗率は基本的に、該当数式で漸化式を作ること自体は間違っていないよ。
あえていうなら、風俗の人は日に2回ということもあり得るだろうから、年間12回ではなく、24回でもいいくらいだ。
仮に、月経ベースの避妊を並行して行うなら、(1-(1-0.98)*(1-該当避妊率))^12だから、低用量ピルぐらいの計算上の避妊率にはなる。
http://d.hatena.ne.jp/potato_gnocchi/20100526
「若い人が投資をする理由は複利だ」とか言ってるけど大嘘。
他にも「習うより慣れろ」とかもあるね。
大嘘。
色々と言い訳はあるだろうけど、日本で麻雀といえば金を賭ける。
ひところ大学の寮などに行けば、新入生が上級生から金を巻き上げられるなんてのは、まあ通過儀礼みたいなもんだった。
いわば、カモから金を巻き上げるわけだ。
（もちろんそれは単なる通過儀礼だから、上級生からすれば授業料、とでも思ってる節はあった）
じゃあ、儲かってる人はどこから金を巻き上げるのか？デカく負けるひと？大口の取りこぼし？
違うね。
１万円、５万円、１０万円ぐらい負けてる一般人からうすーくひろーく巻き上げるのさ。
だから、FXの入門書や株の入門書が氾濫している時ってのは、稼ぎどきだったわけだ。
訳もわからない初心者が「無くなっても授業料だと思って」大挙してやってくる時期だから。
まさに、カモネギ状態だ。
複利？
馬鹿言っちゃいけない。１％の複利でも積み重ねればデカイ。それはそのとおり。
で、ペーペーの若人が金突っ込んで複利の恩恵を享受できるもんか？
できないね。
若い人が投資を行う理由はたった１つだ。「痛みを伴った学習は身につくから」
もっと身も蓋もない言い方をしてもいい。「賭け事なら熱くなるから」
株をやらなきゃ、そもそも株式会社ってのはなんで、どうして合併が起こるのか気にすらしない。
どの業界がどんな仕事をしていて、どうして利益を生んでるかわからない。
コンシューマ向けの仕事をしているところ以外は、就活の視野に入らない。
「賭け事に勝ちたい」というある意味凄まじく純粋で強力な動機から、そういったことを知ることが出来る。
（WBSのトレたまで取り上げられるだけで株価が上下するなんていう、市場のイイカゲンさも肌で感じることが出来る）
考える事、調べることが大量にあって、勝つには動向を調べる必要がある。
そりゃそうだ。ライバルに勝ちたきゃ、ライバルに先んじる必要がある。
それは、場代を徴収する雀荘に勝つ為でも、たまにいる雀ゴロに勝つためでもない。
それよりも、なぜGoldの相場が最近上がりっぱなしなのか、土地に投資するのはどういう意味を持つのか、OPECってニュースで言う時にじゃあそれは家計にどういう影響がありそうなのか、
そういった自分が生きている世の中を知ることが出来る、情報の読み解き方を知ることが重要なんじゃないか？
ダビスタに費やした1万時間は輝かしい勲章かもしれないが、経済指標の影響力が判るわけじゃない。
棒テン則リー全ツッパ、相手が張れば運だのみ。
それじゃ勝てないし上手くもならない。
勝てたとしたって単なる星の巡りだ。
FXも同じだ。
「上がりそうだから」「下がりそうだから」の２択のギャンブルじゃルーレットと同じだ。
「みんなが上がると思いそうだから」なんていう根拠をどうやって出していくか。
政権交代したら円ドルレートはどう動くのか？それを自分はどう考えるのか？
株だってそうだ。
上がり調子の株に張るのに根拠がなきゃ、それは大金かけたスロットだ。
スロッターだって研究するご時世、どうなるかわからん株を買うのか？
そしてその分析は、日々の生活の中で役に立つ。
シューカツするなら日経読もう。大いに結構。
でも、小銭を稼ぐために血走った目で世界情勢追っかけてる連中の情熱を持って読めるかな？
業界研究するときに、100万突っ込むつもりで分析してるかな？
「うちの会社は大丈夫かなあ」と溜息つくときに、同業他社と材料比較できるかな？
だから、若い人が漫然とインデックスファンドの手数料を比較しても、持株会に入ってもあまり意味はない。
ギャンブルに勝つつもりで、不順な動機で突っ走るために本気で分析してこそ意味がある。
向いてる向いてない、投資だ老後だなんて言う前に、目の前の鉄火場に本気になる。
それこそが、結局世の中を知ることになるし、社会の仕組みの一端に触れることが出来る。
麻雀やパチンコ、桃鉄やその他もろもろのエンターテイメントと同じく、単なる遊びだ。
どうせ熱くなるなら、あとで使える知識が身につく賭け事に時間を費やそう。
それに、なんだかんだいったって人生落ち着けばギャンブルみたいなヤクザなことからは足を洗うんだ。
ショックだね。超高速道路というか、そういう以前の問題だよこれは。
やろうとすることを普通の人が身につけるのに３年は掛かるだろうに、しかも、ここまでのクオリティはでない。
唸ってしまう。
回避できるのであれば使うHTMLやCSSは限られる。覚えるのは最小限。
Dreamweaverつこーてるのかな？
ツールが解決してくれるのならコードを書く必要すらない。
jQueryでやられていることを自前実装するには技術力が必要。
中で何をやっているかなんて詳しく知る必要などない。
世界中のもっと詳しい人がチェックをいれてくれている。jQueryを利用したライブラリやサンプルコードも転がっている。jQueryでできないことがでてきたらどうするか？ prototype.jsでも使えばいいじゃない。
扱いがかわいそう。
自分に必要がないもの、目的に合致するのに遠回りなものを切り捨てる能力がないと何時まで経っても勉強だけして終わる。
PHPで何かしようとしたのではなく、単なるテンプレートエンジンとして割りきって利用したようだ。
表示したいところに表示させたいものを埋め込むだけなら、それはHTMLとほぼ同等の何かでしかなくなる。
どの言語でやっても一緒なら、できるだけ自分がつくる部分が少ないほうがよい。
phpではクローラーをつくるのにいいライブラリがあるというのを聞いたことがない。
RubyならPerlみたいな正規表現に悩まされることもない。なるほど。
素人がRuby環境を例えばLinux上に構築しようとしたらかなり躓くところがあると思う。Railsを使わずにRubyで済ませたというところか。ここらへんから何か恐ろしい。
逆算するとクローラーをつくるまで学習を初めてから２ヶ月も掛かっていないことになる。
クローラーをつくってからApacheを知ったというのがリアルで笑えるのだけど、恐ろしい。
Ruby環境とPHP環境をどうやって同居させたのかとかそういう苦労が見えない。ということ苦労しなかったのかもしれない。やはりRailsではなくてRubyなのか。
技術者を名乗る人でもRubyの環境構築ができない人も多いのにこの人は素直にすごい。
何もないところからLinux環境にPHPやらmySQLやらRubyやらの環境構築は熟練した人でも半日かかるめんどくさい作業なのでそれをやれてしまうというところで、３年生ぐらいのエンジニアスキルがあると俺は認める。
それは言い直すと普通に仕事として身につけたとしても一般的には３年はかかるということだ。
はてさて、SQLまでかけるようになったというのだろうか。
DB設計は？ 確かにこの内容であれば設計を要するほどの複雑さはない。１テーブルで十分。
インデックスとか貼ってないだろうなとは思わせるが、5GBのデータでもこれだけのレスポンスが出てしまう時代だ。
チューニングするぐらならいいハードにのっけなよということか。
デザイナーとしても食っていけるだけのスキルがあるんじゃなかろうかとおもってしまう。
もう、なんていうか調査能力もすごい。
というか調査能力がすごいんだろうな。
Twitter、楽しんでますか？
そろそろ誰か好きな人が出来たりしましたね。良かった。じゃあストーキングしちゃいましょう。
今回は「@masudadayo」さんをストーキングしてみます。（example.com的な例示IDがないので作りました。同様の用途で使いたい方使っちゃってください。）
鍵がかかってる人は諦めましょう。また、なるべくリアルタイムで捕捉することを念頭に置いて書いています。
まさかただフォローするだけ、良くてもListに入れる、RSS登録するだけなんかじゃないですよね。それでは「全て」追えません。検索を使います。
検索ワードは「from:masudadayo OR to:masudadayo OR @masudadayo」。to:と@を併記しているのは検索の仕様です。to:はin_reply_toがついているものだけを対象に検索しています。
Twitterをやっていれば自分のホームから検索すればこのクエリを保存することができます。保存したものはiPhoneなどからも使えるので出先でのチェックもできますね。
また、これ以外にさらにORで繋げて対象のニックネームなども書きたいのですが、公式検索は日本語に非常に弱いのであまり効果がないかもしれません。
そこで使えるのが通称「yats検索」（ここ）。かなり日本語のヒット率が高いのでオススメです。ただ、クロール対象が狭いので出来れば公式と併用したいところ。
ちなみに、なんとMacのTwitterクライアント「夜フクロウ」には公式検索とyats検索をマージして検索結果として表示してくれる機能が搭載されています。
他にもGoogleのアップデート検索や、NAVERのリアルタイム検索なども使えることがあります。削除されたツイートなどがインデックスに残っていたり、ね。
favを使ってコミュニケーションをとっている通称ふぁぼクラスタだとこれは外せません。
favstarではほぼリアルタイムに観測ができます。Recentがふぁぼられ、Givenがふぁぼり。ただ、無料だと時系列に過去へさかのぼれるのが1ページ(20件)だけなので古いものが見れません。
そこで、国産サービスだと有名なふぁぼったーや、最近ではふぁぼろぐなんかも出来ました。
特にふぁぼろぐは、自分のふぁぼを整理して見られるのが恥ずかしい！と言って非公開にする人が続出しています。favはその人の趣味嗜好や内面を知ることのできる大事なデータですから必ずチェックしましょう。
対象が仲良くしてる人（@を飛ばしてるとかRTしてるとか）気になりますよね。
ずばり、なかよしったーでは最近のツイートの中から一番を調べられます。
また、Twilogなら、対象の人が登録してれば過去全て、してなくても最近のツイートの中から仲の良い順に表示されます。右ペインの「Friends」でどうぞ。
Twitivityでプロフィールや、アイコン画像変遷が追いかけられます。気持ちや環境に変化があるとプロフィールを変える人は多いのでこれでぜひ。
特に、Twitpicなどの写真系や、foursquareや国産ならロケタッチを始めとした位置情報サービス系。
電波の悪さや、APIの不調などでサードパーティのサービスにだけデータがアップされて、Twitterにはつぶやかれていない事が結構あるので、ツイートとは別にチェックしておくのをオススメします。
他にも皆さんの素敵なTwitterストーキング術があれば教えてください。Facebookのように複雑でないTwitterはストーキングが非常に簡単ですね。
では、タイムラインで。
規制派の方は仲間うちでヒートアップするんじゃなく裁判官の前で同じことを言ってみるといい。
http://alfalfalfa.com/archives/1401298.html
仲間内だけで議論していると、こういうことはよくある。
こまかいところをすっ飛ばしてノリで議論を進めてしまう。
相手側の指摘は全部スルーしてしまうこともありがち。この時点でもう議論じゃないけどな。
その結果、虚構の上にできた主張が、さらに虚構を生んで、いつのまにやら
それってもう完全に、集団幻覚とかトリップの世界。インデックスさんいつのまに。
彼女たちはもう耳つぶすとかしないと助からないかもしれない。
話それたけれど、
そういう場でいくら議論しても、議論の土台となる事実認定がおろそかになるから。
そういう内輪議論をしたいなら別に留はしない。
でも、そういうのは他の人の目に見えないところでやるべきだと思う。
他の人にその理屈は通用しない。強弁するならばこれは偽証罪になるかもしれない。
これはオタ側も一緒。
どんなエロだろうが変態だろうが、内々で消費してる分には構わない。
ただ、なんつーか、もうちょっと気を使えよ。
はっきり言ってまわりから見たらキモイってのは確かなんだ。
あなたキモイですよって言ってるのに開き直ろうとするやつらってめっちゃ不気味だぞ。
キモイなら見なければいいじゃん、というためには、
一応相手の心情には気を使ってますよ、害意は、いや脅威はないですよってのは示すべきだろう。
その面ではオタの対応はちょっと不十分だと思うぜ。
限度わきまえず突っ込んでくるイノシシ豚みたいなのは相手にしなくてもいいけど
社会人としての配慮はあってしかるべきだよ。エチケット的な意味で。
おしゃれしろとは言わんから、あんまり公の場でオタオタするな。
いやでも、退会してもデータを残していて復活キャンペーンなんてしているぐらいだから、
退会してようとなかろうと管理コストは変わってないとも言えるじゃないか。
それに、リアルタイムのゲーム通信や、同時接続のトラフィック制御に比べて、
データを「蓄積しているだけ」の部分のコストなんて微々たるもの。
どうせ、退会フラグ立てて個人情報部分だけ埋めて、レコードは残してるから変わらないはず・・・。
処理コストはアクセスしてないのだからインデックスの二分探査時間に影響するだけなので
一人分レコードが増えた場合の探査コストは、ユーザー総数に対して指数関数的に小さくなりゼロとみなせる。
だから、お金かえして（；ー；
http://www.itmedia.co.jp/news/articles/1008/30/news042.html
今回の件で、アトラスが消滅するのではないか。
もしくは、ブランドとしてめちゃくちゃになるのではないか。
そう危惧したゲームファンたちのために、ちょっと調べた経緯を書く。
先に述べて置きたいのは、吸収合併はアトラスの業績が悪い故のことではない。
インデックスホールディングス（アトラスの吸収合併元。以下インデックスＨＤ）の営業利益率は1.8%。これはもちろんグループ全体の数字で、アトラスも含む。
対して、アトラスの営業利益率は8.7%となる。グループ内でアトラスが優良会社であることは明白だし、アトラスの業績は決して悪くはない。
さて、吸収合併に至った経緯を軽く書こう。
２００３年にアトラスはタカラと資本提携し、タカラの連結子会社となった。
参照：http://game.watch.impress.co.jp/docs/20030327/atlus.htm
そのタカラはコナミと資本提携していたのだが、タカラの業績が悪化したため、２００５年にコナミが所有していたタカラ株を全てインデックスＨＤに売却する。
参照：http://www.itmedia.co.jp/news/articles/0504/25/news011.html
インデックスＨＤはアトラスに株式公開買い付けの打診をし、アトラスの了承を得る。
２００６年、インデックスＨＤは友好的ＴＯＢを開始し、アトラス株をかき集め始める。
（敵対的ＴＯＢでは、ここで言えばアトラスの方も株を買い占めるため株値がドンドン上がるが、友好的ＴＯＢではインデックスＨＤが地味に株を買い集めてゆく）
４年がかりで買い集め、２０１０年、今年５月にＴＯＢが終わり、１００％全ての株を買い集め終わる。
満を持してインデックスＨＤは吸収合併に踏み切ったというわけだ。
つまり今回の件は、２００６年からの既定路線であって、「突然アトラスが敵対的買収を受け倒産した」という類の話ではない。
確かに、株式会社アトラスは消滅したが、アトラスというブランドは確実に残っていくし（上述した通り、業績は優秀なのだから潰すわけがない）、今後発売が予定されているタイトルも発売中止ということはないだろう。