 
|
はてなキーワード: スタックとは
第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 練習問題
togetterがchromeが固まるくらい重いのと、書いてある内容に同意できてもエタ東となる4時の組み合わせは気分が悪いので、自分用に。
最初に書いておくと、これは特にpixiv擁護ではない。というより、擁護できる部分は特にない。
pixivを擁護したがっている人たちというのがいて、連日出てくる問題を鎮火させようと頑張っている。
カオスラウンジとズブズブだったpixivも悪の企業であると認めず、pixivは悪くない、pixivは俺たちの居場所だ、と信じて自分たちの立場を守ろうとする。（俺正義タイプ）
本の宣伝をしたいが代替サービスのユーザーがまだ少ない。pixivを宣伝用に使い続けるしかないのからpixivを守りたい。（我欲タイプ）
pixivとかユーザーのことなんて全くどうでもいいけど、批判に対して反対意見を言える俺かっこいい。（自己顕示タイプ）
大体想像できる動機はこんなところ。
メンツは固定しているないが、毎度の騒動で発生源となっているtogetterまとめを網羅的に眺めると、誰が鎮火しようとしているのか分かりやすい。
はてブでいうとb:id:sa_tie、b:id:katsura_1、b:id:tailtame辺りが該当。彼らを駆り立てているものは一体何なのか。（なお、エタ東も方向性が違うだけで同類にカテゴライズしている）
もっとも動機が不純だからといって、成すことが正しければ良い結果をもたらすこともあるし、独善が「悪事」としか呼べない暴走を引き起こすこともある。評価は人による。
pixivの新規登録画面は極めてシンプルで、pixiv idの用途については特に記されていない。（※要改善）
登録するとユーザーにはユニークな数字のidが付与されるので、pixiv idはログイン用のみだと考えている人は少なからずいるようだ。
実際にはpixiv id名でディレクトリが作られるほか、スタックフィード（活動履歴）のid、アカウントを共用するpixivブログや、姉妹サイトdrawr（flashで手書きできるサイト）のidとして利用されている。
pixiv idを外部から見られないものとして、個人名を使うなどする人もいて、問題となったことは過去に数度ある。id変更の機能追加をするという話もあったが今のところは実現していない。
今回の騒動の発端となったのはこのpixiv idが画像の絶対パスから参照可能だ、という最初期から判明していたことを何度運営に要望を出しても改善されないまま放置されたことに業を煮やしたことユーザー達のtwitterである。
これを、「最初期から判明していたことだから今更問題ではない」と擁護する連中が現れた。
「idは最初期から漏洩するような仕様で、スタックフィードなどからidを参照することも可能だ」と判っても問題点を把握できないユーザーが多数いたことで、危機の周知は次段階に移る。
「IDとパスワードを同じにしている人は危ない。プレミアムユーザーならクレジット番号などの登録もしているので危ない。」と危険を訴えた。この辺りから「ただの言いがかりレベル」などと鎮火ツイートが広がる。
現在のPCスペックの技術の向上は目覚しく、家庭用でもハイスペックなPCがあれば簡単なパスワードであれば数分～数十分で破ることもできるとされる。
が、それはメモリ内で高速に試行できるローカル環境上の話であって、web上のパスワード認証に対して必要とする時間は全く別物という視点が抜け落ちていて、とても現実的ではない。
だが、総当たりなどせずとも、簡単な単語やIDと同じパスワード、誕生日などであれば簡単にログインできてしまう可能性がある。
それを、「例えローカル上で10万回/秒でログイン試行できるPCでも、web上のパスワード認証に対しては通信とサーバーレスポンスがボトルネックとなって100回/秒程度のパフォーマンスしか発揮できないと思う。並列で大量にリクエストを殺到させればサーバーが落ちるだけだし、そもそも膨大なオーダーのログイン攻撃が仕掛けられれば、突破するより前にファイヤーウォールが異常を関知するか、サーバー管理者が気付く。そもそもイラストコミュニティサイトに対して逮捕されるリスクを犯して潜入したところで、成りすまして暴言コメントを書いたり個人情報を抜く程度で、不正アクセスのリスクにリターンが見合っていないわけで…。」
などと問題点をすり替えて、指摘する側がさも間違っているかのように発言を繰り返す。
大手ポータルサイトや銀行、携帯キャリア、有料ポイントを運用するネトゲなどであればそれなりに堅牢なログイン構造にするのが当然で、既に大手のお絵描きコミュニティ、しかもカードの支払まで行われるサイトにパスロックがないというのが問題でないはずがない。
admin.pixiv.net他に接続するとグローバルIPからでもログイン認証が出てくるというもの。発覚したのは実は1年も前だという。今回twitter等で公になってからも1時間程度は誰もがアクセス可能であった。
あくまでログイン認証画面が出てくるだけで、ID/パスワードが判明したわけでもなく、webのログイン認証に対するブルートフォースは非現実的なのは変わらないが、「外部からadminツールにログイン可能」というセキュリティ意識の無さが露呈し、大騒ぎとなる。
更に話が広まる際には「adminツールが流出した」「バックドアが仕掛けられた」「ログインにキーロガーが仕掛けられている」「アクセスするとウイルスを仕込まれる可能性がある」「今すぐ退会せよ」など虚実入り乱れた話となる。
普通に考えれば、外部からアクセス可能な状態で晒され続けたという事態が発覚した時点でサーバーを落として対策を取るはずなのだが、隠蔽体質に定評のあるpixivが何のアクションも起こさない為、念のためアクセスを控えるよう呼びかける。
「そこまで大事になっているのであればサーバーを落とすわけで、実害はない」などと見当違いな「俺の脳内のpixivのセキュリティ安全神話」ツイートが擁護派から出てくる。
admin.ads.pixiv.orgに接続すると「It workssl!」と表示されるもの。これがapacheのデフォルト表示「It works!」と異なることから、「何者かに書き換えられたか、運営が謎のミスをしたのか」と疑惑が生まれる。
ads.pixiv.orgは広告関連のサーバーのようだが、侵入された場合は他のサーバーも同様に危険である可能性が高く、「個人情報やカード情報が抜かれる危険性もある」と指摘されると「万が一侵入されていても個人情報が流出する可能性は低い」と根拠のないpixivの言い訳を持ち出す。
カード情報は決済代行会社が保存していると運営から「なぜか」一部ユーザーにメールで通知されていたようで、ここまでの騒ぎになっておきながらサイトトップでも発表しないなど、さらに不信感が募る。
「IDが漏洩する危険性がある」という問題点から、罪のないユーザーが被害に遭うことを防ごうしたものの、サービス開始時からの仕様で改善される望みが薄い。
さらに管理者ページが外部から閲覧できたことは、あってはならないセキュリティ意識、にもかかわらず、「批判は的外れで間違いだらけ」というまさに的外れな擁護ツイートが広まる。
ここまでサンドバックになってて何も発言せずパスロックを実装するpixivはある意味凄いが、その沈黙がさらなる疑惑を生んでいることにいつ気が付くのか。
togetterがchromeが固まるくらい重いのと、書いてある内容に同意できてもエタ東となる4時の組み合わせは負けた気分になるので、自分用に。
最初に書いておくと、これはpixiv擁護ではない。というより、擁護できる部分は特にない。
pixivを潰したがっている人たちというのがいて、連日火をつけようと頑張っている。
大体想像できる動機はこんなところ。
ほぼメンツは固定しているので、毎度の騒動で発生源となっているtogetterまとめを網羅的に眺めると、誰が火をつけようとしているのか分かりやすい。
はてブでいうとb:id:sa_tie、b:id:katsura_1、b:id:tailtame辺りが該当。彼らを駆り立てているものは一体何なのか。（なお、エタ東も方向性が違うだけで同類にカテゴライズしている）
もっとも動機が不純だからといって、成すことが正しければ良い結果をもたらすこともあるし、独善が「悪事」としか呼べない暴走を引き起こすこともある。評価は人による。
pixivの新規登録画面は極めてシンプルで、pixiv idの用途については特に記されていない。（※要改善）
登録するとユーザーにはユニークな数字のidが付与されるので、pixiv idはログイン用のみだと考えている人は少なからずいるようだ。
実際にはpixiv id名でディレクトリが作られるほか、スタックフィード（活動履歴）のid、アカウントを共用するpixivブログや、姉妹サイトdrawr（flashで手書きできるサイト）のidとして利用されている。
pixiv idを外部から見られないものとして、個人名を使うなどする人もいて、問題となったことは過去に数度ある。id変更の機能追加をするという話もあったが今のところは実現していない。
今回の騒動の発端となったのはこのpixiv idが画像の絶対パスから参照可能だ、という最初期から判明していたことをid漏洩だと騒ぎ立てたことから始まる。
「idは漏洩したわけではなく、最初期からこのような仕様で、スタックフィードなどからidを参照することは可能だ」と判明したことで、祭りは次段階に移る。
「パスワード総当り攻撃に対する対処がない、悪意あるユーザーがブルートフォース攻撃を仕掛ければ突破されてしまう」と騒ぎ立てた。この辺りからただの言いがかりレベル。
確かに現在のPCスペックの技術の向上は目覚しく、家庭用でもハイスペックなPCがあれば簡単なパスワードであれば数分～数十分で破ることもできるとされる。
が、それはメモリ内で高速に試行できるローカル環境上の話であって、web上のパスワード認証に対して必要とする時間は全く別物という視点が抜け落ちていて、とても現実的ではない。
例えローカル上で10万回/秒でログイン試行できるPCでも、web上のパスワード認証に対しては通信とサーバーレスポンスがボトルネックとなって100回/秒程度のパフォーマンスしか発揮できないと思う。
並列で大量にリクエストを殺到させればサーバーが落ちるだけだし、そもそも膨大なオーダーのログイン攻撃が仕掛けられれば、突破するより前にファイヤーウォールが異常を関知するか、サーバー管理者が気付く。
そもそもイラストコミュニティサイトに対して逮捕されるリスクを犯して潜入したところで、成りすまして暴言コメントを書いたり個人情報を抜く程度で、不正アクセスのリスクにリターンが見合っていないわけで…。
大手ポータルサイトや銀行、携帯キャリア、有料ポイントを運用するネトゲなどであればそれなりに堅牢なログイン構造にすると思うけど、お絵描きコミュニティにパスロックがないというのが即叩き材料になるとは思えないが。
もちろんパスロック自体はないよりはあった方が安心できるのは間違いない。でもセキュリティ専門の人ならまずhttpsでログインできないことを指摘するよね。
admin.pixiv.net他に接続するとグローバルIPからでもログイン認証が出てくるというもの。発覚してから1時間程度はアクセスが可能だった。
あくまでログイン認証画面が出てくるだけで、ID/パスワードが判明したわけでもなく、webのログイン認証に対するブルートフォースは非現実的なのは変わらないが、「クラックされた」「ロジックボムが爆発する」など大騒ぎする。
更に尾ひれが付いて「adminツールが流出した」「バックドアが仕掛けられた」「ログインにキーロガーが仕掛けられている」「アクセスするとウイルスを仕込まれる可能性がある」「今すぐ退会せよ」など騒がれる。
普通に考えれば、そこまで大事になっているのであればサーバーを落とすわけで、実害はないのだろうな、と思うわけだけど「既にハッカーに乗っ取られていて、運営は手も出せないのでは」とまで言い出す人まで。
アイマス2に男キャラが追加されたのをきっかけに「可能性を生み出しただけでアウトなんだよ！」とネガキャンしまくっていた人たちを思い出す。
「セキュリティ問題とギャルゲーを同一視するのは間違いだ」という指摘は正しいけれど、ハッカー映画に影響された「俺の脳内のセキュリティ問題」なんてゲームの世界と大差ない。
admin.ads.pixiv.orgに接続すると「It workssl!」と表示されるもの。これがapacheのデフォルト表示「It works!」と異なることから、「ハッカーに書き換えられた、侵入の痕跡だ」と大騒ぎする。
ads.pixiv.orgは広告関連のサーバーのようで、万が一侵入されていても個人情報が流出する可能性は低いのだけど、「個人情報がマニアに売られている」「カード情報も抜かれている」と騒がれる。
実際にはカード情報は決済代行会社が保存しているようで、アカウントに不正アクセスで潜入しても見られるのはカード末尾4桁のみ。
「IDが漏洩した」という新たな材料で騒ごうとしたものの、実は既出の仕様だったためにパスワード総当りの「可能性」によるセキュリティ問題に切り替える。
そこから管理者ページが外部から閲覧できたことを、管理者権限が奪われた「可能性」があると話を大きくし、どうも全体の根拠が怪しいと分かると「何も言わないpixivは不誠実だ」と批判する。
ここまでサンドバックになってて何も発言せずパスロックを実装するpixivはある意味凄いが、それが付け入る隙をネチネチと探すネットの暇人クレーマーたちの加虐心をくすぐって余計な火種を生んでいることにいつ気が付くのか。
追記：セキュリティ関連については悪意を持ったユーザーに狙われる可能性があることから、表に告知を出さないというのがpixivのポリシーらしく、直接メールで問い合わせれば返事は受け取れるそうです。
不安な方はデマかもしれない情報を無責任に広める前に、直接運営に問い合わせましょう。もちろんパスワードを変えるなど自衛も重要です。
(http://www.drk7.jp/MT/archives/001769.html のマネ / http://anond.hatelabo.jp/20110515004216 の続き / 昔も同ネタで書いてた → http://anond.hatelabo.jp/20101218150419 / 書きおわってから http://anond.hatelabo.jp/20110515220351 に気がついた。この記事よりはるかによみやすいのでおススメ)
評価者の属性によっておおきく変りそうなので一応こちらも受けて立とう。
iPod Touchとhtc EVO wimaxを使ってみた差を独断と偏見で語ってみたいと思います。
まず結論から。
比ぶべくもなく圧倒的な差で"僕的には" androidの勝ちです。ただし、iOSユーザにはその意味は多分わからないでしょう。誰にでもおススメできる道具じゃありませんし、そこまでケータイに求めないのであればiPhoneでもガラケーでも好きなもの使えばいいと思います。
androidをかなりはやい時期から使ってたこともあり、iPhoneユーザから「androidいいですか？ / androidはコレありますか？」 と人に聞かれることも多いのですが、「androidいいけど、iPhoneでいいならiPhoneのほうが良いよ」あるいは「androidにiPhoneと使いかた違うから、同じように使おうとしてもそんなソフトないかもよ」と答えます。今後の機種変についてはiOS以外なら試していきたいですが、しばらくはandroidを使うことになると思います。
一方、別の技術も知っておくという意味で、オモチャとしてiPod Touchを買ってみました。まぁ、ムービープレイヤーとしてはまぁまぁ良いので、機内のお友にしばらく使うことでしょう。
とはいえ、自分の母親みたいなど素人には「ガラケー使っとけ」と言うでしょう。iTunes用母艦のメンテも、androidのメンテもしたくないよ。
さて以下詳細。
スクロール速度についてはiPod Touchのほうが良い場合が多いです。ただ、htc EVOも言うほど劣っているわけではないです。むしろ、iPod Touch(iOS)でデフォルトのアニメーションで「目がごまかされてる」部分が気になります。アプリの切り替えやインテントによる連携なども含めて、androidのほうが「最短距離を進む」快適さがあります。てか、スクロールなんて引っ掛からなきゃいいでしょ。(xperiaが引っ掛かるのは多分メモリが足りないんじゃないかな)
アプリ込みで考えると、iOSは不安定なものがおおい。これはTouchだからかもしれないが、フォアグラウンドのアプリが突然不安定になっていきなりホームに戻される。これはいただけない。androidの場合はちゃんとエラーダイアログが出て、必要に応じてその内容を作者にフィードバックする仕組みがあるため、ちゃんとしたアプリの安定度は日々あがっている。GCがかかると時々重くなることもあるが、EVOでは気になるほどでもない。
確かにアプリ自体の作り込みはiOSの方が高い。しかし、iOSは「ちょっとしたこと」でも有料アプリな上に、「ちょっとしたこと」が全然使用感の向上に寄与しない。androidの場合、ちょっとしたアプリもインテントのおかげでさまざまな活用法が可能になるので、ボランティアレベルのプログラムでも戦力になる。
例えばiOSユーザの話を聞くと「○○ってアプリは神！ Evernote/read it later/ナンチャラカンチャラと連携できる！」みたいな間抜けなことを言っているんだが、Androidはそもそも連携できないアプリがカス以下扱い(昔のustreamアプリとかね)。具体的には、twitterアプリでshort URLを展開する機能がついてて便利！ とか言われても、「でもそれ開いてサファリで開いてさらにニコ動アプリ起動して」とか阿呆臭くてしょうがない。どのアプリからでもURLを開こうとするとちゃんと展開→確認の上、最適なアプリで直接開く、というところまで意識的なアプリ切り替えなしで行けるし、見終ったら戻ることも簡単。
あと、有料アプリのお試しができるようになったのが地味に便利。期限が15分になっちゃってちょっと切ない…。お試しができないApp storeで何度か外れアプリを買って以来、iOSで有料アプリは買ってない。
EVOの画面でかすぎ！ 手が届かない。通勤中はtouchで我慢することもあります。あと、pdfを読む用にtouchは便利。
とはいえ、スライド読む用と論文読む用で別アプリになってしまい、管理が面倒なのが減点 -- dropboxから送り込むコースとmendeleyから送り込むコースとがあって、さらにわけわからん。あーこれは「画面」の問題じゃないや。
これはEVOは最悪。まぁ、ひどい時にはwimax, 3G(通話用), wifi(テザリング用)と3つも無線機動かすのであきらめてる。ipod touchの持ちの良さは機内のお伴には最適。
touchのカメラはおまけなので評価せず。とはいえ、skype for androidがフロントカメラ使えないので、skypeでvideo chatするときはiPod Touchを使います。てか、iPhoneユーザの「カメラ」ってデジタル処理(instagramとか)ばっかりで気持ちわるい。ちゃんとしたカメラで撮った写真以外を「作品として」人にみせびらかすために「一見オサレ()風に加工」とか、ちょっとねぇ。
あまり気にするほどの耳は持ってない。本体スピーカーは、本体質量がデカい分かもしれないがEVOの圧勝。
wimaxを使いはじめたら元には戻れません。softbank？ 使ったことないので評価は控えますが、あの社長は嫌いです。本業おろそかにして目眩しばかりやってるタイプでしょ？
元blogで言及されなかったandroidの特徴が3点あって、「ハードウェアボタン」「連携性」「端末の自由度」。ハードウェアボタンは、「とりあえずここ押す」というボタンなのでとても大事。特にandroidで大事なボタンはbackボタン。つまり、スタック上にさまざまなアプリから取り出してきたactivityがシームレスに重なってて、終わったらそこに戻れる、という環境と、それに適したアプリ/使い方を見つけられないと、androidは不便なだけだと思う{{多くのiOSユーザがこれがわからずに、単体アプリで何でもやりたがるのが不思議である。Emacsか？}}。連携性も同じで、インテントによるアプリを結合した使い方って、確かにちょっと使いこなしが必要な点。ただ、手に馴染むと快適さが半端ない。「端末の自由度」についてはいわずもがな。まだまだ不十分だけど、「ワンセグが欲しい」「おサイフケータイ」「防水じゃなきゃヤダ」という要求に応えられるのはandroidであって、iPhoneではない。
iOSは単体では何もできず、何するにしてもiTunes{{それも「特定のPCの」iTunes！ 糞！ デスクトップに同期させてると出先のノートで何もできやしない！}}が必要になるのに対して、androidは単独で/クラウドと結合することで成立する環境になっている。まさに Apple と Google の思想の差がそのまま反映されているのは当たり前。iPod Touchはあくまで「Mac/PCのオマケ」な端末であるのに対して、androidは僕の中で「仕事の道具」という位置付け。それぐらいの違いを感じる。
僕は基本的にコンシューマ系OS(Macも、Windowsも)大嫌いな偏った人間ですが、この手の端末は金太郎飴みたいに同じような道具になるのではなく、手になじんだ一人ひとりにスペシャルな道具であるべきだと思ってる派{{カウボーイは、馬は捨てても鞍は捨てずに持っていく by HHK}}。そんなわけで結論に戻って、僕的にはandroidの圧勝なわけでした。ただし、他の人には、「androidは手になじんでくる感じがおもしろいけど、困ってないんなら別にガラケーでいいし、パソコンに慣れてるならiPhoneでいいんじゃない？」 と言ってます。こんないい道具、他人と共有してなるものか（笑）
情報をスタックしたり、マーキングするような使い道をする人間が多い。
ホッテントリに入った記事は信憑性があるものが多く、エントリページの批評を合わせて読むことで真偽の判断はやりやすい。
モヒカン族が恐れられていた頃は縄張りであるウェブに入り込み、使い道を誤った人間を消毒して回っていたが、ウェブが発達した今では村人たちはコミューンを作り自己擁護する術に長けているために空気になっている。
震災に乗じて自分の価値を高めるため、被災地や被害者に深い同情を示したり、自分たちにやれることがないかと模索するような、よく言えば前向きな、悪く言えば偽善に満ちた情報が溢れた。
さらに厄介なことに情報強者を名乗る人間が己のフォロワーに向けて虚実混じった情報を全て真実が如く喧伝した。
フォロワーたちは裏を取らずにそれを拡散し、それを見て自称情報強者は悦に浸る。自称情報強者のほとんどは自己顕示欲混じりながら善意でやっているから性質が悪い。彼らを説得する術はなく、何度炎上しても数百～数万のフォロワーたちが離れない限り、彼らはデマを流し続ける悪夢のようなツールでもある
twitterは一次情報の交換ツールとしては最も有用だが、真偽不明な二次情報や明らかなデマをも拡散してしまう点は欠陥でしかないのでそういう目的では利用しない方がいい。
twitterが「被害者に同情を示すことで自分の価値を高める」陽のツールならば、2chはその陰と言えるツールである。
「震災特番よりアニメを流せ」というような自己の価値を貶めたり、不謹慎厨や不寛容厨を呼び寄せ炎上するような恐れがある本音を垂れ流すには打ってつけのツールである。それでも阪神大震災や東海村臨界事故の頃の不謹慎発言と比べると毒気は抜け、一方で独善的な政治的主張が増えた印象がある。
情報交換としての地盤は最も脆弱だが、スレッドごとに網羅的に情報がストックされるメリットはある。ただしその中には多数のデマも含まれる。特に2ch世論に迎合する政治主張と絡めた悪質なデマは広がりやすい。また2chに書かれた適当なデマをソースとしてtwitterにて拡散されるという状況はしばしば見られた。
彼らは今回の悲劇を利用して、視聴率主義のために危機を煽る、旧来メディアの醜悪な部分が濃厚凝縮されたような記事を大量生産した。
2chまとめブログやネットメディアには報道者としての義務責任はなく、ただ今回の震災を利用してアフィリエイトで利益を得ることだけにある。それがデマであろうが誇大情報だろうがセンセーショナルな内容でPVを稼ぐことができればそれでいいのだ。
アクセスを稼ぐためなら手段を選ばない。ネット世論に迎合するために、誤読やデマを駆使して特定の人種・政党や無実の人物へのヘイトを煽った。
ニコニコ生放送は字幕の存在によりまともに機能しないかと思われたが、政党叩きやメルトダウンを必要以上に煽るコメントには検閲や規制が入る（しかもコメントが検閲されたことに当人は気付かない仕組み）のためにそこまで荒れていなかった。ただしそうした処理がなされていないと思われるニコニコ実況は荒れ放題になっており、別物とみなした方がいい。
仰る通り、ハードウェアアーキテクチャについては知らないですね（スタックやヒープがどうとかは表面上わかりますが）。
というのはズバリそこが非常に嫌い（肌に合わない）で、意図的に避けてるからです…。アセンブラの本とかも持ってますが、どうにも読めないですね…。
当然Cは嫌いです…。C++がギリで、できればRやpythonレベルの抽象度で全部済ませたい派です。が、さっきも書いたようにちょっと踏み込むとすぐ低レベルの話が出てきますね…。
最近はGPUだの並列化だのを使いこなさないと生きていけない感じですし。
関数型言語くらい抽象化して数学っぽい雰囲気になってると個人的には嬉しいですねw
残念ながら、その読書履歴だと、ここで言う「原理」には辿り着いてないと思います。挙げられた本はどれも計算に関する抽象概念からさらに上の、アーキテクチャを言語化する部分に関してです。それらも原理と言えば原理なのですが、そこからスタートしてもC言語でのプログラムは書けるようになりません (Rとかなら書けるかもですが)。
ここで言う『原理』すなわち、なぜ char x[sizeof(int)]; がダメなのか、という理解につながる原理は、「レジスタ」「ALU(CPUの中の計算ユニット)」「バス」「メモリ」といった原理です。メモリアクセスやヒープ・スタックの使い方、アセンブラといったような話です。
なんで言語の約束事の上っ面を覚えるのが難しいか、というと、「原理」を理解していないからなんです。原理を理解せずに約束事だけ覚えたって使えません。曖昧で良いので、プログラムを動かしているときにどのようにメモリが構成されどのようにアクセスされるのかを知る努力をして下さい。その上でC言語をよく見ると、いかにCPUアーキテクチャに近い所で記述されているのかがわかるようになると思います(*)。
それだけで、目の前の箱がどう動いているかの理解度が劇的に上がる筈です。
*: 理解したつもりになるだけですが、現実のコンパイラもCPUも、そのさらに7歩ぐらい先に行っています。ですが、この領域は進めば進むほど泥沼なので、「あ、Cって高級アセンブラなんだな」という所で実用上は十分だと思います。てか、偉そうなこと言っている私(某大学博士課程在籍、要は増田で現実逃避中のダメ学生)も、そこから先はちゃんと理解していません…。
高負荷になるとカーネルコールから特殊なエラーが帰ってくるとか
単体じゃ出ない問題もあるし
人が違う、会社が違うっていうところから来る意識違いとか、結構テストしてもでるし。 結合のデバッグはなくならんよ。
あとは、引き継いで、数年後に違う人が改造するとかのときに、
あまりにも、STLガツガツだよ改造しにくい時があるんだよ。
数年後の改造って、当初の設計になかった追加機能だから、設計上できなくて結構改造ってときに
ベタベタに書いてあるか、STLガツガツに書いてあるかとか結構違ってくるしね。
メソッドが細かすぎるとコールスタックが深くなりすぎて、それはそれで追っかけにくいというのもある。
時間が経つと、書いた人がもういないとか、よくあるしね。
そういう時に、改造しやすくデバッグしやすく行儀よく書いてあるとすげー助かる。
最近は、年取ったのもあって、難しい部分は
＞JAVAを最初に学んでその後に現場で実際に用いるであろう言語（例えばPHP+SQL）を習得するといったルートは現実的なのだろうか？
いろいろ言う人はいるけど、PHPでも、問題ないよ。
ただ、欲をいえば、PHPのモジュールをC++で書く拡張機能あたりをちゃんと勉強しておいたり、ちゃんとコードをチューニングして行けば勉強になると思う
SQLはただ使うんじゃなくて、データーの正規化やインデックスなんかをきちんとマスターしておくと、違う感じ。あとは、ストアードプロシージャ
＞上記のケースで前段階として学ぶ言語はどの程度のレベルまで到達する必要が有るのか
というか、本気で学ぼうとすると、トランジスタから始まって、フリップフロップ、レジスタ、アキュムレーター、バスの配線、クロックというハードの構成がどうなっていて、
それに対応するマシン語があって、それがニーモニックに変換されて、
そこにスタックという概念が持ち込まれて、レジスタをスタックに退避するという概念が生まれて、関数コールができて、C言語が生まれて、さらにそこにthisポインタをコンパイラが自動補完して関数テーブルを保管することでオブジェクト指向というか、C++ができている。そこに（Cの世界に）BNFなどの構文があって、それを構文ツリーにするBisonなんかがあって、PerlやPHPができている。
という、なぜC++のオブジェクトはポリモルフィズムができるのか？というソフトからハードまでを一貫して知る必要がある。
そこまで理解していると、コードのレベルは確かにハンパないレベルにはなるけど・・・。正直、業務には必要ないというか、そんなクオリティーの仕事が少ない。
やりたければ、やってもいいけど、PHPからやったら？そして必要になったらPHPをCで拡張するという形でCに入ると良いと思うよ。
やりたい言語をやるのが一番だ。
でも、本気で知りたいなら、死ぬ気でアセンブラをやれ。それがすべての始まり。
わりといえば、普通に大学入って、授業を真面目に受けた方が早い。
＞そもそも実際に現場で使用することを想定した言語で、今から学ぶのに本当に適しているのは何か？
PHPでいいでしょ。大差ない、むしろ、自分が気に入った言語で、どれだけコードを沢山書くか。日々の鍛錬。
ちなみにWeb系といわれたから、ライトウェイトな言語を中心に考えたけど、つぶしが効くのは意外とJavaやC++であることも。書いておく。
http://d.hatena.ne.jp/faith_and_brave/20100220/1266673222
まず第一にエンタープライズでの開発が考慮されていない。エンタープライズの開発だと１００人２００人 マスタークラスから ジュニアーまで様々なレベルの開発者が携わる。
その中で重要になってくるのは可読性。
はっきり言って、歴史的な可読性を犠牲にして効率が上がるならともかく、気持ちの問題程度の効率では意味がない。
第２に
スレッドとファイバーの違いぐらいわかれ、わざわざスレッド起こしたらコンテキストスイッチにどれだけコスト食うんだよ。
関数コールするとレジスタとかが、スタックにPUSHされるんだよってわからん奴が、IF書くなと同じで、スレッドってコンテキストスイッチの塊なんだよってのがわかんないのに下手にスレッド書かせるな。
３にラムダ式・・・いらん・・・必要なのは曲芸じゃない、可読性。可読性を犠牲にして早くなるならともかく・・・
４にforeachではlastを変数に取るな。途中でReallocしたり、eraseしたりしたときに余計なバグを生んで面倒だ。レビューの時も邪魔。速度？速度が必要な背景でSTLのVector使うな。配列使うかポインタ使え。
なんつーか、トータルで見て、次はC++と各種OpenCLとかGLとかのライブラリの集合だな。C++0xはまともに使う人もいなさそう。正規表現とかもライブラリ使えば良いし、そもそもC系列ならBisonとかLRとかだろうと。C系列の使い手ならBNFを使え。正規表現使いたければそれこそ、Perl使え。
俺の住む世界はアイティーとやらに支えられているらしい。
アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。
そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。
昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。
パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。
楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。
研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。
現場に出て、本番機に触った。
３０年間親会社を支え続ける偉大なシステムの中身を、わくわくしながら覗いた。
そこには、俺の求めていた世界とはまったく違うものが広がっていた。
俺が産まれる前から、入れ替わり立ち替わり何人もの手によって継ぎ足されたロジック。
何千行にもわたって、似たような処理が何回もひたすら繰り返される似たようなモジュール何十本。
1993年に行う臨時処理のロジックが、今もコメントもなしに埋め込まれている。
仕様がわからなくなれば、キャビネへと走って、黄ばんだ方眼紙に鉛筆で書かれた仕様書を探し、
そして修正履歴のみが書かれているのを確認して肩を落とす。
半年後に臨時で行われる業務に対応するため、いくつかのモジュールについて、処理可能なユーザーコードをひとつ、条件に加える。
与えられた期間は２週間だった。ずいぶん長いなと思った。
何枚もの設計書を書いた。つまり、方眼紙状のExcelテンプレートに同じ文章をコピペした。
追っていったモジュールはどれも、ヒープもソートもメモリ管理も論理演算も出番がなかった。
あるのはただ、IF文とMOVE文とばかりだった。ソースの難易度は使われている命令の数とは関係ないことを学んだ。
テストデータを作るため、階層型DBを何回も辿ってデータをアウトプットさせるモジュールを書いた。資格試験で学んだSQLは、無用の知識だった。
協力会社への仕事割り振りやユーザー対応に毎日忙しそうだった上司が、夜遅くまでの残業続きでくまのできた目を皿のようにして設計書をレビューした。
ロジックを丸々コピペしてソースを修正し、コンパイルし、実行した。
２週間はあっという間だった。
俺のせいで、半年後以降は使われないロジックがソースにまたひとつ増えた。
今回の対応については、Excel方眼紙にレポートをまとめて共有ドライブに入れておいた。
だが共有ドライブの検索には時間がかかるし、Excelシートの中身となれば検索から漏れることも多い。
きっと誰にも読まれないだろう。
２バイト文字が使えない関係上、原則、ソースにはコメントはあまり入れられない。
数年後の新人はきっと、俺の書いたモジュールを見て「このロジックは何だ」と首を捻るんだろう。
数年後の俺はきっと、今回のレポートを共有ドライブから探し回って新人にパスを教えてから、
協力会社の管理に追われる作業に戻って目の下にくまを作るのだろう。
俺がやりたかったシステム開発って、こんなものだったのか。
俺は部署の中で、俺の望む仕事を探し続けた。
先輩たちは忙しくて誰も興味を持ってないけど、自動化できる作業はいくらでもある。
よく使われるExcelシートを改造し、定例作業をクリックだけでできるようにした。
ExcelVBAとはいえ、書いていて心地よかった。引数が明確な関数と変数のスコープと全角文字があったからだ。
COBOLで打つプログラムより、控えめに見て100倍くらいの生産性を発揮できていたと思う。
先輩たちは喜んでくれたが、ただし俺の仕事を、あまり仕事とは見なさなかった。
それでもよかった。業務時間外は俺は相変わらずスクリプトを書いていた。とても楽しかった。
VBAから入って、WSHなんてものを知り、やがてJavaScriptを学び、ネットで資料を探し、はてなを知り、はてブでWeb技術についての記事を読みふけった。
知れば知るほどに、どんどんCOBOLが、メインフレームが嫌いになっていく。
先輩は誇らしげに言う。システムはたいしたことをやっていない。業務知識こそが大事なのだ。
ユーザーより詳しく業務を理解し、適切に提案し、設計する能力。
協力会社を率いて、わかりやすい文書で指示を行い、スケジュールを調整する能力。
人を動かすぶん、責任も大きくやりがいもある。優秀な人材こそが我が社の強みだ。
そんな人材が育つよう、我が社は安定して働ける環境と福利厚生を整えている。
ああ、そうだよ。先輩、あなたは正しい。
俺だってメインフレームの信頼性のすごさはわかってる。
密なユーザーとの関係から生まれるシステム子会社としての強みも認識してる。
それだけじゃない。社内環境も悪くない。給料もいいし休みも取れるし先輩は優しい。
ここは、いい会社だ。
けど駄目なんだ。
３０年前のシステムを枯れた言語でツギハギする仕事じゃ、俺の心はやっぱり満たされない。
ユーザーの業務知識ばかり身につけたって、俺自身の人生には、いいことなんてない。
俺が求めていたのは、この仕事じゃないんだ。
社内の誰も、TumblrもTwitterもやっていない。ライフハックなんて聞いたこともない。
Joostやモバゲーや２ちゃんねるが社会に与える影響について誰も語れない。
休日はゴルフや酒に興じている。自宅にPCを持ってない人までいる。
おかしいことじゃない。普通の人たちだ。
それどころか彼らは、仕事とプライベートを切り分けている、立派な人たちだ。
でも、やっぱり俺の生きていきたい世界は、ここじゃないんだ。
たぶん俺がいるのは極北なんだろう。
ここが、人月計算とExcelとスーツの世界というやつなんだろう。
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。
ちくしょう。VS2008 がやられた。
数時間ほどコーディングしていると、IDE のエディタで日本語入力が出来なくなる。
なんだよもう。なんだよもう。なんだよもう。
俺は Windows Me が好きだった。プログラムにバグがあれば、すぐにぶっ飛んでくれるからだ。そしてバグさえ無ければうまく動いてくれた。皆が言うほど Me はドジッ娘なんかじゃなかった。繊細だっただけだ。皆が「Me がまたコケた」と言うたびに、やれやれどんだけ無茶な使い方をしてるんだ、付き合い方がなってないな、とせせら笑っていたものだ。全裸で。
ところが NT 系列はどうだ。プログラムにバグがあっても、潤沢なリソースが勝手にバグを隠蔽しやがる。明らかにスタックあふれてんのにジッと黙ってビバノンノンしている奴の姿を、俺は何度か目撃した。GetMessage() はエラー値を返さない。ウィンドウは表示されない。ただただまったりと、たこルカ★マグロフィーバーを歌っているだけだ。そしてある時突然、どういうルートを辿ったのか svchost.exe がぶっ飛ぶという面白いオチがつくのだ。させ子のくせに。させ子言うな。すいません。
それはともかく、これ、再インスコしかないなあ。。。
ちがうにょー
デバッグに梃子摺る人が初心者に多いわけは、主に次の３つに起因するにょ。
エラーメッセージの見方を知らないからエラーメッセージを全く見ない。エラーが出ている場所と内容まで事細かに記してあるコンパイル時エラーメッセージや実行時スタックトレースを前に絶望してしまい、慌ててソースコードを１から読み直してしまう。特によく耳にするのが『どこが悪いのかわかりません』だけど、数行のエラーメッセージに答えがずばり書いてあることがほとんどだったりします。
特にプログラミングに慣れていない初心者が陥りがちなのが、制御フローばかりに目が行ってしまい、制御フローから類推できるデータフローには気を配らないという現象。例えば値「１」を返す関数が「２」を返してきてしまった。確かにそういう場合には制御フローを辿ることも重要だけど「２の源流をたどってみる」ことをすれば、意外とすんなり原因が見つかることも多かったりです。
見たままの文字にばかり注意してしまい、例えば半角空白と全角空白とタブを見分けていなかったり、他にも行末に１個空白が紛れていて「なんで上手く処理されないんだ」と悩んでしまう人が意外といる。他にもコンパイル時エラーで多いのが ; の有無だったり () の対応だったり。原因の目星がついても、最後の最後で躓くのはおおよそこういうポイント。慣れればぱっと見で気付くことなんだけど、このあたりが前述２つの理由と相まって、意外と疎かにされやすいところなんだよね。
総じて、デバッグを出来ない初心者に共通する原因は「結果から原因を探ることに慣れていない」ということに集約されたりする。そもそも結果を見ていなかったり、結果から原因を逆算する手法を知らなかったりするのが、「慣れていない人」というわけです。
爆発の基準点はわからないが、男は一度爆発したら初期化されて全部忘れる、女は爆発しても多少圧縮されるだけで初期化されずスタックは積み上がり続ける、といった感じかと。
IT業界に未経験で中途入社して1年弱の人間ですが、ネットワークとデータベースはサッパわかってません。
コンピュータの基本的なところ（論理回路から始まって云々カンヌン）やハードウェア周りもほぼわかってません。
普段の仕事は主にソフトウェアを作ることで、ネットワークorデータベース関連のソフトには手をつけてません。
そうは言っても知らないとヤバいなーとは思っていたので
http://www.amazon.co.jp/dp/4764902842/
http://www.amazon.co.jp/dp/4891003383/
これらをとりあえずポチりました。あと「ネットワークはなぜつながるのか」も持っていたはずなので読もうと思います。
情報理論では
http://www.amazon.co.jp/dp/0471241954/
がいいらしいんですが、高くて躊躇してます。
どのように勉強していったらいいでしょうか。
言語は主にC++(最初オブジェクト指向のオもわかってなかったので苦労しました)です。
CはC++に入る前にK＆Rとオーム社の上下巻の本を読んで一通り勉強しましたが、今ではオブジェクト指向じゃないとまともなコード書く自信ありません。
LINUXは使えますが、emacsのキーバインドは全然使いこなせないです。viとか使えないです。つまりその程度です。
二分探索とかキューとかスタックとかバイナリツリーとかリストとかソートの基本的なデータ構造とアルゴリズムは一応勉強しました。全て実装したことがあるわけではありませんが。
C/C++にいくつか思うこと （ちなみに、プログラマ始めたのはCができた頃でC++よりも私のプログラマ歴の方が長い）
Cはポインタ というか、ポインタを使いこなすことで、チューニングしていく言語だから ポインタ使いたくない＝チューニングしたくない
って人は他の高級言語で良いと思う。ただ、動画などの処理をC/C++又はアセンブラ以外で書く人というのは、あまり聞かないので
速度が必要＝C/C++って事かと思う。
昔、全くチューニングしていない、CとJavaを比べて同じ速度だからJavaでもOKというレポートを読んだことがあるのだが、あれは酷かった。
Ｃはチューニングしたときに、もっとも伸びしろが大きく、必要な場合アセンブラと並記できることで、ほぼアセンブラという領域まで
チューニングできるところが魅力。その際、ポインタは無くてはならない。知っておくべき技術。
繰り返しになるけどチューニングしない人には意味がない言語と言われればその通り。
また、ポインタだけではなく、レジスタについても知っておくとＣでの伸びシロが大きくなる。
そして、少なくともアセンブラレベルでのＰＵＳＨ，ＰＯＰ，ＣＡＬＬは覚えておいた方がよい。
関数コールをすると、レジスタ類の待避がアセンブラレベルでは走り、その上、スタックに引数や返値を積んでジャンプするという
ものすごく遠大な処理がアセンブラレベルでは走っているが、Ｃレベルでは１行の関数コールに見える。
という事を理解しておくと、Ｃ＋＋でのインライン関数の重要性や、再帰関数が実行時にはかなり重い理由が頭の中に浮かんでくる。
こういう言い方をすると、最近はＣＰＵが早いから大丈夫とか言う人が多いが、じゃぁＷｉｎｄｏｗｓ Ｖｉｓｔａは売れましたか？と聞きたい。
少なくともチューニングが必要な事もある。必要ないこともある。という事で選択すれば良いと思う。
たかだか、数行のスクリプトでチューニング不要ならそりゃ、Ｐｅｒｌつかうさ
参考までに書いておくと、個人的感覚ではＣ＋＋はオブジェクト指向言語ではない。
アセンブラにまで行き着く Ｃ言語を大規模開発する時に最低限必要となる抽象化をするための言語
そのために、まともにＯＯＰで設計するとＣ＋＋では重くなる事が多い。いかに、崩せるかがキモ。
またＣ＋＋使いか？エセＣ＋＋使いか？の見分け方は
constを正しく使えるか？参照を正しく使えるか？ vtableの説明ができるか？
という質問に正しく答えられるか？で見分けると結構見分けがつくと思っている。