 
|
はてなキーワード: GUIとは
第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 練習問題
オブジェクト指向が難しいというならそれこそLLでいいと思う。
オブジェクト指向わかんないのにリッチGUI作ろうとするなんてどうかしてるし、よくわからんけどなんかできたなというだけでなんも身に付かないと思う。
直接関係無いけど、SIerの人かな？
GUIでなんかよくわからないボックス配置とかしてなんか処理を書くとなんか動く、というような環境をいきなりやっても
↓
馴染むための登竜門って意味で言えば、VisualStudioなどのGUIでデバッグが出来る環境をもった言語が良いし、VB,C#などのサンプルが豊富で結果を確認しやすい言語が良いと思う。
グラフィカルに窓とかボタンとか出てきて、ボタンを押すなどのアクションに対してリアクションをコーディングできる、VBマジお勧め。
イベントドリブンの処理とか、タスク管理とか、環境に関する基本的なコーディングを一切書かずに、ロジック部分だけ書けるしね。
プログラミングは静的言語(C/C++,Java,C#など)と動的言語(rubyとかpythonとかperlとかいわゆるスクリプト言語)と関数型(lispとかF#とかhaskellとか)を一つずつくらい眺めた方がいいと思う。
どれか一個くらい自分に合ってるのが見つかるかも。
やりたいことにどの実装系が一番適しているかを考えるべきで、実装系を目的に合わせるべきじゃない。
そういう考えでいると、PHPで何でもやる奴とか出てきて迷惑なんだ。
そもそものロジック構築などは、ターゲットには依存しても、言語にはほとんど依存しない。
馴染むための登竜門って意味で言えば、VisualStudioなどのGUIでデバッグが出来る環境をもった言語が良いし、VB,C#などのサンプルが豊富で結果を確認しやすい言語が良いと思う。
覚えている限りの時間の流れの中から、世の中に存在するコンテンツを分けてみるテストです。
パソコンが外につながっていることが珍しかった時代。新大陸が見つかった状態。新し物好きかつパソコン好きが移民していった。パソコン通信くらいしか商売になっていなかった。作る人と使う人がイコールだった。何かをするにはコマンドを打つ必要があった。
最初は、学者さんの論文の発表やストックするのに使われていた。
イギリスのホストにつないでmozaicでなんて時代には、論文の延長のノリで研究室のメンバーの自己紹介ってのがあった。実は、実名うんぬんってのは、一番最初にやっていた。
ここで、実名を名乗るのかペンネームを名乗るのかの分かれ道。すでに実社会でしっかりと活動している人は、実名でやっていただろうし、ひとりで楽しむような趣味の人や背徳感がある人はペンネームやハンドルネームになったんだろう。
全国の日帰り温泉のまとめのような個人が足で調べた価値の高い情報が高い確率で存在した。
まめな人は自己紹介のついでに日記を書いていた。当時はコンテンツマネージメントシステムは一般に普及していなかったので、htmlを手打ちして、ftpコマンドで送信。量が増えると大変だった。メールをみるときはなんちゃらtermというソフトでコマンドを打ちながら見ていた。
デジカメが普及するまでは、写真を取り込んだりイラストを取り込んだりするのは、お金がかかることだった。まして、高価なグラフィックソフトなど夢のまた夢。デジカメが普及したあとは当たり前になった。
取り込むためには専用の拡張ボードが必要だった。カメラも高価だったし。2GBの壁があって、長い動画は編集できなかった。高画質な動画に仕上げるためには職人芸が必須だった。大容量の動画をあげるサーバーはほとんどなかった。
音楽を作る人は、midiの配布していた。有名な曲のコピーが多かったので、大人の事情でほとんど閉鎖。
無料のホームページとセットのような感じ普及。ホームページ自体散発的なもので、同じ趣味趣向の人たちで同盟とか組んでいたよね。
大量に生成されるコンテンツは個人の手を離れていった。新大陸はいくつかの勢力に分かれて群雄割拠の状態。広告枠として大きなお金が動くようになった。作る人と使う人が区別されるようになった。グラフィカルユーザーインターフェイス(GUI)が、あたりまえになり、コマンドを打つ必要はなくなった。
地図が見れるようになった。パソコンにインストールしていた時刻表やルート検索がwebになった。
コンテンツマネージメントシステムが無料開放された。htmlの作成もftpも必要なくなり、気持ちや感情の発露のみを文章や写真にすればよくなった。改行を大量に挿入してスクロールバーを有効にして、文章を読むためにマウスのホイールをまわして文章を読むときに指の動きを加えて、読んだ感を高める手法が流行る。
会員制の閉じたサービスが登場する。内容は日記、掲示板と基本は同じだが、個人が設定する必要はない。テクニカルな要素がなくなったので、気持ちや感情の発露のみを文章や写真にすればよくなった。携帯電話からコンテンツを作る文化の先駆者ともいえる。携帯しか使わないユーザー層があらわれる。
写真のアップロードも無制限になった。デジカメの画質が上がってもリサイズする必要もなくなった。
動画を受け止めてくれるサーバーも増えた。ブログやSNSのおまけ的存在だったが、Youtubeの登場で無差別級のサービスになった。カメラで撮影した時点で、パソコン用のファイルになっているのも参入障壁を下げた。
たとえば、全国の飲食店をすべて載せるとかそこに感想や評価を付けるようなサイト。個人が手弁当でまとめていた情報を商売にする会社があらわれた。
感情の発露がリアルタイムになる。「つぶやき」という概念が生まれた。新大陸を制覇しようとする勢力の攻勢が高まる。作る人と使う人に加えて踊らされる人が登場した。「更新されたよ」ボタンをクリックするだけで、ダラ見ができるコンテンツが優勢となる気配。
ゲームとかやることが多くなりすぎた。
発展期に登場した便利サービスの中で脱落するサービスがあらわれ始めた。
大きな掲示板のスレッドには、約1000個の書き込みがある。その中から文章を選んでコンテンツを作る手法。新聞の読者投書欄のように投書されたご意見の中から好きな意見を載せることができる。文章ロンダリングやソースロンダリングという言葉が生まれた。
コンテンツの提供形式として、素人作成風味の味付けをする企業・組織があらわれた。個人が大きくなったのかもしれないし、何者かに組織されたのかもしれない。この手の人たちは頼んでもいないのにどんどんコンテンツを作る。
midiサイトに対する警告に比べると2次元コンテンツはゆるい。コンテンツホルダーの手が回らないくらいにあふれいるのか、あえてあふれさせているのかはわからない。黎明期ならばまつりになっているような内容のものがあふれいる。包括的に権利処理されているのかもしれない。
趣味じゃなくて仕事の人が増えたのだろうか。仕事でwebに出るといっても会社の看板を背負うと個人ではなかなか発言できないはずなんだけど。よくわからない。
P.340
・パスにスペースの入らない(たとえば、My Documentsなどは、途中にスペースが入っているのでエラーになる。アンダーバー「_」は可。)
フォルダ(C\Testなど)を作る。 →以下フォルダAとする。
2/ 実行ファイルを作りたいスクリプト(○○.rb)ファイル自体も、2バイト文字、半角でもスペースの入らないファイル名にする。
→「5-05-04 ride block.rb」といったファイル名は、スペースが入っているのでダメ。
3/ フォルダAに、ActiveScriptRubyをインストールするとできる「ruby console」ショートカット(everythingで検索)のショートカットを、そのフォルダにコピーする。
4/ フォルダAに、実行ファイルを作りたいスクリプト(○○.rb)を、Imgフォルダ等と共にコピーする。
5/ フォルダAに、fontを、fontsフォルダごとコピーする。
6/ フォルダAに、Ruby/SDLのDLLをそのフォルダにコピーする。15種類。
→DLLフォルダを、ではなく、exeファイルの置かれる場所に、DLLファイルそのものを直接並べる。
フォルダAにコピーしたruby consoleを起動 →コマンドプロンプトの後に、「ruby ○○.rb」とし、スクリプトの起動を確認する。
8/ フォルダAにコピーしたruby consoleを起動 →コマンドプロンプトの後に、「mkexy ○○.rb」とする。
→ゲームが起動するので、終了させる。
9/ ○○.exy ファイルを、メモ帳等のテキストエディタで開く
10/ 初期値は「core: cui」となっているのを、「core: gui」に変える。
→変えなくてもいいが、その場合、実行時にコマンドプロンプト窓が出てきて邪魔になる。
11/ フォルダAにコピーしたruby consoleを起動 →コマンドプロンプトの後に、「exerb ○○.exy」←今作ったファイル とする。
12/ 「○○.exe」をダブルクリックして実行、起動しなかった場合、2～5のプロセスに、コピーし忘れがある。
13/ 配布物は以下の通り。
・実行ファイル「○○.exe」 →ファイル名は任意に変更可。(もちろん.exe以外の名前)
・fontsフォルダ
http://www5.ocn.ne.jp/~m-shin/windows/windows-vista-proxy.html
WinHTTP(AutomaticUpdateなどが利用)へ、IEプロキシ設定のインポート。
なるほど...と言いたいところだが、
proxycfgのコマンドを残して内部処理だけ変えるってのも、
何かの理由があって嫌だったんだろうな。
むしろ、IEとWinHTTPとで設定が混在するような設計を避けてほしかった。
似た例とすれば
W32TMのNTP設定とGUIの時刻同期設定も微妙に別だし。
開発チームが分散していて統一設計が苦しいのかもしれないが、
ＯＳ論争のほとんどでそうなんだけど、前提条件が違いすぎてかみ合わないよね。
「Mac」も「Linux」も、「Windows」でさえ、人によって体感は違うと思うんだよね。
「Linux最高だぜ、ふぅーははは」って人に良く聞くと、viやEmacsを極限カスタマイズして、
コマンドラインさえあれば、他にツールなんていらねぇって人だったりする。
同じことが「Windowsでは出来ない？」そりゃそうだよね、対象としてるユーザー層が違うもの。
これはWindowsユーザーからすると逆のことが言えて、「なんでこの程度のことＧＵＩで提供されてないの」となる。
それは仕方ないんよ、「Linuxコミュニティ」では、「それはシェルで○○××△△と書けば出来る」とか言われちゃうんだから。
「Windows」は当初（今も）GUIの仕様をガチガチにしなかったんだよね。
指標は示しても、後はメーカー任せ。
シュートカットの機能、コントロールの挙動、メニューやなんかも各社バラバラ。
けどこれって、「Windows」が悪い訳でもないんだよね。
縛らなかった分、多様性は生まれたし、それがこれだけの帝国を支えたわけで。
結論、全部持って、全部使えるのが最強。
私は昨年度、ゲーム系専門学校を卒業したが、内定なしでの卒業だった。
就職活動は見かけ上は頑張っていた。見かけ上は。
しかし、これは就職課の言う「受けろ受けろ受けまくれ！」という言葉を実践していただけで、今思うと受かることより受ける事に比重を置いていたのが良く解る。
受ける会社に入る気はあったのだが、入ってから何をしたいかとかは一切考えず、とにかく受けられるから受けていた状態である。
良く書き損じていたので履歴書は何枚書いたかも良く解らないけど、中身のない履歴書だなとは活動中常々思っていた。
正直なところ、活動中は自分は何も持っていない人間だと思い込んでいたし、今でもそう思う
というわけで、今までの人生を振り返ってみることにする
幼稚園児の頃は普通に友達を作り良く遊んでいたが、基本いじめられっこであった
家では偶にMS-DOSを触ってインベーダーゲームだのブロック崩しだのをやっていた
小学校に入ってからも低学年の頃は大方似たようなことをしていたが、PCはWindows95になっていた
CUIとはおさらばして、GUIでレーシングゲームとかをやっていた記憶がある
中学年くらいでネットとエロサイトを覚え、Yahooでアダルトサイトを探していた
この頃にはWindowsの基本操作はマスターしていて、ローマ字も当たり前に知っていたので小学校のローマ字の授業は楽ちんだった
当時の私は非常に馬鹿だったので、毎回「ア」とだけ入れて検索して、何ページもめくって「アダルト」のカテゴリにたどり着いていた
勿論使っていたのは親のパソコンだったので、ばれないように履歴を消したり、Q2ダイアルのアプリを消す方法も身に付けた
誰からも教わっていないのにQ2ダイアルのソフトが出ないように始末できた自分は凄かったと思う
この頃は文系である社会と理系である理科の成績だけが妙に高かった
中学生活が始まると親からお古のノートパソコンを貰うことが出来た
この為、非常にインターネットに入り浸る最悪の生活が始まった
これが非常に楽しく、社会人や主婦を相手にし良くお喋りをしていた物である
あちらからしたら、こんな年少者がいるなど驚愕の沙汰であったのは間違いがない
そうこうしていると、親からはネットの禁止令が出たが、幸いにもパソコンと回線だけは奪われなかったので、ありとあらゆる手段を使い隠れてネットをしていた
丁度自室の真上の部屋にモデムがあったので、親がトイレに行った隙などを見計らい電源を入れて、水が流れた音がしたら電源を切るなどの姑息な事を良くしていた
最後はモデムのある部屋に南京錠を掛けられたが、ばれないように錠前そのものを外して部屋に入ったりしていた
勿論、勉強などしているはずもなかった
自体はどんどん悪い方向へしか行かなかった
因みに部活はテニス部に入ったのだが部活は性に合わないという事で三ヶ月で抜けている
中学２年になるとゲーム系のコミュニティサイトに入りびたりはじめ、そこでの交流に嵌ってしまう（そこの年齢層は小５～高１程度）
そうこうしている内に自分のWebサイトを立ち上げようと思い、HTMLの勉強を始めた
リファレンスサイトは殆ど見ることなく、正直ソースコードの改変で知識を蓄えていた
ぶっちゃけ中身のないサイトだったが、毎日日記だけは書いていた記憶がある
このサイトを運営していく中で色々な事もあった
他人のサイトで迷惑を掛けたり、こっちが掛けられたり
まぁ中２らしいと言えばらしい、そんなネットライフを送っていた
そして中３になり、更に事態は悪化した
リアル友人の勧めや、ネットで知り合った人たちの勧めなどで人生は素敵な方向へねじ曲がる
まずラグナロクオンラインとかいうタイトルを知ってしまう
まだこの頃プレイできる環境にはなかったのだが、プレイしたいという強い願望にかられた
それとはまた別にシスタープリンセス、灼眼のシャナ、Kanon、AIR、みずいろ、月姫、水月などと言った作品と出会ってしまう
いわゆる萌え系作品への出会いだ
高校に入ると新しいノートパソコンを親から買ってもらい、ラグナロクオンラインを始めた
これのおかげで高校の成績は常にカスだった
高校時代やったことなんてラグナロクオンライン以外にいう事がないくらいだ
しいてもう一つ言えば、小遣いと昼飯代とお年玉を全てエロゲーとエロサイトに回して3年間で20万くらい使ったこと
イーバンクはやばかった
そして上京してまで専門学校のゲーム学科に入った、今思えばソフト学科に入るべきだったと思う
理由は座学より実践でしょ！とソフト科の教師に言われたというそれだけ（ゲーム学科は実践、ソフト学科は座学が基本だった）
心機一転ネトゲは辞めようという事でアカウントまで消したのだが、勉強への熱意は半年で消え
その後はネトゲのアカウントを消したという後悔の念に苛まれて何もやる気が起きなかった
二年目にして、ネトゲへの復帰を果たし、再びネトゲ廃人になった
就活もしていたが、冒頭で述べた通り芳しくはなかった、そもそもやる気がなかった
ただ、そんな中でも真面目に受けていた授業がなかったわけではない
１年～３年にかけ、ゲームプログラミングはクソだと思っていたのだが、ゲームと関連性のない授業はまともに受けていた物が一部にあった
特に３年のアーキテクチャとアプリケーション開発は大分真面目にやっていた
最初はフリーターにでもなろうかと思ったが、決心が固まらず新卒者就職応援プロジェクトに応募した
そして、もうそろそろ一年が経とうとする今、結果として３社回った
専門学校での就活は40社受けたのだが、業種は絞らずありとあらゆる業界、業種を受けていた
働ければ何でもいいと思っていた
でもインターンをしてみて思ったのは、働ければ何でもいいなんてことは全くなかった
始めの工業系は仕事がなかった、楽ではあったのだが何か違うように感じた
営業系は仕事はあるが、とてもじゃないがモラルも糞もないし、その内訴えられて潰れそうなことばかりしている
少なくとも社会貢献と言うより、社会を破壊する業務しかしていない
客を欺き、金が落ちた後なら客がどうなろうと知った事ではない
とてもじゃないがこんな思想の元で働きたくはないと思った
ニコニコスマイルで限りなく詐欺に近いか、正真正銘の詐欺である営業をさせられるのは辛い
そう、働ければ何でもいいなんて言うことはなかった
そりゃ座ってるだけでお金がもらえるなら、それに越したことはないんだろうけど、それだと将来が不安過ぎる
もし会社が潰れたらどうなるのかなんて考えた日には転職先がありゃしない
気が付いたら、もうネトゲはしていなくって、むしろほとんど遊んでいない状態だ
今はまだその詐欺営業の会社に身を置いているのだが、業務上でも色々考える事が合ったりして、それを考えたり
後はPHPでTwitterのAPI叩いたりするものを作ったり、Perlでファイルフォーマットの変換スクリプトを組んだりしている
最近こういう事をしてて思うのは、プログラミングっておもしれーなってことだ
正直今の私の技術力なんてミジンコレベルなのだけれども、今更やっと進みたい道が見えた気がした
人生の本当に長い間、多分私は寝ている時間を除けばパソコンに触れている時間が最も長かったかもしれない
今まで散々遊んできた分際でいうのも生意気だろうが、IT系の会社に行きたい
やりたくもない事をやっても仕方がないし、やる気が出ないからどの道何も進まない
ITならやる気が出るのか？と聞かれたら、少なくともほかのよりは出るとしか答えられないけど、でもやりたい
就活でも最終面接まで二度も行けたのはIT系だけで、一般職の結果は散々たるものだった
正直、そこらの人よりはITが好きだし、技術に興味もある
ネトゲやつまらない事しか書いて無かったBlogやTwitterも今では更新頻度が減り、技術勉強ノートと化しているし、Pukiwikiを立ててノート代わりに使ってもいる
自分が長く接してきたのはWebだから、特にWebのシステムやサーバーの運用に興味がある感じ
あとは、Tweenみたいにな多くの人に利用される一般アプリも作ってみたいって願望もあったりはしますね
今までは情熱の欠片もない就活ばかりしてたけれども、今度からはもっと上手くいきそうな気がします
ここ最近まで大して就活する気がなかったけれど、今になってようやく就職する目的、情熱が見つかった感じです
一体ここまで遊んできた私に何ができるのかは謎ですが、出来る限り今後は頑張って行きたいと思います
ぶっちゃけ遊ぶだけならもう散々遊んできたしね
そこで置き忘れてきたものを今からでもなんとかして取り戻す
かつてアップルは、ipodと同時に自社で開発した音楽管理ソフト『iTunes』を公開した。
このソフト、フリーである。音楽を簡単に管理できる。しかもmp3の変換なども非常に簡単。
有料で売っても良いはずのこのソフトを、アップルは無料で公開したのだ。
大きな理由としてアップルは、ユーザーが各自バラバラに管理していた音楽ファイルを
統一して整然とした内部構成にしたかったのだ。現に今、iTunesをインストールしているユーザーの
My MusicにはiTunesのフォルダがあるはずだ。そしてそこに、アーティスト別、
アルバム別にフォルダ分けされたmp3が入っている。整然とした内部構成を歓迎したのは、
アップルの人間だけではなかった。音楽とネットとPCが大好きな連中が、こぞってiTunesを『クール』に、選択し始めたのだ。シンプルでメタリックなGUIも良かったのだが、iTunesが流行った最大の原因は、iTunesが世界標準になって音楽ファイルの管理の最大手になったからだろう。何かがグローバルスタンダードになれば、
大勢の人がそれにあわせようとする。その方が便利だからだ。
そんな風に標準化していけば、内部の精度も上がる。結果的にiTunesは、音楽をインポートして
管理するには最適のツール、というかもはや定番になった。CDをインポートするのはiTunesで、
実際に曲を聞くときは別の音楽再生ソフトで聞いている人もいるらしい。
それぐらい、iTunesは『音楽を管理する場所』として信頼されている。
さて、出版社では今、『各自』でさまざまな試みを行っている（もっともその中の７０％は現状維持だと思うが）が、
『各自』ではダメなのだ。各自ではなく、アップル様が開発したiTunesっぽい書籍管理ソフトに、みんなノればよいのだ。
そうすれば、書籍のデータも、iTunesライクに管理できる。
タイトルとかでグラフィカルに並び替えできる。PCの中で書籍データが、時に整然、時に騒然となっている様は、見ていてコレクター心をくすぐるものがある・・・。
iPadにはそういうのがあるんだっけ？ なんか、急にほしくなったよ。
10 ：名無しさん＠お腹いっぱい。[sage] 投稿日：2010-07-08 14:19:43 ID:4+wg75AQ0
シビアなキーカスタマイズが絡む場合は、AHKかkeyhacのPython使うほうがいいかもしれない。
キー操作が絡んで、かつ速度を求めないなら、AHKやkeyhacからWSHやAutoITのスクリプトを走らせてもいい。
AutoItXはWSHから使えるのが便利なところ。素のAutoItのGUIの部分は使えんけど。
ＧＵＩ使いたきゃ、HTAから使ってもいいし、ほかのＤＬＬ使ってもいい。
SFCminiのDLLとSeraphyのDLLまで使えば、UWSCやAutoHotKeyとほぼ同等のことを
javascriptやVbscriptの文法で出来てしまう。
テキストエディタなどWSHやdmscriptを使えるアプリのマクロからも、
他のアプリを制御したり、他のアプリのウィンドウの情報を取ってくることが簡単になる。
もちろん、出来ないことも大いけども。
いちいちコマンドラインツールを探さなくても、とりあえず今使ってるアプリを
スクリプトから制御することが簡単になる。
ボックスモデルがどのようにレイアウト構築するか理解した事が無いのかな？
文字と絵をレイアウトするものは大概ボックスモデルをベースに作られてるだろうが。
そのFlashだってActionScriptやFlexで配置指示してしまえば、お前さんが言うめんどくさい組み方になると思うがな。
だからスティーブジョブズも奇妙なWeb標準なんか放って置いてiOSのアプリを書かせようとしてるんだと思うよ。
少なくともUI要素をインラインで配置なんて訳わかんないことしなくていいでしょ。
えぇと、InterfaceBuilderしか使ったことしか無いのか。
どのみち、InterfaceBuilderで出来ない事やろうとしたら、めんどくさい組み方になる。
変人で悪かったな。
PHPから動的にPDF吐き出すとか、実装するならテキストベースのレイアウタ使ったほうが楽だろうが。
変人が標準って変だよ？
それを、何も判って無いお前のような奴が多少は使える気になって喚いてるだけ。
開発側は最低限の物は用意してるんだ。
気に食わないなら、自分でWYSIWYGのシステムでも組んでりゃいいだろ。
でもさ、
いまどきマルチメディアなコンテンツをテキストベースで書くのってどうよ。
HTMLとかCSS決めてる人ってどう使われるか想像したこと無いのかな。
DreamweaverってCS4からCSSの設定の和訳を止めたんだよ。
なんでかって言うと和訳された意味より、CSS原文のキーワードのほうが重要だから。
つまりもう降参です僕はテキストエディタですって事だよ。
WYSIWYGなんてはるか遠い昔の話だよね。
今まともなGUI付いたインターネットコンテンツ作成環境ってFlashぐらいだよ。
Flashってもう仮想環境だからアプリ書いてんのと同じだよね。
だからスティーブジョブズも奇妙なWeb標準なんか放って置いてiOSのアプリを書かせようとしてるんだと思うよ。
少なくともUI要素をインラインで配置なんて訳わかんないことしなくていいでしょ。
なんでこんな面倒臭いことになったのかなあ。
だってポストスクリプトやPDFをテキストエディタで書く奴なんか変人でしょ？
変人が標準って変だよ？