 
|
はてなキーワード: モニタとは
高専在学中, OB, OGの人達が高専に入ったきっかけとか、どういう系統のことが好きなのとか詳しく知りたいからできれば高専関係の方はブログに書いてほしいなーとかチラッと思った #kosen_opportunity
なんていうのがTLに流れて来てたので暇つぶしに高専入学の志望動機を思い出してみた。
なお、当時書いたであろう入学志望動機は現存してないのでやっぱり記憶を。
中2当時はご多分にも漏れず
人と違う何かをしたいとかそんなことを思ってたようで
中3で
old macを安く買ってPLLの定数変更してクロックアップに勤しんでみたり
そんな中学生でした。
ってのが育英に通うきっかけでした。
ちなみに志望学科は
航空が電子工学科→航空
にしたような。機械とかあんまし興味なかったですしね
第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 練習問題
会社のお仕事で、突然に展示会係になってしまった人用のメモであります。
主催者側からあらかじめ、小間のレンタルや看板の作成の案内がくる。明確なプランがあるのならば、自前で用意するのも手である。自前で工夫すると目立つ。その一点が最大のメリットである。
すでにあるのであれば、壁にたくさん貼る。細かい商品説明を書いてもなかなか読んでもらえないので、キャッチーなものがよい。浸透していないブランド名ならば、サービスの内容を大きく書いたほうがよい。
実演できる商品であれば、論より証拠、目の前で見せるのがよい。
忙しい来場者に瞬間で展示物のよさを知ってもらいつつ、来場者の出張報告の助けになるようにチラシはつくるべきである。チラシを作るときには、このチラシをもらって、出張報告書や稟議書がかけるのかどうかを基準としてみるとよい。
24インチのモニタにパソコンで作った動画を流せばOK。このあたりはスキルによって、簡単かもしれないし、難しいかもしれない。
自社の新製品よりも、誰がもらってもうれしいであろうすでに世の中で喜ばれているもので普段使いできるもので安価なものを配るのがよろしい。
すなわち、ボールペンやメモ用紙のようなものに新製品の名入れをして配ると、ターゲットとなる人が展示会会場を出て、家や会社まで持ち帰ってくれるという目的を達せられるはずだ。
持って帰れるものならば、サンプルの無料配布でもよい。もらってうれしいかを判断基準にすることは重要だ。
疲れている人もいるかもしれないので、缶ジュースや缶コーヒーのようなものを喜ばれる。
新入社員の女の子でもいいし、若い男性社員でもよい。兎に角、清潔感があって、話しかけやすい人を最前線に配置する。詳しい話を聞きたい人が現れたら、詳しい人が説明をすればよい。お金があれば、コンパニオンを雇うのだろう。
いすに座ったまま、黙っていたのでは人は集まらない。何か目新しいものはないかと、さまよっている人の注意をこちらに向けるには、声を出すのがよい。いすに座ったままでは横柄なので、目立つ場所に立って、この小間で何をしているのかを声に出してアピールする。そのときの声は、少しあざといアニメ声であったり、露天商のように通る声であったりすると雑踏の中でも注意を引ける。
くじ引きをしてもらうことで、話すきっかけを作る。あたりはずれで、ノベルティを分けてもいい。
集まった人の中から見込み客となる人を選別する。
アンケートを書いてもらい、名刺を集める。アンケートは選択式の簡単なものにする。答えに困るような質問は入れない。
当たり前のことかもしれないが、後日の連絡先をチラシに明記する。共同出店の場合は、特に詳しい人が小間にいないことが多いので、注意。
後日、集まった情報をもとにコンタクトを取ってみる。電話をしたり、パンフレットをもう一度送ったり、実際にアポイントをとって、商談につなげる。
近頃、ゲームを全くしなくなった事をよく実感する。学生の頃にはまっていたMMORPGをはじめとするネットゲームは勿論、Xbox360やPS3にも滅多にゲームディスクを挿入することなく、もっぱらDVDやブルーレイの鑑賞機器として稼働している。PSPやDSに至っては一年以上電源を入れていない。
と言っても、ゲーム自体が嫌いになったわけではない。今でもレースゲームやRPGにはわりと興味があるし、最近読み始めたライトノベルの影響か、ネットゲームに対する興味もやや増してきた。多分、これから先もゲームから完全に意識が遠ざかる事は難しいだろう。また、ネット上ではよく「体力が続かなくなった」という声を聞くけども、それも何か違う。確かに昔の様に丸一日をテレビやモニタの前で過ごせるほどの体力は無いとしても、半日くらいなら問題なく向かえるはずだ。
要するに、モチベーションの問題なのだと思う。ゲームなんてただのお遊び。そういう考えが板に付いてしまった。こんな事を言うと「仮想と現実の区別がついてない」という類いの批判を受けるかもしれないが、それに乗っかって言うなら、ゲームというものは仮想をもう一つの現実として扱うからこそ楽しかったんじゃないだろうか。少なくとも、子供の頃はそうだったと思う。勝った負けたに真剣に一喜一憂し、難題が持ち上がると全力で解こうとしていた。今の様に「暇だな。ゲームでもしようかな」ではなく、学校から帰るやいなや、ランドセルをほっぽり出して友人の家に駆けつけてはコントローラーを取り合っていた。
あの頃の俺にとってゲームは特別な存在だった。当時を思い出す度にその一端は感じられるだろう。しかし、今はもう違うらしい。では「今の自分にとって特別なもの」とは何なのか。ゲームに限らず、同じ様な事を感じた時は特にこの点を思い出して欲しいと思う。
私はどっちかというとWindowsが好きだしMicrosoftが好きな方だ。だがWindows8、お前は駄目だ。
そりゃiPadが売れまくって羨ましいのは分かるし、MSがいくらタブレットOSを作っても誰も見向きもしなかったのは事実だ。だからといって、WindowsをタブレットOSにするのは暴挙としか言いようがない。
そもそもiPadが売れてWindowsのシェアが落ちているとしても、それは単にこれまでPCとは無縁だった層が新たにiPadを使うようになり、これまでのWindowsユーザーがiPadを追加購入しただけで、Windowsユーザーそのものが減ってるわけではないはずだ。iPadで仕事はできないからね。逆にiPadで仕事をするとニュースになるくらいだ。世の中の多くの人間がWindowsを使っている、あるいは嫌々使っている、あるいは使わされている理由、そしてそんなWindowsユーザーがWindowsに何を求めているのか、Microsoftは理解してるんだろうか？ してるけど無視してるんだろうか？
世の中のほとんどのWindowsユーザーがWindowsを使う目的は、仕事でワードとエクセルとインターネットをするためだ（あとエロゲをするためだ）。ワードを開いて文書を書きつつ、分からない点をIEで調べ、Outlookで連絡メールを送る、そんなのがほとんどでしょ。画面の綺麗さなんぞぶっちゃけどうでもいい。むしろ殺風景な方が仕事してる感じがしていいじゃないか？
なのにあのMetro UIってなんだよ。あんな原色のオモチャみたいなインターフェースで仕事ができるかっての。アプリが一つだけしか開けない、それでどうやって調べものをしつつ文書作成ができるというのか。Windowsの"s"の文字が泣くよ。でかいモニタに一つのアプリを表示して、他の情報が見たければ切り替えろ（これ「スナップ」とか言ったっけ？そういえば訳語が思いつかないから一般ユーザーに丸投げしてたね。訳語すらすぐには思いつかないような操作がどうして直感的操作として受け入れられようか）とか、冗談もほどほどにしてほしい。
ああいうUIが生きるのは、解像度が限られた端末だけだよ。なぜ広々としたモニタを無駄遣いするのか。それが気に入らないならクラシックデスクトップを使え？何がクラシックだよ現役選手をいきなり骨董品扱いすんな。
それにオフィスにはタッチパネルディスプレイなんてないよ。入力はキーボードとマウスだ。一度あのMetro UIをマウスで操作してみてほしい。悲しくなるから。だだっぴろい画面の上、マウスを端から端まで動かして、点在するばかでかいボタンをぽちぽちと押す作業のむなしさ。メニューを出すにはマウスポインタを画面の端にくっつけて。ああ、マルチモニタ環境やリモートデスクトップ越しで死ぬほどやりづらいけど気にするな。スタートスクリーンのスクロールはホイールでできるよ、ただし横スクロールなのに縦に回す必要があるけどな。どや、マウスでの操作もばっちりやろ？
Win8が出ればタッチパネルディスプレイが普及するなんて寝言も聞きたくない。仮にそうなったとして、MSは我々にそんな苦行を強いるんですか？試しに目の前のディスプレイを指でなぞってみてください。3分で腕が痛くなるから。ジョブズもそう言ってたのにねえ。タッチパネルが実用的なのは携帯端末、タブレット端末、要するに本体を手に持って使うデバイスだけです。
WindowsにiPad的機能は誰も求めてないんだよ。iPad機能を求めてるWindowsユーザーはiPadを買うから。今目の前にあるデスクトップやノートPCでiPadみたいなことをしようなんて誰も望んでない。いくらシェアがどうあっても、MSはタブレットOSとデスクトップOSを完全に別物として出すべきだ。両者の操作体系は相容れないものだ。だいたいWin8のあの中途半端な融合具合を見ればそれは明らかであるが。タブレットOSとデスクトップOSが融合して嬉しいのは、スレートPC形態にもなるがキーボードを展開するとノートPC形態になるゲテモノPCだけ。そんなのがPCの主流になるという寝言もまた聞きたくない。
まだMetro機能を完全にオフにするモード（今のところレジストリの設定で可能ではある）がデフォルトなら許せるけども、そんな状態で発売されるはずがない。そんなことをするくらいなら最初からタブレットエディションを別に出している。なのでユーザーがMetro UIが統合されたWindowsを使いづらそうに使う光景が目に見える。自分でカスタマイズしてオフにすればいいじゃんという発想はPCに詳しい人のもの。ほとんどの人は与えられた状態をあるがままに受け入れ、そんなカスタマイズとは無縁ですよ。
それにスタートメニューを廃止した理由が「スタートメニューを誰も使ってなかったから」といけしゃあしゃあと抜かすところがまた癇に障る。なんでスタートメニューを誰も使わなかったのか、そしてどうすればスタートメニューが使われるようになるのか。考えもしないのか無視しているのか…。Windows用の人気ランチャの一つや二つ、触ってみればわかることなので無視してると考えるのが妥当でしょう。あるいはスタートスクリーンをごり押しするための言い訳。
スタートスクリーンで従来のアプリを選んでクラシックデスクトップで実行できるでしょ、とMSは言いたいんだろうけども、アプリを起動するたびにいちいち全画面がMetro Style Appとかいうオモチャみたいなガジェットで覆い尽くされると、それだけで思考が中断させられる。従来アプリのメニューが階層化されずフラットに展開されるので探して選択するのが大変とか、その辺は今後改善されるかもしれないけどあんまり期待しないほうがいいだろうね。
これはエクスプローラもそうで、「ツールバーやメニューバーを誰も使ってなかったから」という理由でリボンインターフェースを採用とか、なぜ使われないのか理由を全然分析できてない。ファイルをマウスで選択して、さあ移動しよう、という段階で、一度それは置いといてメニューをクリックしに行くのは不自然な動作だから誰もしないんだよ。そのままドラッグ＆ドロップ、あるいは右クリックメニューで操作を選ぶのは自然だし不要なマウスの移動もしなくてすむから皆そうしてる。あるいはキーボードショートカットを使ってる。だからリボンなんてつけてもやっぱり誰も使わないのが目に見えてる。それどころかリボンUIは縦の幅を食うので、昨今の横に広いディスプレイと相性が悪いということも考慮してないのか無視しているのか…。
シェアの数字にこだわるあまり、ユーザー完全無視。いやまあそれでもWin8は売れるんだけど。そりゃお店でパソコン買ったらWindows入ってる世の中だからね。企業だってコストを考えれば今更LinuxやMacに総入れ替えなんてできないが、XPのサポートが切れるから嫌でもWin8を導入せざるを得ない。MSは分かっててそれをやってるからなお腹立たしい。PC初心者やWindowsを嫌々使ってるユーザーをこれ以上苦しめないでほしいものだ。
私は従来モードの設定（製品版で封印されてたらキレるな間違いなく）で使うからいいとしても、そういったユーザーをサポートするのも私なんだよ…。彼らは「できるWindows8」とか「わかるWindows8」とかに載ってるのと違う画面にされることを望まないんだよ…。
例えば２Ｄ格闘ゲームなどは、今後かつてのようなものは生まれないと思っている。
スプライト全盛期の頃とくらべて、今のハードウェアは遅延がデカイ。液晶ＴＶも遅延がデカイ。目で見て入力して間に合わないというのはゲームとして致命的だ。
例えばこれに対するブコメもそう。
http://b.hatena.ne.jp/entry/anond.hatelabo.jp/20110806200518
正直さ、はてな界隈で見られる「反性差別」は、昭和臭すぎて気持ち悪いんだよ。中国嫁日記の『嫁』に過剰反応とか、いつの時代だ。
「どうせオタクは処女厨でセックス目的で、メンヘラ女子なんかと仲良くなるのは「下心」があるからでしょ？オタクが性欲丸出しのオタコンテンツ見るのも、そういった性差別的視点があるから（笑）」
とか、馬鹿じゃねーの？頭湧いてるだろ。
「お前たちは自分では気づいていないのかもしれないが、思考の根底が差別的だから～云々」みたいな、どや顔シングルピース発言よく出来るよな！
事あるごとに、とある作品や、言葉遣いの中から、男尊女卑、家父長制、セクマイへの差別、ミソジニー・・・を見出して、批判する人たち・・・
でもな、『そういった発想』ができる事自体に、昭和の残滓を感じる。
昭和臭い。昭和。バブル。車でドライブして女の子ナンパしてセックスセックス！！なバブル臭！！！
なんで、男が女の子と仲良くするときはセックスしたい下心が当たり前で、もし隠しているとしても無意識はそうなってる、オタコンテンツを楽しむ際のオタクにしても同様、故にオタクは差別性を自覚して、反省すべき！猛省すべき！！自制すべき！！！なんですか？？
いや、昭和の時代遅れ共が『自分の無意識』を『他人の無意識』に投影して「あいつらの正体見破った！！」なんて、ドヤ顔シングルピースしてるだけだろ？
昭和の時代遅れ共が持ってる『自分の無意識』が、『女の子と喋るときはセックスしたいの下心丸出し、ポルノはレイプもの大好き！！』なだけでしょ？
自分らがそういうゲスだから、逆に、ジェンダーとセクシュアリティをお勉強して、正義の味方になっちゃっただけでしょ？（笑）違います？？？？
自分らがただのゲスでクズで、正義の味方のフリしてネットバトルで人権とポリティカル・コレクトネスを盾に、他人を罵倒するのが大大大大大大好きなゲロ以下のゴミだから、PC正しいのが大好きなんでしょ？
誰かに勝利したいのが本懐で、本当は差別とかどうでもいいんでしょ？
ねえ、そうでしょ？違いますかにゃ？違うかにゃ？？にゃ～～？正しいですよにゃー
こいつら、絶対リアルの飲み会とかじゃ昭和のセクハラオヤジ丸出しのセクハラネタ言いまくってると思うわ。
んで、ネットじゃ正義ヅラして中国嫁の差別性が～とか言ってるの（←ありがちでしょこれｗ
匿名以外じゃ表に出さないが、女の子と仲良くしたい（いや男でもいいんだけど）のは単に甘えたいからだし、甘えたいのはセックスしたいからじゃなくて寂しいから。
陵辱ものエロゲ（触手が好き）をよくやるのは、女の子をレイプしたいからじゃなくて、アヘ顔ダブルピースの女の子の快感が気持ちよさそうで俺も体感したいから！！！（エネマグラ
こういう感情、わかります？わからない？わかんねーなら黙ってろよ、２０世紀の規範に囚われたアホの正義の味方の啓蒙主義者共が。
いまだに通例行事のごとく男尊女卑、家父長制、セクマイ差別、ミソジニー・・・と唱えた所で、ここは2011年ですよ。わかりませんか。
お前らがテレビと紙で三次元のポルノを見ていた子供時代に、俺はモニタでポルノを見ていたわけ。初恋愛がネット上の時代なわけ。知り合い20人いれば1人は女装してるの。はてなのインテリ気取りがボーイズラブのゲイに対する差別性とまで語っていて爆笑したけど、BLは男も読んでるの。もはや感覚が何もかも違うの。
昭和共の『敵の無意識ほじくり返し戦法』で『どや顔シングルピース』が通用するのは『全く同じ思考体系を持ったお前の同世代』だけだろっての。古いわばーか。
そろそろお脳のアップデートをして下さりませんかね？？
二次元のポルノ見て『どや顔シングルピース』で『やや、この作品の根底に流れる性差別性は・・・許せませんぞ～～～（どかーん！）』とか、笑ろてしまうからやめろや。
俺みたいなスタバでAirを弄るドヤ顔野郎、他に、いますかっていねーか、はは
「キャラメルフラペチーノのトール」 とか 「カプチーノのショート」 とか
かたや俺はレジでAirに表示したメニューを指差し、呟くんすわ
「コレもらえるかな？」
狂ってる？それ、誉め言葉ね。
尊敬する企業 Apple（カレンダーアプリのパクリ行為はNO）
週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい！と柄にもなく思ってしまった。
ここまで、日本語でウケを取り、アメリカ人にしか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・！
この人のセッション、ブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルのセッションに格上げされた。こんな人がいるとは。
で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ：
Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。
なんという激熱トーク。本当に小さかった南米のRubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で８０箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。
最後の時間オーバー後の「あと一言だけ（本当はあと１分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w）」でどんなにダメだとされていても、諦めずに進めという、過去の偉人が貶められたり失意にあった時代の動画もよかった（もっとも、この話は知っていたのでインパクト自体は薄めだった）。
この後はLTとクロージング。
インパクト強すぎｗ
これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと
真面目に受け取ったらヤバイ発言多すぎだろ・・・
こ れ が 締 め の 講 演 か よ ！
そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。
その後の高橋さんの最後の挨拶とスタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。
隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミングが大事！とすぱっと立ち上がってみてよかった。その後前列の人がみんな！立とうよ！みたいにやって一気に雪崩状態。
これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、
こんな一日だった。熱かった・・・
質問に答えてあげたり、一緒になにか探してあげても「私：これじゃないですか？」「非モテ：ああ…。」とかで終わるのでモヤっとする。
感謝してほしい訳じゃなくて、「ありがとうございました〜！」「すいませんでした〜」って、会話の終わりが明確にするために、必要だと思うんだけど。。
ちなみにこの人は話しかけてくるときも突然「これって…」とか言ってくる。今大丈夫ですか？とか全く聞かない。
もちろん人の会話ぶったぎりで話しかけてきたりもする（なぜ…）
その人が使用後の給湯室／休憩室の流し付近は床まで水滴がたくさん。。きっとトイレも汚いんだろうなあ…。
会議室／休憩室のイスを戻さない。ようじとか小さい袋とかなにかしら片付け忘れてる。
もちろん「忘れてますよ〜」って言ってなんか渡しても「ああ…。」
例えば・・・うちの新入社員はゆとり世代なんだけど（当たり前だが）その子がなんか面白い言葉間違いをしたときに、
教育係の子が「も〜○○くんはゆとりだからな〜」って言ってみんなで笑ったんだけど（ちなみに本来はすごいできる子）。
そしたら非モテ、１日中なんにでも「ゆとりだから〜」を付けてその子に話しかけてた。もう若干その子キレてたと思う。。
ってな感じで、この会話だと笑ってもらえる！と思うとひたすらそれにしがみつくからうざいのなんのって。。
ちなみに彼ら、見た目はほんと普通。。
【先遣隊遺失物調査官Gentyによる思考ログ】
温度モニタに示される外気は、とても冷たいものであった。ただ「外気」といっても、この巨大な《ストラクチャー》に「内や外」があればの話だ。
今のところ、我々の先遣隊のいずれもがこの《ストラクチャー》の「境界」を発見してはいなかった。
三次元フォログラムはその「部分」を視界に示すが、この《ストラクチャー》の位相的性質については未だ明らかになっていない。
もちろんその中心部には惑星《ゴブ》の「大地」があるだろう。ただこの《ストラクチャー》がその大地に「根ざして」いたり、「建って」いたりするというわけではないようだ。大まかに言っても、この《ストラクチャー》は今のところ、この惑星を「包み込んでいる」。
それにしても寒い。この環境は有機生命体には最適化されていない。概ね、高純度ケイ素体の電磁誘導のために最適化されている。にしても、この環境が最適化の結果であるとも言い切れない。今のところその境界と同様に惑星《ゴブ》の「自然と人工物」の区別もできていないからだ。
フォログラムの断片から窺えることは、この《ストラクチャー》がフラクタル的複雑性を持つこと、有用性以上の目的をもった装飾が見られること。付け加えて―これは先遣隊文明調査局によって明らかになったことだが―この《ストラクチャー》が彼らの創造主たちが《baroque》と呼ぶ様式に近いことくらいである。
引用 : http://nidasoku.blog106.fc2.com/blog-category-3.html#entry829
133 名前： すずめちゃん(茨城県)[] 投稿日：2009/01/21(水) 11:00:53.92 ID:RDis6JId
９ｔｈまでやった
いい加減選曲のときに曲聞かせろよな
134 名前： すずめちゃん(新潟・東北)[] 投稿日：2009/01/21(水) 11:02:48.13 ID:aooI1Ine
>>133
どう考えても改悪だろそれ
184 名前： すずめちゃん(catv?)[] 投稿日：2009/01/21(水) 12:36:04.16 ID:SyrCnTC/
>>133
・曲プレビューが無い
・同じ曲を２回選べない
いつまでも「クラブというのはそういうもの」という古参談話が継承され続けています。
つかビギナーモードで実装してるんだからSTANDARDモードでもやれよと。
あとEXPERTの全曲名表示とか、稼動時の段位上限八段縛りとかさ。
他の音ゲーに比べてインカム増えないのはそういう古臭い部分があるからなんだよ。
186 名前： すずめちゃん(茨城県)[] 投稿日：2009/01/21(水) 12:43:45.34 ID:RDis6JId
>>184
190 名前： すずめちゃん(catv?)[] 投稿日：2009/01/21(水) 12:54:29.17 ID:SyrCnTC/
>>186
うむ。
・選曲BGMが聞けなくなるだろ
・無くても困らない
ホント、ジャンル名だけでどうやって判断しろというのか。
「ELEMENTAL CHANT」とか「AMERICA」とか「HYPER JAPANESQUE」とか酷すぎ。
192 名前： すずめちゃん(アラバマ州)[sage] 投稿日：2009/01/21(水) 12:57:55.48 ID:6cwzwhSv
>>190
インテリジェンスと言いつつ、かまいたちの夜のパクリ曲だしなｗ
195 名前： すずめちゃん(アラビア)[] 投稿日：2009/01/21(水) 13:08:34.98 ID:H+jyZof8
>>190