 
|
はてなキーワード: マシンとは
ああ、今じゃあメモリ2GBで32bit WindowsってんでもうDisられちゃうんだなあ。
おじさんの新入社員のころはWindows2000用のソフトウェアをWindows MEのメモリ128MBのマシンで開発しろって言われたよ。
VC6はそりゃあもう遅かったねえ。
しまいにゃHDDの基板上のチップがパッケージ不良で大規模回収になって、ロットが対象のものだって発表される直前にクラッシュしたのさ。
おじさんがその会社にいたくなくなったのはそれが最初だった。バックアップ用のHDDもなければ、CVSなんて便利なものも無かったから、自腹で購入していたノートパソコンにこっそり移していなければ、ソースが全部クラッシュしていたところだったなあ。
そういやCVS使いたいって言ったらなんか知財の関係の人に申請書を出して許可を得なくちゃいけないとかで面倒くさすぎて諦めたこともあったなあ。ie以外のブラウザも禁止だったなあ。アレも禁止コレも禁止って言った割にはcode redとか感染しまくってて笑えたなあ。
某社内でのソフトウェア技術者について書きたくなったので書いてみる。
まず、そもそもプログラミングは下請け or 子会社がやるものという認識。それを、最近本社でもソフトウェア技術者を採用し始めたけど、やっぱり低く見られがち。プロジェクトの開発リーダーは必ず電気回路の人だし、外部との折衝もやらせてくれない。工場の製造用ソフトだってハードウェア技術者が無理して書いてる。
周りのプログラマーのレベルも低いよ。自分の周りがそうなだけかもしれないけど、C言語以外できない人多いし、ポインタはおろか struct と union の違いも認識していない。環境がローレベルなのか、仮想メモリとかいう考え方もない。 Windows しか使ったことない人ばかりだし、簡単なコンパイルエラー直すだけで数時間がかり。バグ管理はもちろん Excel。ヘッダファイルの define 一覧が Excel に表としてまとめられていて、手動で同期取ってたりする。
あとパソコンに対する考え方が古いよね。未だにCADを17インチディスプレイで書いてるし。今年会社で導入標準モデルになってるパソコンはメモリ2GB, HDD 320GB しか積んでない。マシンに投資するのは無駄という考え方が伝わってくる。スペックアップを主張しても「昔はもっと遅かった」で終了。
デスマーチを避ける考えもないかな。デスマーチを乗り越えたのが武勇伝として語り継がれる。俺何日も徹夜したえらい、みたいな。
そんなくせして、「Apple は大した技術力がないけど、アイデアがよかったから iPhone や iTunes がヒットしてる」と言ってる。まずいね。
全身が痒いし、くしゃみが出るし、鼻も出る。
というか、その症状が止まらない。花粉症の酷いのが襲ってきた感じ
まぁ、もともとアレルギー性鼻炎持ちだから、それが酷くなるというイメージかも。
下手をすると1000円を切る値段で置いていたりする。
あの手の「大吟醸」は、米、米麹以外に「醸造アルコール」を添加している。
たぶん、その「醸造アルコール」に当たったんじゃないかと思う。
「醸造アルコール」はやっぱり曲者だなぁと。つくづく思った。
大方ロクでもない原料でアルコールを作ってんだろうなぁと……。
まぁ、飲みたい人は飲めばいいんだと思う。安いし。
「オマエただのクレーマーじゃねぇか」という批判は当然あるだろう。
それは甘んじて受け入れる。
つーことで、アレルギー持ちの人は、「醸造アルコール」入りの「大吟醸」は気をつけた方がいいですよ、と。
品名挙げると「越○桜」、「北秋○」辺りですよっと。
第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 練習問題
国民に等しく医療を提供する－－。そんな理念に基づき、１９６１年に創設された「国民皆保険」から５０年。だが、かつて世界一とももてはやされた日本の医療は、疲弊著しい。右肩上がりの成長期はとうに過ぎ、公的保険は低迷する経済にじわじわむしばまれている。節目の年に、「安心」が失われつつある現実を各地に追った。【鈴木直、山田夢留、山崎友記子】
◇長年の「裏技」容認
「６５００万円ですね」。札幌市の建設業社長（６２）は、社会保険労務士からそう言われて目をむいた。
全国建設工事業国民健康保険組合（工事業国保）で起きた１万人超に及ぶ無保険問題。厚生労働省は昨年９月、無資格で同国保に入り、保険料を逃れてきた事業主らは「時効限度の過去２年に納めるべきだった医療と年金保険料を払う」との清算方針を決めた。６５００万円は多い時で３０人を雇いながら原則個人事業主の同国保に加入していたことへの「代償」だが、社長は「冗談じゃない」と吐き捨てるように言う。
事態を招いた責任は、一義的には工事業国保側にある。組織拡大を競い、「保険料が減るから」と次々無資格者を誘ってきた。札幌市の左官業の男性（５６）は「法人でも大丈夫」と言われて入った結果、今や無保険だ。
それでも社長は３０年間、国から一度も指導を受けてこなかった。冬場に建築が減る北海道では、１２月に従業員を解雇し４月に再雇用する慣行がある。「常用雇用扱いでなくとも可」。社会保険事務所は社会保険の加入不要とも示唆したという。一部社労士は「裏技」として指南し、厚労省も黙認してきた。
それが昨春、無資格問題が報道され、国は手のひらを返した。社長は昨年末、全従業員を解雇した。しかしなお、６５００万円の納付義務は両肩に重くのしかかる。
時効にかからない２年分全額を払わせる清算案は、１人６５万円かかる。「公平」を重んじる長妻昭厚労相（当時）の意向が反映された。事情に詳しい民主党議員は「とても払えない。現場を知らない長妻氏の置き土産だ」と批判してきたが、この間同省は「当事者の話し合い」を求めるばかりで調整から逃げ続けた。
無謀な解決策を示しておきながら、事態がこう着するや傍観に転じた厚労省の責任は重い。札幌市は病気の無保険者に一時的な同市国保への加入を認め、協会けんぽ移行後に医療費の返還を求めることを模索するが、移行のメドは立たず、医療費は市の持ち出しとなりかねない。それなのに厚労省は見解を示さず、地方に任せている。
工事業国保の辰川弘敬常務理事は８月３日、監督官庁の東京都から届いたメールに青ざめた。文面に「協会けんぽは過去の医療費を元加入者に請求させる」とあったためだ。
工事業国保が負担した過去２年分の無資格者の医療費５０億円は協会けんぽが払う－－。この厚労省の清算案に関し、同国保は元加入者が同けんぽへの移行手続きをすれば直接同国保に医療費が払われると解釈し、厚労省もそう認識していた。
ところが協会けんぽ側は違った。個々の元加入者に医療費を請求してもらい、元加入者を通じて同国保側へ返還するつもりだった。「工事業国保は非を認めず、移行手続きも進んでいない」。幹部間にそんな不信感があるためといい、１年が過ぎた今も一円も支払われていない。
「１万人を超す元加入者に今から連絡などできない」。同国保の悲鳴に社労士の内山晃衆院議員（民主）が間に入り、１０月末から事態は動き始めたものの、移行手続きを終えた３９７０人分、１９億円の支払いに見通しがついたに過ぎない。
◇「例外」国保に特権批判
工事業国保は左官職、芸者ら同業種ごとに１６５ある国民健康保険組合（国保組合、３４３万人）の一つ。国保組合は、単独事業主などの条件を満たしていれば加入でき、その場合は国民健康保険（市町村国保）など一般公的保険には入らなくてもよい。歴史的経緯から、６１年の国民皆保険導入後も「皆保険の例外」（厚労省幹部）として存続してきた。
国保組合には公費負担（負担率４３％）がある。市町村国保（同５０％）並みながら「医師国保」「弁護士国保」など高所得層も混在し、特権視されてきた。建設系も０３年に一般の医療費窓口負担が３割になった際、２割に据え置いたところが多く、通院医療費をゼロとしてきた組合もある。０９年秋、こうした税金の使われ方が財務省の意向で事業仕分け対象に浮上した。
ただ、けがのリスクが高く、低所得者も多かった建設職人は長らく公的保険から排除され、やむなく仲間で身を寄せ合ってきた。今も「けがと弁当は手前持ち」との意識が強い。建設職人で作る全国建設労働組合総連合（全建総連、約６４万人）の勝野圭司社会保障対策部長は「ひどかった建設職人の社会保障を自分たちで勝ち取ってきた」と主張する。
選挙の際、同総連は集票マシンと化す。その成り立ちも相まって、与野党を超え政治との結びつきが深い。
「建設国保は何が何でも守る」。仕分け開始直前の０９年１０月２１日。民主、自民両党から共産党まで与野党幹部が顔をそろえた全建総連定期大会で仙谷由人行政刷新担当相（当時）はそうあいさつし、拍手を浴びた。結果的に、国保組合への補助金は仕分けから外れた。
それでも、無職の人や非正規雇用労働者の急増で「原則」の市町村国保が疲弊する中、「例外」の国保組合には廃止論も相次ぐ。１０年秋には仕分け対象となり、厚労省は国庫負担を削減する法案を用意している。
国保組合廃止について厚労省幹部は「私有財産を奪うに等しい」と話すものの、中長期的には衰退するとみる。単独事業主でも税制上有利な法人なら入れず、加入者は減る一方と踏んでいるからだ。
日本の医療保険制度は１９２７年、工場労働者らを対象とした健康保険が最初。４２年に会社員らの健保と統合、今の制度につながっている。一方、農民向けには３８年に国民健康保険（国保）が始まった。ただ、５６年当時で人口の３２％、約３０００万人が無保険だったとされ、政府はこれらの人を国保に加入させるため６１年に国民皆保険を導入した。
現在は、民間企業の従業員は勤め先が設立した健康保険組合か、会社に健保がない人は全国健康保険協会（協会けんぽ）に入る。
健保組合は設立に７００人以上が必要とあって、大企業が多い。保険料率の労使の負担割合を社員が半分を超えない範囲で自由に決められ、出産一時金（４２万円）の上乗せや保養所など、特典のある組合も多い。
協会けんぽは中小企業中心。保険料率（労使折半）は都道府県ごとに違う。健保組合同様、病気で休んだ際の傷病手当金はあるものの、上乗せ給付はない。不況で健保組合を解散する企業の受け皿ともなっている。
一方、自営業者や無職の人、一部の非正規雇用労働者は市町村が運営する国保に入る。保険料には地域間格差があり、最高の北海道猿払村（年間１３万３６８２円）と最低の沖縄県伊平屋村（３万９０７円）では４倍以上の開きがある。事業主負担もない。
現在、医療費の窓口負担は原則一律３割だが、皆保険導入前、９０％以上の国保は５割だった。当時の健保は「ゼロ」が多く、０２年度まで２割だったのに比べると差がある。国保には上乗せ給付や傷病手当金もない。
というか、今まで傾かなかった理由は何だと思ってる？
プレイステーションやセガサターンなんて、CPUは20MHz前後、メモリ2～3MBとかだよ？
そんなミドルクラス以上のPCを持ってて、それをきちんと運用できてる人なんてごく僅かだよ。
そもそも自分のPCがどの程度の性能なのかすら分かってない人の方が多い。
一方コンシューマでは、据え置き気に比べて絶対性能が微妙な携帯機が威力を発揮しているなど、ゲームそのものに求められる描画能力が昔程重視されなくなっている。
重視されなくなったんじゃなくて、それなりのHD画質が「あって当たり前」になったってだけ。あって当然なクオリティだから誰も求めない。
今更ゲームにステレオ2ch音声を声高に求める人なんていないでしょ。
よく考えてみ。
あなたが想定する、「PC(Windows用)ゲームを買う人」ってどんな人？
性別、年齢層、家族構成、生活スタイル、職業、なるべく細かく想像してみ。
その上で、そういう人間がこの国に何百万人といて、そのうちの何十万人かが、現行のゲーム機やその他の娯楽を差し置いてまでPC(Windows用)ゲームを買う状況って、現実に有りうると思う？
PCの方が開発は楽で、ダウンロード販売を使えば、物理的にも流通的にも中間マージンを大幅に排除できて
ゲーム会社は利益を得られやすくしかも価格も抑えられると思うんだよね。
PCの問題として、昔はメーカーマシンのゲーム描画能力が貧弱過ぎるという問題があった。
しかし、今はPC全体の性能向上とオンボード3D性能の向上によって、ある程度の描画能力までなら問題がなくなりだしている。
一方コンシューマでは、据え置き気に比べて絶対性能が微妙な携帯機が威力を発揮しているなど、ゲームそのものに求められる描画能力が昔程重視されなくなっている。
相対的にメーカーマシンでも要求されたゲーム性能を満たしやすくなっていて、障害はなくなっているように思える。
PCを持ってない人は少ないと思うけど、テレビ持ってない人は増えているのでは。
テレビとゲーム機を両方買うとかなりの出費で、スペースも食う。PCを拡張すれば問題ないけど…。
十分な開発環境やライブラリ、2Dツールはもちろん統合3Dツールまで無料で手に入るようになり、ゲーム製作の敷居はすごく下がっていると感じる。
ウェブ上で、読んだ後非常にモヤモヤする文章を見つけることがあります。この言葉にならない感覚は一体何なのか…書くことで言葉に変換して正体を突き止めたい！
ということで以下に絶好のサンプルを引用し、モヤモヤしないと思う文に脱臭してみたいと思います。
20才の頃、お金も無く、良くてユニクロ、下手するとジャスコで服を買ってた。いや、ジャスコでは正確には買っていない。帰省した時に、親が僕の服装のみすぼらしさを不憫がって、近くのジャスコに夕ご飯の買い物に行ったついでに、安売りの服を買って恵んでくれてただけだ。当時、今で言う「リア充」は、わざわざバイトして、そのお金で好きな服を丸井や伊勢丹で買って、お洒落少年をやっていた。リア充爆発しろ、とはこのことだ。当時の僕は、バイトしてまで服を買う程ファッションに興味が無かったし、そんなお金が有ったら、少しでも出たてほやほやの初代Pentiumマシンのメモリを増やしたかった。
【脱臭後】20才の頃はお金がなかったのでユニクロで服を買っていた。親が僕の服装を見かねて夕飯の買い物ついでにジャスコで安売りの服を買ってくれることさえあった。当時のおしゃれな友達はアルバイトしたお金でデパートの服を買っていて、妬ましかった。一方僕はそこまでおしゃれに興味がなく、服よりもPCの部品を買いたいと思っていた。
※20才の頃はユニクロやジャスコの服を着ていた。だけでも良いと思いますが、お金のなさの強調にジャスコは外せない一方で、親の話を入れてさすがにジャスコで買うほどはダサくなかったと言いたいのだと考え、残しました。親に対する「恵んでくれた」という表現は、卑屈なうえ親を小馬鹿にするようで、反感を覚えました。後半、あえてネットスラングを使ったり、Pentiumマシンという単語をわざわざ出すことにあざとさを感じました。できれば、PC部品の方が欲しいのにも関わらず服を買う友人を妬ましく思う心理にもう少し詳しい説明がほしいです。両方同程度に欲しいが自分はアルバイトでそこまで稼ぎきれなかったというもどかしさで、苛立っていたのでしょうか。
25才の頃は社会人3年目。デパートにはバーゲンなるものが有り、その時期だと安くお洒落な服を買える事をやっと発見した僕は、なけなしのボーナスを手に、デパートで服を買う様になった。しかし、その頃同世代のリア充は更に先に行っていて、バーニーズやVIA BUS STOPとかの、やや高級なセレクトショップで服を買っていた。デパートで買うDCブランドの服は、自己主張が強く、どことなくDQN感が漂う時も有ったが、リア充達がセレクトショップで買う服は、大人の余裕に溢れていて、僕はそこにファッションのスキルの差を感じざるを得なかった。
【脱臭後】25才、社会人3年目になる頃にはボーナスも入り、デパートのバーゲンがお得なことに気づいて、デパートで服を買えるようになった。しかしその頃、おしゃれな友達はもっと先を行っており、高めのセレクトショップやで服を買っていた。デパートのブランドはこれ見よがしでかっこ悪い気もして、おしゃれな友達に対し相変わらず劣等感を覚えた。
※「なるものが有り」「やっと発見」「なけなしの」等がうるさい印象を受けました。後半は単に劣情を述べていると思うのですが、固有名詞や言い回しでおしゃれに精通していると強くアピールしているように感じられ、鬱陶しく思いました。
30才になると、そこそこお金も出来て、時代もバブってくる事になる。この年代になってやっと、ストラスブルゴやアリストクラティコみたいな通っぽいセレクトショップで買うようになり、欧州の古いメゾンのオーナーデザイナーが来日しての採寸オーダー会みたいなのをチェックして買ったり、ディオールやドルチェ&ガッバーナなど、自分のスキニ―な体型でこそ生きる服を多く揃える店によく行って、しまいには自分の担当が出来たり、いつしか服の買い方に関する変な劣等感は無くなった。
【脱臭後】30才になると収入がずっと増え、通好みのセレクトショップの服やヨーロッパのデザイナーのオーダーメイドを買ったり、超高級ブランドに通い詰めてお得意様扱いしてもらえるようになり、劣等感を克服した。
※この部分は特に鼻についたため、思い切って大幅に割愛しました。特にこれ見よがしなファッション用語が嫌らしいと思いました。
その頃、手練れのプロ独身みたいな洗練された女性と知り合った。外資系企業に勤め、日本版SATCみたいな感じの子だった。ある時彼女は、服を買いたいときはニューオータニに行くと言っていた。余り意味が分からなかった。少なくとも、これまで僕が経験してきたプライスタグともろもろの質が正比例するマッチョな世界とは違う軸の話なのだろうとは感じた。正直、服を買いにホテルに行くのは、想像力の範囲外の事柄だったので、その言葉に対し、僕は極めて曖昧な返事をした覚えがある。
【脱臭後】その頃、外資系企業に勤める独身の、非常に洗練されたおしゃれな女性と知り合った。彼女は服を買いたいときはニューオータニに行くと言っていた。当時はホテルで服を買うなど考えてみたこともなく、彼女の真意もわからず、曖昧に返事をするしかなかった。きっと、高い服ほどおしゃれに違いないという僕の考え方とは次元が違う話なのだろうと思った。
※「プロ独身」とはどういう意味なのか、ぜひ説明してほしいです。「プライスタグともろもろの質が正比例するマッチョな世界」という表現も、何度も読み返さないと意味がわかりませんでした。高尚な雰囲気を醸し出そうとしすぎだと思いました。
そして、35を少し過ぎた今、やっと彼女が言っていた事が何となくは分かる。確かに、オータニやオークラは服を買いに行くには快適な場所だ。静かで、邪魔されず、店員は控え目な一方、二回目の訪問なのに僕が前に買ったものと、何とどういう軸で迷ったかを覚えてくれている。古いホテルに入っている、いつも客が入っていないアパレル系のお店は、なぜ成立しうるか長年の疑問だったが、プロ独身女性みたいな「お金のある、うるさ方」が太い顧客なのだろう。こういう人は服はもう十分に持っている。だから、服そのものだけが買い物の目的では無く、服を買うプロセスにもこういう人はスペシャルを求め、そのプロセスを消費している。そうすると、単に服の品揃えが良い店より、自分の好みを知っている店、静かに買える店、客筋がいい店、みたいな所の評価が上がり、結果的に高級ホテルに入るに相応しい接客レベルのお店が、その種の人々に刺さることになる。
【脱臭後】そして今、35才を少し過ぎて、彼女の言った事がわかるようになった。ホテルに入っているアパレルショップは静かで、店員も控えめで、落ち着いて服を選べる。そのうえ一度の買い物でも、次に行ったとき前回どの服を迷ったかまで覚えていてくれる。なぜホテルのアパレルショップはいつも空いているのに商売が成り立つのか、長年疑問に思っていたが、お金持ちで服にこだわりがある少数の独身女性が単価の高い買い物をするために赤字にならないのだろう。そのような客層は服はもう十分に持っており、服そのものよりも服を買う過程を楽しみ、消費している。このため品揃えの良さよりも、接客レベルの高さを求めて店を選ぶことになる。
※「太い顧客」という表現が一般的ではなかったため、少々無理に直してしまいました。「お店が刺さる」という言い方は、変ではないのでしょうか？
服を買うという行為の目的は服だけでは無い。オフィスワーカーは弁当が好きでコンビニで弁当買っている訳じゃ無いってことと同じだ。コンビニは、「少しでも長い昼休みの自由時間」「同僚との面倒な連れランチを断る口実」を弁当という形で500円のプライスタグ付けてオフィスワーカーに売っているのだ。モノじゃなくて、イミを売る時代とは、人口に膾炙した言葉だが、きちんとその意味合いを理解すれば、正しくビジネスチャンスを捉えられる。コンビニは、より安くより美味しいお弁当を作るのではなく、より長い昼休みを提供し、より判りやすいランチを断る口実を提供する為に、オフィスワーカー向けの定時デリバリーサービスでも始めた方が、ビジネスチャンスは拡がる事だろう。外食に行って戻る45分を、コンビニで買って戻る15分にしたい人は、それが気軽にデリバリーされて0分に出来るなら、もう500円余計に払ってくれるに違いない。身の回りで、愛妻弁当とか手作り弁当とか持ってきている人種は、本当に妻や料理を愛しているのだろうか、顔を思い出して考えてみよう。節約という人は居るだろう。でも、単に一人でランチを食べたいだけという人も結構居ないだろうか？そうだとしたら、そこに市場がある。
【脱臭後】服を買う行為の目的は服だけではない。会社員は弁当が好きでコンビニ弁当を買うわけではなく、昼休みに少しでも長く自由時間を得るためや、面倒な同僚とのランチを断る口実のために、500円払って弁当を買いに行くのである。よく、物ではなく意味を売る時代と言われるが、きちんとその意味合いを理解すればビジネスチャンスにもなりうる。コンビニは、より安くより美味しい弁当を作るだけでなく、上記のような理由で弁当を買いに来る会社員のために、定時の弁当配達を始めるべきである。外食に行って戻る時間をコンビニで節約したい人は、配達弁当でさらに時間を節約できるなら、500円の弁当でも1000円で買ってくれるに違いない。愛妻弁当や手作り弁当を持ってきている人も、多くは妻や料理を愛しているのでも、ただの節約でもなく、単に一人でランチを食べたいだけなのではないだろうか。そうだとしたら、そこに市場がある。
※平易な文に直してみると、「配達で500円弁当を1000円で売る」「弁当持参派の多くは一人で食事をしたいだけ」とは随分無茶な気がしてきました。また、「物ではなく意味を売る時代」という言葉と、この最後の段落は、実は無関係なようにも思えます。配達弁当を買う人は、弁当と同時に時間を買っているのではないでしょうか。
誰でも自分の臭いはわからないといいます。ニンニクも食べてしまえば臭くない。私の文章も、どなたかによって脱臭可能に違いありません。
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす
http://japan.internet.com/busnews/20111013/8.html
で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。
（2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。
Stevey の Google プラットフォームぶっちゃけ話
僕は6年半ばかり Amazon にいて、それから今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやもうとにかくね。百、いや二百のポイントで二つの会社を比較することが出来るだろうけど、僕が正しく覚えていれば、 Google はそのうち三つを除いて優れている。実にある一点に関してはスプレッドシートを書いたんだけど、法務部が外に出すなって言うんだ。リクルーティングは惚れ込んだみたいだけどね。
つまり、まあ簡単に言えば、 Amazon の人事採用プロセスってのは基本的に欠陥品なんだ。だって、チームがチーム毎に、自分達のために人を採用するんだぜ。だから、色々平均化の努力はしてるみたいだけど、採用基準はチームによって信じられないくらいバラバラさ。そんでもって作業工程ってのも腐ってる。ソフトウェア信頼性工学なんてお呼びじゃないし、エンジニアに何でもやらせようとするんだ。コーディングする時間もないくらい。もちろんこれもチーム毎にバラバラで、要するに、運次第ってところ。施しやら困った人を助けるのやら、コミュニティに貢献するのやら、そんなのはもってのほか。ばかにしに行くんじゃなけりゃ、近寄るべきじゃないね。それにまた施設も染みだらけの壁に囲まれた箱みたいな家畜場で、装飾やらミーティングエリアなんてものには一銭も使ってない。給料やら福利厚生なんてのも最悪だ。まして最近じゃあ Google やら Facebook っていうライバルがいるのにね。社員特典なんてものも見たこと無かったな。採用通知の番号を照合して、ハイ終わり。コードベースも悲惨そのもの。エンジニアリング基準ってものがないんだから。チームによっては個別にがんばっていたくらいかな。
公平に言えば、彼らは良いバージョン管理ライブラリシステムを持っていた。これは僕らもまねるべきだし、僕らのところには同様のものが無い、良い pubsub システムもあった。でも多くの部分で彼らが使っていたのは、ステートマシンの情報を RDBMS に突っ込んだり読み出したりするだけのくそみたいなツールの塊だった。僕らならただでも欲しくないようなね。
僕が思うにその pubsub システムとライブラリ管理システムが、まさに Amazon が Google より優れている三つのうちの二つだ。
早期にリリースして、狂ったようにイテレートするってのも彼らのうまいところじゃないかって言うかも知れない。けど逆もまたしかり。彼らは早期にリリースすることを何にもまして優先する。品質保持やらエンジニアリング規則、その他長い目で見たら重要になってきそうなものはみんな後回し。そんなだからたとえ市場で競争相手よりアドバンテージがあったとしても、結局ちょっとしたことをやるのにも問題を起こしちゃうよね。
でも、一つ、そんな政治的な、思想的な、技術的なへまを補うだけの、彼らが本当に本当にうまくやってることがある。
Jeff Bezos は悪名高きマイクロマネージャーだ。彼は Amazon の小売りサイトの1ピクセルまで管理する。彼は以前 Larry Tesler を雇った。 Apple の主任科学者で、たぶん世界で最も有名で尊敬される HCI エキスパートさ。そんでもって、 Jeff は Larry が言ったことを、 Larry が辞めるまで3年間無視し続けた。 Larry は大規模なユーザビリティ研究もやっただろうし、少しの疑いの余地も無く誰もそのひどいサイトを理解できないってことをデモしたに違いない。けれど、 Jeff は1ピクセルたりとも動かさせはしなかった。トップページにぎっちりつまった内容の1ピクセルたりともね。それらはまるで何百万という彼の貴重な子供達なのさ。けれど Larry はそうじゃなかった。
マイクロマネジメントが Amazon が僕らよりうまくやっている三つ目ってわけじゃあない。つまり、まあ、彼らはうまくマイクロマネジメントをやっていたと思うけど、それを強みって言いたいわけじゃ無い。まずは何が起こっているかみんなに理解してもらうための文脈を準備しているだけさ。僕らはこれから、公衆の面前で、 Amazon で働きたけりゃ私に金を払えと言ってのける男について話すわけだからね。誰かが彼に反対したときは、彼は彼の名前入りの小さな黄色いポストイットを手渡して、誰が会社を動かしているかを常に忘れさせまいとする。思うに彼は全くの… Steve Jobs なのさ。ファッションとデザインセンス抜きのね。 Bezos はとんでもなく頭が切れる。誤解しないで欲しい。彼の前じゃ、普通のコントロールフリークなんてヤクが極まったヒッピーみたいなもんだよ。
それである日 Jeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。
彼の巨大な指令はこんな感じだった。
1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。
2)各チームは各々そのインターフェースを通じて通信しなければならない。
3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。
4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。
5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。
6)そうしない者は解雇される。
7)ありがとう！良い一日を！
ハハ！。ここにいる君たち150人ちょっとの元 Amazon 社員ならもちろんすぐにおわかりの通り、7番は僕が付け加えたジョーク。 Bezos は間違いなく君たちの一日なんかに興味ないからね。
それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフ熊ブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 Wal（ごにょごにょ）Mart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢なインターフェース」という言葉を連呼する男だった。 Rick は歩き回り、「堅牢なインターフェース」について語り回り、そして言うまでも無く、みんなはいっぱいの進展をし、 Rick にそれを知らせた。
それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問や論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなもの、インディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。そのほんの一部をちょっぴり挙げると、こんな感じだった。
とまあこれらがほんの一例。他にもたくさんの、おそらく何百の、 Amazon が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
Windows 7 64bit 版上で winpcap を使ったサービスプロセスを制作。
こちらのページを参考にさせてもらった。
「WinPcapを使用したパケットモニターの作成」CodeZine 古谷誠進さん
http://codezine.jp/article/detail/126?p=2
・アダプタ一覧（アダプタ名およびIPアドレス）を取得する
の箇所
処理は、while(d)ループの外でやらなくちゃいけない。
デバッグきつかったっす、サービスだとデバッグできないこともあって。
・俺のマシンが64bitだから、winpcap.dllやlibと合わない?
(PCAPSDKのLibにx64というサブフォルダがあって、こっちのものを指定しなきゃだめ?)
・WIDECHARとMULTIBYTE の扱いの問題?
と、いろいろ迂回してしまった。
解消したら、無事動き出した。
わざと避けてた部分を書かれたw
まぁFlashの普及という意味ではvideoタグが全部持ってくよね。あとcss3。canvasはそれほど脅威ではない印象。
videoタグの実装が整ってくれば、一定数のFlash離れは起こるんじゃないかと思う。ただ、videoタグの普及にはまだまだ時間がかかりそうだから、それまでにFlash無しじゃいられない体にしてしまえば、生き残りは十分可能な気もする。実際、Mixiアプリやってる有閑マダム達を虜にして一定数は確保してる。
あと、一度インストールしたら、重大なセキュリティホールが発見されない限り、わざわざアンインストールはされない。慎重に対応すれば現在の普及率をある程度キープすることは可能。
もっとも、Adobeは、Flashをブラウザ上からクロスプラットフォームのアプリ作成環境にまで成長させるつもりっぽいので、長い目でみてもFlashは形を変えつつ生き残るんじゃないかと思ってる。
「Flashに死んで欲しいと思ってる」ってのもある程度同意。ただし少なくともIE6ほど「みんな」ではない。
Flashが恨まれるのは、まだマシンパワーが貧弱だった時代に、わざわざ重いベクターアニメーション環境をブラウザで動かしてしまった事に起因してる。その上、かなり優秀なタイムラインアニメーションツールを提供してしまったため、敷居がぐっと下がってしまい、「負荷」という言葉を知らないアーチスト達によって、きれいだけど無茶なコンテンツが量産されてしまったという悲劇を引きずっている。
もっとも、マシンパワーがあがった今でも、負荷的に無茶なFlashコンテンツが量産され続けている状況は変わってない。これはFlashのせいというより、コンテンツ作成者の知識不足によるところが大きい。Adobeは、もっとコンテンツ作成者の成熟に力を入れたほうがよいのかも知れない。
http://anond.hatelabo.jp/20110816094649
http://b.hatena.ne.jp/entry/anond.hatelabo.jp/20110816094649
私はこの記事の正しさを判断するだけのリソースを持っていません。
なにより、２ちゃん同様、反応が一定の数を超えると「流れ」ができてしまいう。特にあんまり考えないで、この記事はすごい、と言ってみたりBIや生活保護を否定する意見が「数だけは多い」ことによってなんとなくそういう雰囲気が気持ち悪いと感じました。たぶん私の他にもそういう人いるでしょう。
今更「本当にこれって正しいのかなー」とか「セカンドオピニオンが読みたい」と思ってもそういうコメントだけ探すのも大変だろうから、自分がピックアップしてみた。
これはこれで偏っているので、読み手の人は上手にバランスを取ってください。
読むのが面倒なひとにはとりあえずコレだけ読んでください。
この意見が正しいとは言わない。ただ、直接ベーシックインカムの否定に繋がる話ではないってことだけは理解しよう。
まとまった批判をされている人がいるのでまずここから取り上げる。
・"イギリスにはホームレスが少ない"の段は一般化しすぎ。キャッシュマシンの脇に布団巻きつけた若い兄ちゃんがという状態が改善されたのは90年代後半の好況、ブレアの政策、ハウジングNGOの活動の賜物
・それと、ここで終わらせずに、昨日のエド・ミリバンドのスピーチを加えてほしい。
・それと、子供たちが「鬱屈した」理由を具体的に検討していないのは、それこそ片手落ち。昨年の政権交代後の緊縮財政で、「部活」的な活動を運営していた組織の予算が75％もカットされた http://t.co/ksQqiUV この現実をどう見るか
・さらに、ハックニーのペンバリー・エステートのようなところでは自分の住んでる街を歩いているだけで警察に呼び止められ所持品検査を受ける。警官は殆ど「白人」、止められる側は白人でないことが多い。その制度的不十分さにも「納税者」の憤りは向かうべき
・必読: 月曜の両党主スピーチ: http://t.co/okbhvh8
・シングルマザーの公団優先話でいつも不思議なんですが、彼氏はどこに住んでるんでしょう？実家？ウソついて同居？私が普段見てるメディア（BBC, Gdn）ではほぼ無視されている説で、統計数値も見たことないのです。
・「パートナーがいても敢えて結婚せず、シングルマザーになる母親が多い（当然の結果として、その後別れて本当のシングルマザーになる確率は高まる）」 "離婚率"の高さはスルーですかそうですか。「パートナーがいても敢えて結婚せずシングルマザーになる母親が多い」論、エド・ミリバンドとパートナー http://t.co/zBtBoeY に言えるほどの裏づけがあるのなら、それはそれでひとつの意見。ないのなら某メディア鵜呑みか個人的妄想
この意見を読むとかなり元記事の意見が相対化されるのではないかと。
元記事の人が、必ずしも正しく問題を理解しているとは考えないほうが良いみたい。
イギリスのメディアの方が日本のそれよりは少しレベルが高く、そのメディアの報道を見ているというだけという可能性もありえます。
その他の意見
・社会保障に暴動の原因があるとしたら、制度の影響でなく、不況等の理由で、依存していた制度が切られる不安と恐怖の方がなんだかしっくり来るし、それを「甘やかし」と簡単にまとめてしまうのも問題がある
・なんで同じように高福祉高負担のスウェーデンとかではこういった暴動が起こらないのだろう？
・本田勝一のアメリカ合衆国の黒人ルポルタージュとかいてあることがさして変わらない気がする
・(1)〜(3)に託児所の充実がないのはなぜだ
・一見、教育無策だったようにも思えるけど、元首相のブレアは、教育こそ政策の最重要課題として理解し実行していた。それでも結局イギリスを立て直すことが出来なかった
・この分析からは「階級」という社会的な鎖が抜け落ちている。前提として、英国には絶対的階級社会があり、しかし労働者階級＝貧困層ではない点を理解しておくことが重要かと。同じような福祉社会である北欧やら日本との違いはそこにある
・よく読むと手厚い福祉が引き起こす矛盾というよりは、育児・教育の公的支援の不足の問題
・この文章の性格。それは向き合うか（与えるか）、さもなければ処遇する（奪う）というものだ。殺伐とした現状といいたいのかもしれないがそれに飲み込まれている感。分析から導き出される結論が歪みすぎ。吐き気がする。「暴徒達は何者なのか」「イギリス人はどう思っているのか」という見出しのつけ方からもクサい
・「中流社会を捨てた国」http://d.hatena.ne.jp/takahiro_kihara/20091121 の話と違うなぁ
・思想や状況が違いすぎるので日本と対比すべきではない。自分としてはhttp://blog.livedoor.jp/mikako0607jp/lite/archives/51802870.htmlに共感
元記事において、階級意識の問題、差別の問題、教育の問題、むしろ福祉が最近激減しているという問題、などがスルーされていることが指摘されています。
これらの問題のウエイトをどの程度評価するかによりますが、無視して良い問題ではないように感じますね。
闘争だ。いまは闘争の時代なんだ。学生運動とか、安保闘争とか、運動母体が負け続けてきた闘争がまた激しく再燃しかけているんだ。
人々はインターネットを介して集う。演説は、なにも集会で行う必要がなくなり、どこであってもいつからでも、聴衆になることができて発言者になれる。
不鮮明な熱量は確かに大きくなり続けて、いつの日にか火山みたいに噴火するのかもしれない。大きな大きなうねりになれば、何かが変わって勝つこともできるのかもしれない。
運動母体が得る始めての勝利。仮にそれが実現したらどういう状態になるのだろう。勝者は敗者を虐げ、新たな秩序を打ち出すことができる。権力者になることができる。
もし運動母体が大勢に打ち勝つことができて、その後権力を握り得たとして、その権力を行使する主体は誰になるのだろう。
広がりに広がったネットワーク媒体だろうか。それとも旧来どおり中枢をなす人物たちによる統制なのだろうか。
侃々諤々としたネットワーク上の民意による体制が築かれたとしたら、なんだかＳＦっぽいなあって思う。
もちろん、個々人の判断を礎に据えているとは言え、その総意としてまとめ上げられた一個の意見が――とかなんとか考えたけど、法律も似たようなものじゃないねえ。
神様が生まれるかと思ったけど、そんなことなかった。いや、それとももうすでにたくさんの神様がいると考えてもいいのかもしれない。
違うか。ファジーなプログラムがあるだけか。超高性能なコンピュータマシンが、無数のプログラムを起動させているだけなんだろうな。
仮想現実。マトリックスの世界観。少し違うのは、コンピュータを形成しているのがその中で蠢いている無数の意思であることか。
私たちの総意で汲み上げられた倫理なり良識なりに、私達自身が縁どられて生きている。個体を律して、安定を育む。度を越すと、それらに縛られてしまう。
不思議な感じだ。同調圧力とか、空気を読むといったこと。あるいは偏見とか、典型的なものの捉え方というものを想像すると、無機質な無生物によって個人が支配されてるような気がしてくる。
法則と呼ばれるようなものって、だからやっぱり神様に近いなあって思う。神様の残り香見たな。そういうものによって私たちは支配されているし、自然だって規制されてる。
すごいなあ。でも、いつか根本的に常識を覆してしまうような、例えば星を継ぐものにあった大々的な発見があれば面白いなあって思う。そういうことがあってほしい。
ところで、星を継ぐものに書かれてた、新たな化合物の発見って、どこで回収される伏線なんだろう。あれだけ気になる。どういうことだったんだろう。