「バッファ」を含む日記 RSS

はてなキーワード: バッファとは

2011-12-20

RegQueryValueEx REG_SZ UNICODE版とANSI

値はLPBYTE 型のバッファに返されるが

RegQueryValueExAやRegQueryValueExWと、

ANSI版かUNICODE版かを明示しなければ

UNICODEANSIとして文字列を返してくれるようだ。

AとW の違いは引数パス指定だけではない。



LPBYTEだから

文字列気遣いしてくれなくて ANSIで帰ってくるかなと勝手に思い込んで

MultiByteToWideChar を呼んで余計な変換を増やしてうまくいかなかった。

2011-12-12

コンピュータプログラミング概念技法モデル」の目次

第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 練習問題

2011-10-31

信者情報/福貫

福貫

2011年ドラフト会議を鑑賞する巨人ファンhttp://www.youtube.com/watch?v=J4fanzhZrBo)で一躍有名となったピアキャス信者

糞貫とは


決め台詞

  • 気分悪いわー
  • ボケFuck!
  • うぉぉぉぉ!いなずまぁらいこうざぁぁぁぁん!

沿革

掲示板

1 名前名無しさん[] 投稿日:08/04/01(火) 18:06:59 ID:2RwJz0c7

はじめまして^^

『配信者でよかったぁーーっ!』

理由は"デブな男は嫌い"とのこと

と福貫自身は語っていたが後にm9板ニュース速報スレで福貫の嘘が暴かれる。

346 伊藤かな恵 mail:sage  08/08/22(金) 20:35:46 ID:NVBCmxj3

ゆかまとピー太のスカイプ終了後

福貫がゆかまのスカイプに凸して

「わざわざ眠いのにかけた」「ピー太と話したかったのに」

「(ゆかまの)名前もわからない」などと発言

福貫がピー太と話しゆかま無視で会議通話乗っ取られる

まりに失礼なため初のスカイプブロック

ちなみに>>342は捏造

  • 2008.9.28
    • 競馬配信中、阪神10R神戸新聞杯で8.0倍の的中馬券となる馬単1-10に3000円賭けたつもりが勘違いで11Rの馬券を買ってしまいJRAにブチ切れ苦情メールを送るも黙殺される。さらに買ったほうの11R摩耶ステークスの結果は馬単2-15だったため配信は怒りの緊急切断となった。
  • 2008.10.10

一緒にビールかけを試みるも放映権を持っているフジが中継せず朝日報道ステーションまで待つ事に。

待たされている間にすっかり落ち着いた福貫は報ステビールかけが中継されると同時に

自分も頭からビールをかけるがカメラ解像度が低いためリスナーにはよくわからないという体たらく

あっというまに朝日の中継が打ち切られ、残されたビールまみれの福貫はジョッキ一杯のビールをかけて配信を締める。

天誅 千乱 →リスナー受けが芳しくなく、すぐ止めてしま

パワプロ15 栄冠ナイン 目指せ甲子園 →甲子園優勝までやり続けると宣言したが、結局うやむや

マリカー →全コースのレコード更新を掲げるが、やはり結局うやむや

22時間を過ぎたところで、サライを流して配信を止めてしまい 24時間不達成

福貫、誠意とは何かね?

本物だったら次で抜けてくれというレス通りにNOBUOは次のレースの後去っていった。

始めは偽物と叩いていたがどう考えても本物でした本当にありがとうございます

↓偶然にもNOBUOに勝った瞬間

チーズケーキと山盛りの雑炊を一人、黙々と食す

レス「お前本当に一人なんだな.....」

レス「この後自殺しそうだな・・・

二つ合わせて約216万円の大勝利配信でピアキャスドリームを作る

福貫『景色虹色毎日が楽しくてしょうがない』

  • 2009.1.21
    • FXで有馬で当てた200万をさらに増やそうかと悩む。

そこでデモ口座で3億円分挑戦してみたが見事に破産

デモでよかったなw

  • 2009.1.25
    • 福貫『今なら100%勝てる、もうバイトもやめるわ』

この可笑しな自信家を誰も止めない点から見て、リスナーは相当の精鋭の模様

  • 2009.1.28
    • FXで上手く行ってるためバイトを辞めようと考える福貫。

しかし今のバイト先に迷惑をかけないように徐々にシフトを減らして辞めようとするが・・・

866 名前:福貫 ★[] 投稿日:09/01/28(水) 18:36:11

休憩中に携帯で書き込んでたんだよw

帰り際に株やりたいから減らして~的な事を伝えました

そんでありがたい事に、軽くお説教してもらいました

心配してもらって嬉しかったです(T_T)

結局シフト減るかどうかは分からないです

みんなもありがとね

どうしてこうなった・・・

  • 2009.2.12
    • 専用スティックとスト4、あわせて2万円を意気込んで投資

しか格ゲーの敷居はズブの素人にとってあまりに高く数日後に挫折転売

結果、糞アフィブログの持ち主、頃飯だけがおいしい汁を吸った

ネットヤクザ福貫『おいリスナーどもいいか?俺のとこのアフィ踏め』

その報告と今後の相談をするためにニートから正社員になった配信中の葉月さんにスカイプで凸

有馬記念から4ヶ月で福貫の人生をここまで転落させたリスナーは相当の精鋭の模様

まり引退

  • 2009.5.18
    • 暇だったとのこと

まり復活

抽選王で全くの手付かずだったワンダと巨像が選ばれ、プレイ

福貫いわく、一日一巨人と徐々に進めていくということ

腹いせに箱○をサクリファイス


打開したもの

PS2 ようこそ ひつじ
Wii 実況パワフルプロ野球15 栄冠ナイン
ドラゴンクエストソード
Wii VC 風来のシレン(テーブルマウンテン、掛け軸裏)
XBOX360 Fable 2
PS3 ブレイドストームデモンズソウルゴミ箱、トマランナー

挑戦中のもの

FC
PS2
wii マリオカート
XBOX360
PS3 Skate 2
リアル 巨人応援配信

挫折したもの

FC スーパーマリオブラザーズ忍者龍剣伝
PS2 Persona3、ゴッド・ファーザー
テイルズ・オブ・ジ・アビスデカボイス
ジ・アニメ スーパーリミックス 巨人の星
女神転生3ノクターンマニアクス
wii 悪魔城ドラキュラ
XBOX360 あつまれ!ピニャータ2天誅 千乱、 スターオーシャン4
リアル 24時間配信、オフ会ダイエット、FX、女

破壊したもの

Wii マリオカートWii ディスクを粉砕
箱○ Xbox360本体 ←new! テーブルのペットボトルが倒れて水浸し

ゲーム大会の参加実績

996 名前:名無しのリスナーさん[sage] 投稿日:2008/06/13(金) 00:41:45 > > > > > ID:fG/.J2iY

5456-0318-0904

お願いします僕も参加したいです

一応配信できます! ふくぬき

998 名前:名無しのリスナーさん[sage] 投稿日:2008/06/13(金) 00:48:39ID:sVX/XeWw

>>996

ごめん、もう枠いっぱいになっちゃった

万が一出れない人がいたら変わりにでてもらう補欠あつかいでも良い?


その他


福貫家の華麗な一族

  • 妹の学費を捻出するため、帰宅後は自家製の野菜の出荷のためをせっせと袋詰めする真面目な父貫     

「おい福貫よ、あいつらのウナギ、梅だぞ」

「ねぇぬんぬー、お金貸してぇ」

  • 兄に貸しを作ることを異様に毛嫌いする妹貫

「兄じゃ、クリームパンやって!」

  • 近所の老人コミュニティの中で疎外され肩身の狭い思いをしている祖母貫

よくカレーを作るらしいが福貫いわくジャガイモばっかりで味もあんまりおいしくないらしい


配信環境

CPU Core2Duo E6550
Memory 2GByte
M/B
VGA GeForce 8300GS
Sound
回線
ルーター
キャプチャ GV-MVP/RX3
マイク 1000円くらいのやつ
Webカメラ
コントローラー

WME設定

配信対象
オーディオコーデック
オーディオ形式
ビデオコーデック
ビデオビット レート
ビデオサイズ
フレームレート
キーフレーム
画像品質
バッファ サイズ

2011-10-06

WINPCAP 4.1.2 を使ったアプリケーション開発(with VC++ 2010 EXPRESS)で

Windows 7 64bit 版上で winpcap を使ったサービスプロセス制作

こちらのページを参考にさせてもらった。

WinPcapを使用したパケットモニター作成CodeZine 古谷誠進さん

http://codezine.jp/article/detail/126?p=2

が、1点バグ発見



・アダプタ一覧(アダプタ名およびIPアドレス)を取得する

の箇所

// デバイス情報バッファを開放する

処理は、while(d)ループの外でやらなくちゃいけない。



デバッグきつかったっす、サービスだとデバッグできないこともあって。

・俺のマシンが64bitだからwinpcap.dlllibと合わない?

(PCAPSDKのLibx64というサブフォルダがあって、こっちのものを指定しなきゃだめ?)

・WIDECHARとMULTIBYTE の扱いの問題?

と、いろいろ迂回してしまった。



"途中で停止しました"の原因を2時間くらいいろいろ調べ、

解消したら、無事動き出した。



「まずはサンプルの制作から」と、時間をかけないために記事はあとでゆっくり研究しよう...と

コードコピペで済ませてるあたしが悪いんだよ。

ちなみに、いろいろ掲載されている情報の中で、こちらのWEBページの記事が一番わかりやすかったです

2011-09-27

http://anond.hatelabo.jp/20110926232535

美容院価格帯や店名まで指定しちゃっていいんじゃね?(EARTHとかでいいよね)あと、ガチオタ女はまともなヘアケア全然しないし、下手したらヒゲ生えてるからソースは妹)、その辺のフォローも必要かと



男女問わず、「迷いはあるけどいまひとつ踏み出せない脱オタ志願者」ってのは

劣等感と結びついたコスト意識(「こんな自分なんかにそんな金かけてもどうせ無駄」的な)が非常に強いみたいなので、

安い割に効果インパクトの高いアプローチから優先的に紹介してあげるのが良いのかなと思う

女性なら個人的にはネイルバッファがすごくオススメ脱オタ段階の人に限らず)

2011-08-28

決められた納期、溢れる仕事休み無き労働、壊れゆく同僚、そのような環境が常態化した状況下に曝され続け、仕事やりがい自己成長という言葉空虚に響き、未来希望が見えず、もうダメかもしれないと思った。

バッファはある程度必要。

2011-04-27

http://anond.hatelabo.jp/20110427150707

いや、俺は城には生まれてないよ。

既得権益層に歯向かう人って、それがあたか勝手に出来上がったものだと思ってるひとが多いでしょ。

あれって様々な努力のおかげで生まれた当然の対価なんだよ。

その努力を底辺の嫉妬で打ち崩されるのが嫌だって言ってるだけ。

あ、ちなみに俺は非正規雇用の残念な人だからそんなお城はおろか庭番もさせてもらえてません。

だけどそれは相応の人間が相応の生活をしているだけだから関係ないよね。

移民たくさん入ってきて俺より優れた人がバッファの殆ど無い俺を蹴落としても当然だと思うし、俺はそれを受け入れるけど。

あいうのに歯向かう人ってなんだか「俺のがうまく立ち回れる」とか「俺が国を動かすにふさわしい」とかマジで考えてそうできもちがわるいよね。

2011-03-27

http://anond.hatelabo.jp/20110327233115

当事者にはわかるまい。

「無能から死ぬ」という役割としてバッファを買ってでてくれるなら猶予があってもいいが、世の中理不尽からな。

刃物振り回される前に死んだほうが社会のため。

2011-03-23

震災復興の最高と最悪のシナリオを考えてみた。

特に東北に知り合いはいないのだけれど、第一原発から10kmのところに金型屋さんがあって取引停止してたり

東北工場新卒内定者の半分とは連絡のつかない状態になってたりと、やりきれないのでこれから日本を考えてみた。

自分研究者でもなんでもない、ただの事務員(どちらかというとアンチ原発)なので、非正確な情報偏見もあると想いますが、そこはご容赦を。

最高-A 原子力のある場合

原子炉内に立ち入らず作業のできるロボットが実用化される。

国民原子力に関する関心がたかまり、すべての国民が納得するまで安全管理を見直した結果

システムの輸出ができるほどの原理的に安全なシステムができる。

今回の震災津波被害を教訓とした、新しい防災システムを輸出できるようになる

津波の勢いを沖合で提言する何かとか?柳に風で津波の勢いさえ受け流してしまえる住宅とか?漂流カプセルたいなのを家屋内に自然に組み込むとか?)

最高-B 原子力発電のない場合

マイクロ水力発電や、風の通りやすい建築構造により、夏の停電回避

そえぞれの業界のそれぞれの設備で蓄電や発電をすることにより通常営業に近い状態に

東京への一極集中がなくなったり、電力に頼らない快適性の確保のため、日本に住み良い街が増える

安く大量に生産することを売りにする製造業は成り立たなくなるかもしれないが、

医療技術や、高度な技術開発に人と資源を集中することができる。

技術運用面も見直され、官僚体質を一人一人があらため、

情緒コネに頼らない、論理性の高いビジネスを行えるようになる。

今回の震災津波被害を教訓とした(前段とおなじため以下略)

最低-A 原子力発電のある場合

特に現在システムを見直さず、なあなあで原子力発電再開。

その態度に外資企業不安を覚え、情報産業地場に関係ないモノは次々と日本脱出

東海・東南海南海連動地震がおき中部圏原発で大事故中部に人が住めなくなり、製造業終了。

製造業以外も倒産が相次ぐ、流通がなくなり野菜や米や生活必需品がやたら高くなる

失業したら汚染地域自給自足するしかなくなる。

最低-B 原子力発電のない場合

力不足に電力会社が何の対策も講じず、3年ほど計画停電が繰り返される。

情報産業製造業医療も成り立たず、じわじわと海外シェアを奪われていく。

海外シフトできる企業個人事業主シフトして、日本国内では失業率が高まる

仕事を失った人がアル中等になり、生活保護人口が増大、税収は減少

日本円価値がなくなる。

原子力があるにしろないにしろ、技術開発と仕事の仕方の変革が必要なんじゃないのかなと。

あと今までは、暮らしていくのに十分なだけのお金があれば良いとおもってたけど、

災害時のバッファ的に、稼げる時に稼いどくってのは必要だなあと思いました

多分そんな感じでやる気を出す人は少なからずいるとおもうので、上手いこと形になるといいなと思います。

2011-03-21

http://anond.hatelabo.jp/20110321033058

バカが騒いで作れないからつくる土地を強権で強制収用するということだろ。

いでに半径50キロくらいは バッファゾーンしか確保しとけ。

2011-01-15

オーストラリアブリスベン洪水がひどいので

地形的な原因を探るために、SRTM3で赤色立体地図作成してみました

とても不思議な地形が現れました

市街地大河が蛇行しているのですが、周りが平野はない。

市街地の上流に氾濫できるようなバッファがなかったようです

終身雇用で能なしにタダ飯食わせる損失より、

流動化で優秀な奴が利己的に振る舞う損失の方が

はるかに大きい

2・3は読んでないけど。

よくよく見たらこれが書かれたのは1984年。

アメリカがようやく「カンバン方式て何や」「カイゼンやね。これからは」とか

言い出した時代。当時日本のやり方が注目されてたんですな。

ま、アメリカの偉いところは、司馬遼太郎の言うところの「素人が扱うことを前提に組織を作る」

ところですか。

ザ・ゴールの中心理論って、

トヨタカンバン方式を別視点から捉えているものだと思った。

それぞれ異なった視点からアプローチがなされているけど、

突き詰めていくと同じところにたどり着く。

2010-12-28

これまでの社会人経験で学んだことまとめ

社会人も4年目となってもう半年が経ちました

今年は社会人として一区切り付く年となりそうなので、これまでに

仕事をしてきて思った事などをまとめたいと思います。備忘録です

書きかけなのでカテゴライズ適当です

時間を守る、時間に遅れそうな時はすぐに連絡

当たり前ですが、これがなかなか守れていない人がよくいます。

 プロジェクトが火を噴く原因のNo.1です

 客先だけでなく、社内、グループ内を含め時間は必ず守るようにしましょう。

 レビューの日にち、時間、資料の提出期限、飲み会の参加表明の記入などなど、

 周りに与えるインパクトに大小はありますが、時間を守るのは絶対です

 もし、遅れる場合は必ず連絡しましょう。遅れてからでは遅いです。

 連絡するタイミング重要です。直前の連絡は遅れた事と同じです

 ただし、遅れる事を連絡するタイミングは、早すぎるのも良くありません。

 できる努力をしていないと思われるからです。連絡のタイミングは見極める

 必要があります

期限を切る、期限を設定する

 作業を依頼する時は必ず期限を切りましょう。

 また、期限には、必ず意味を持たせる必要があります

 なぜその期限に完了する必要があるか説明できないと、人は動きません。

 また、逆に期限を設定されない作業が降ってきた場合は、期限を設定しましょう。

 そして、なぜその期限までに完了させないといけないのか聞きましょう。

体制を意識する

 作業を進める上で体制は時間並みに重要です

 自分は誰に管理されているのか、エスカレーションは誰にすればいいのか、

 必ず明確にしましょう。

 また、自分が人の上に立つ場合は、管理下の要員以外は原則動かせません。

 管理下以外の要員を動かす場合は、その人の管理者と調整する必要があります

作業の見積もりは絶対手を抜かない

 作業の基本は Plan→Do→Check→Action です

 このPが曖昧だと火を噴きます。計画は絶対に手を抜いてはいきません。

 見積もりの出し方は下の通りに進めます

 1.出来るだけ細かく作業項目を洗い出します。

  例)xx機能の詳細設計書の作成、xx機能のyy処理の試験実施

    xxツールのyyモジュール作成

 2.どのくらいの量があるか洗い出します。

  例)試験実施場合

   xx機能 -

    yy処理の項目数:100項目

    zz処理の項目数:200項目

 3.上で挙げた量がどのくらいの時間で終わるのか計算します。

  この時、上の例でyy処理、zz処理の中でも必要な時間が変わる場合は、

  重み付けをします。

  例)

   xx機能 -

    yy処理の項目数:100項目実施時間=5分×20項目+10分×80項目=900分

    zz処理の項目数:200項目=10分×150項目+15分×50項目=2250分

    合計:3150分=52.5時間=8人日(1日を7時間とする、小数点以下は切り上げ)

       ※1日7時間の根拠:1時間ログの整理や事後作業の時間とする

 また、上で作った見積もりは、PDCAのCheckでも使われます

 具体的には、結果の報告です

 見積もりと乖離があった場合の説明に用いたり、見積もり通りに進捗した場合

 振り返りに用いたりします。

 計画が終わったら見積もりは忘れ去りそうになりますが、

 必ずどこかに置いておきます

リスクを常に意識する、作業時間バッファを持つ

 作業には必ずリスクが付きます

 作業に取りかかる前に必ずリスクを洗い出します。

 リスクとしては、障害の発生、バグ検出による改修からリリースまでの作業、

 急な割り込み作業、etc...があります

 そして、そのリスクヘッジとして、見積もった時間に対し時間

 上乗せしておきます

 リスクヘッジによるバッファであることを説明すれば

 上司も納得してくれるはずです

常に客先の事を意識する

 自分した仕事は最終的に客先に出て行きます

 常に客先の事を意識する事で、成果物品質は上がります

 末端にいて、客先を意識しにくい場合は、自分がいる立場の一つ上に立って

 周りを見渡す事を意識します。

 担当者場合管理者の、管理者の場合は更に上の管理者の立場で物事を

 考えます

 例えば、報告資料のフォーマットからエクセルの文字の大きさや網掛け等の

 書式といった、細かいところまで、人に見てもらう資料は気を使わないと

 いけないところがたくさんあるはずです


。。。うん、当たり前の事書いてますね。でもなかなかやってくれないし

出来ないものです

今日はここまで。

2010-11-15

http://anond.hatelabo.jp/20101114233816

ちょwその記述はウチの実家…!

いや東京から来たらそりゃ田舎かもしらんけど、地味にあちこちに面白い店あったりするんよ!

外の人間の知らんおいしいものもいっぱいあるんよ!水が軟水だし、風が関東ほど乾燥しとらんけー、冬場の髪肌にええんよ!

というか、休みはどんくらいあるの?

土日出勤上等とかでなければ、なんか習い事いくとか趣味サークル入るとかしてみるのもええかもしれんよ。

もともとやってる趣味があればそっちでもいいし、スポーツ経験あったらムダにあちこちある体育館市民サークル的なことやってると思う。そういうのだったらたいして金もかからんし。

あとは、やってたらmixi地域コミュとかにもぐりこんで、オフ会出るとか。

会社辞める辞めないは別として、やっぱり会社の人としかしゃべらんちゅうのは精神に悪いけんね。

もし転職するとしても、会社プライベートのほかにもうひとつバッファになる場所を確保するノウハウちゅうのは絶対また役に立つことだから、適宜探してみてください。

気持ちが落ち着けるようないい友達できるように、祈ってます。

2010-10-26

Gyaoって、ホントにみんな見てるのかな??

まずはコレを見てほしい。

http://gyao.yahoo.co.jp/userreview/00603/v07421/

本日、たまたまYahoo宣伝にあったGyaoリンクをたどったときに、たまたま見つけたドラマなんだけど、とにかくユーザーレビューが酷い。

何が酷いってもう、ドラマことなんかそっちのけで、YahooGyaoのことをけっちょんけちょんにけなしているんだからヒドイw


三行で説明すると、

 1.GyaoYahoo傘下となることが決定(09年4月

 2.天下のYahooと組んだらどうなるんだ、と期待ふくらみ株急騰

 3.GyaoYahoo傘下になったとたん、画面最大化できず字幕みえない、バッファが足りず停まる、商売っ気出しすぎてうんざり(←今ココ

といった感じ。

今ココといったものの、これ2009年9月時点でのお話なんだけどね^^;




もうこんだけ酷いレビューがあがるくらいだから、合併後は惨憺たる結果を示しているのかと思いきや、以下の記事。

http://internet.watch.impress.co.jp/docs/news/20091027_324569.html


2009年9月の時点では、

Yahoo! 動画統合した「GyaO!」の利用者数がニコニコ動画を上回る」と、

さも誇らしげに語る記事が散見された。はて、これはまた異なこと。

そこでいろいろ調べているうちに以下の記事を発見

http://japan.internet.com/wmnews/20091027/3.html


先ほどと同じグラフYahooGyaoの躍進を伝えているが、こちらはもうひとつ突っ込んだ内容を入れている。

1人あたりの利用時間と利用者層だ。

Youtubeニコニコ動画が1時間半を超える長い利用時間であるのに対し、Gyaoはたったの20分しかない。…20分!?



ためしにこの利用時間を利用者数で掛け算してみよう。

ざっくりとそのサイトの総視聴時間が割り出せるはずだ。


 Gyao!→238,060

 ニコニコ動画→784,686

 Youtube→2,292,960

 (単位:千分)


なんと、国内2位だったはずのGyao様がYoutubeに10倍近い大差で負けてしまうではないか。

「勝った勝った!」とはしゃいでいたニコ動にすら3倍の大差で負けている…




総視聴時間を比べたところでさほど意味がないようにも思えるけど、

それでも平均視聴時間が20分ってちょっとおかしくはないか…??

当時、最長10分までしか投稿できなかったYoutubeが1時間半超えしているのに、

映画アニメをまるまる1本流しているGyaoが20分…??

そんなことはありえないだろう。


考えられる結論は一つではないか?

つまりGyaoを訪れるユーザーのほとんどは、たまたま(今回のボクのように)Yahooのトップに載っていた宣伝につかまってGyaoを訪問するが、

多くの人が(今回のボクのように)動画を1本も観ることなサイトを離れてしまっている…と。

上記のjapan.internet.comの記事は、暗にそのことを伝えたかったのではないか?



結局ニコ動を抜いただの国内2位だのはまやかしで、フタをあけてみると、


「超強力なPVを持つYahooさんのおかげでGyaoにも人が流れてくるようになったけど、

 商魂逞しすぎで使い勝手の悪いYahoo仕様だから誰も観てくれないよぅ!」


といったところかもしれない。



統合スタートから1年も経ってから混ぜっ返すのもアレなんだけれど、

Gyaoって、ホントにみんな見てるのかな??




(追記)

そういえば、合併の記事で利用者数がついに1000万超え!みたいな書き方があったけど、

2007年2月時点で、Gyao単体で1300万人の視聴者がいたみたいよ?

http://www.venture.nict.go.jp/ezp/index.php/venture/node_2672/node_2755/node_11414/node_11415


まぁ、「視聴者」であって「利用者」ではないので、イコールではないと思うのだけど…

ちなみに2007年2月以降のGyao視聴者推移は、ボクには見つけられなかった…

そしてニコニコ動画(β)がはじまったのが2007年2月

見つけられなかった理由は、恐らくそういうことなんだろう。


さらに、実はGyaoとほぼ同じ成長曲線を描いていたYoutube存在発見

http://www.atmarkit.co.jp/news/200703/22/youtube.html


Youtubeはこれから2年半で利用者数を倍の2千万人に増やし、

Gyaoは半数以下の5千万人に減らした、ということだろうか。

2007年2月が、Gyao人生最大のモテ期だったのかもしれない。



(追記2)

2009年4月、つまりYahooGyao統合が発表された直後に興味深い記事を発見した。

http://internet.watch.impress.co.jp/cda/news/2009/04/23/23251.html


さきほど単純計算で試算した総視聴時間が、思いのほか二アリーな数値であったことがわかる。

Gyao時代は30分はあったのね。でも30分か…アニメ1本分だなぁ。

1本が長いと連続視聴が疲れるので、結局、総視聴時間が減るということなのかな。


しかしYahoo動画の総視聴時間ヘタレ度合いが半端ないwww8分未満とか何なのwwwww



(追記3)

Gyaoがまだイケイケだった頃の記事。

http://itpro.nikkeibp.co.jp/article/COLUMN/20060418/235583/

http://itpro.nikkeibp.co.jp/article/COLUMN/20060418/235603/?ST=network


そこはかとなくだけど、バブリーな香りが漂ってきはしないだろうか…w

金のにおいを嗅ぎつけたTV崩れのハイエナどもがGyaoを食い潰した、

そんな視点もあるみたいだね。

http://www.future-planning.net/x/modules/news/article.php?storyid=3843



(追記4)

掘れば掘るほど興味深い記事がいっぱい出てきて困る。

誰か綺麗にまとめられるエライ人いないかなぁ。

http://retujyou.com/2007/08/14/usen-livedoor/


他の動画サイトの動向とかも交えて、

動画サイトの栄枯盛衰、みたいなものを観てみたいなぁ。


できればやる夫シリーズで!w

2010-08-18

http://anond.hatelabo.jp/20100817230944

地方出身同士カップル×共働き子育てしてる人とか普通に山ほどいると思うんだけど…

大変は大変だけど、なんとかなるちゃーなるんじゃない?

自分が直接知ってる範囲だと、友達が23区内在住の地方出身同士カップルで、子供3人いるけど、子どもちっさい時は近所の子育て中の人と預けあいサークル的なことをやってたよ。

詳しいことはあんまり聞いてないんで、どういうきっかけでそーいうものが出てくるのか、どこで募集してるもんなのかよく知らないけど。

事故とかトラブル起きたときはどうするんだろう…そのへんの保険とか、うまいことやりやすくなってるといいんだけど。

あと、東京でも市部なんかだと保育園バッファはそれなりにあるみたい(別の友人談)。

大規模マンションで認可保育園つきの物件なんてのもあちこちあるしねー。

2010-08-06

http://anond.hatelabo.jp/20100806000658

うーん、「老人と現役世代の比率だけ比べるプロパガンダ」よりましなんだけど

将来の労働力が増えるといっても出生率を高いまま維持するなら、将来の子供も老人も増えるので、

子供も非生産年齢人口だから、そこもカウントしなきゃ、はいいんだけど、

人口に占める労働者の比率はあまり変化しない。

もやっぱり間違い。これから始まる第2次人口転換(高齢化社会)で最大の問題になるのはピーク時にどれだけ非生産年齢人口の比率が大きくなるか、ということ。

日本だと女性就業率の低さにバッファがあるとしても、一時的に就業者比率が50%割っちゃう可能性が高い、てのが大問題。

これを緩和するには、2050年とかのピーク時に備えて、まだ余裕があったここしばらくについては出生率は上がっていた方が良かったんですよ。なんでそうなるか、というのは実際にシミュレーションしてみないことには説明は難しいんだけど、要は「出生率が低い」ことに問題があるんじゃなくて、「急速に出生率が(低い方に)変化した」ことが問題で、どうしても一時的にひどい状態になっちゃう、ということ。(急に高くなっても実は似た問題は出てくる)

まあ、この変化は既に起きてしまったので、今から出生率向上を頑張っても、今世紀中くらいは焼け石に水にしかならないんだけどね。

2010-07-24

google発のProtocol Buffersについて

オブジェクトシリアライズツールであるプロトコルバッファについて書きます。

プロトコルバッファって何って方はこちらへ

Protocol Buffers 本家

http://code.google.com/apis/protocolbuffers/

XMLはもう不要!? Googleシリアライズツール「Protocol Buffer」

http://journal.mycom.co.jp/articles/2008/07/18/protocolbuffer/index.html

Protocol Buffers (Protocol Buffers の内部解説記事。とても参考になります)

http://dodgson.org/omo/t/?date=20080712

内容

プロトコルバッファは異種言語間でオブジェクトのやりとりをするための規格です。

独自の言語によりオブジェクトインターフェースを規定することで、多言語対応を行っています。

例えばこんな感じ。

  • address.proto
package tutorial;

message Person {
  required string name = 1;
  required int32 id = 2;        // Unique ID number for this person.
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phone = 4;
}

// Our address book file is just one of these.
message AddressBook {
  repeated Person person = 1;
}

以上のようなprotoファイルから各言語ソースコード、または何らかのデータ操作ライブラリを使いオブジェクトの処理を行います。

googleによってC++, Java, Python用のライブラリ作成されましたが、他の言語対応したサードパーティー製のライブラリがいくらでもあるので、実質的にほぼすべての言語で使えると言っても過言ではありません。

以下はこのライブラリを使ってみた感想などです。

整数型はVarintという可変長型でバイナリに保存される

数字が多きければ大きいほど、長いバイト長で保存されます。ただし、負数の場合符号ビットが立つ関係で、ほとんど常に変換後のバイト数が最長バイト数(10)になってしまいます。フィールドの型をsint32, sint64で宣言しると、各数値にzig-zags変換が行われるため、負数であってもその値の絶対値で使用バイト数が決まるようになります。

保存されるデータは各メッセージID/型/値のみ

バイナリに保存されるデータは各メッセージID/型/値のみです。なので、同じ定義の二つのメッセージ型は、プロトコルバッファ上では全く同じように扱うことが出来ます。例えば、片方からシリアライズしたデータを、もう片方の型でデシリアライズすることが可能です。

またオブジェクト連続シリアライズ/デシリアライズすることもできます。

継承されたクラスマッピング

すでに存在する継承関係のあるクラスを、Protocol Buffersでシリアライズ/デシリアライズしたい場合は次のようにします。

(Base, Derived はすでに存在するとします)

(ソースコード中になぜか日本語が書けないので、コメントはすべて英語になっています)

message PbBase {
        require int32 id = 1;
        require int32 value = 2;

        require Derived derived = 10; // - Point !!!
}

message PbDerived {
        require string string_value = 1;
}

継承元のメッセージ定義に、継承先のメッセージを持たせます。Base継承するクラスシリアライズ/デシリアライズしたい場合は、PbBaseメッセージを中心に処理を行うことで、比較的簡単に処理を実装することが出来ます。

例えばこんな感じ

Base *Base_DeserializeFrom(PbBase &pbobj)
{
    // Arrange the classes which inherits from Base.
    if (pbobj.has_derived()) {
        return new Derived(pbobj);
    }
    else
    ...
}

class Base {
    ...
    virtual void Base::SerializeTo(PbBase &pbobj) {
        // Set the fields of 'pbobj',
    }
    ...
};

class Derived {
    ...
    virtual void Base::SerializeTo(PbBase &pbobj)
    {
        PbDerived *derived = pbobj.mutable_derived();

        Base::SerializeTo(pbobj);
        // Set the fields of 'derived',
        ...
    }
    ...
};

protoファイルを以下のように書くと、メッセージの扱いが非常に難しくなります。

message PbBase {
        require int32 id = 1;
        require int32 value = 2;
}

message PbDerived {
        required PbBase base = 1; // - Here is the point !!!
        require string string_value = 2;
}

2010-06-21

http://anond.hatelabo.jp/20100621110724

あ、私もだ。と思ったので思わずTB

コンピューターに例えると、CPUの処理速度は猛烈に速いが、バッファがほとんどないタイプ

以前の経験フィードバックして、答えることが苦手なので、とにかく、何回も試行を繰り返して、解にたどり着いているんじゃないか。

というのは言いえて妙ですね。

私も精神科医にかかったけど、適切なアドバイスをもらえず自力で処世術を身につけてきたので、そんな先生に出会えたことが羨ましい。

今からでもお会いしてみたいなぁ。



漢字の成り立ちを絵で見て、漢字法則インストールされたようだ。

というのが、とてもよく分かる。

社会に出る前に、ビジネス本とか読めれば沢山読んで決まり事を理解しておくと、社会人として新しい環境に入っても少し楽だと思う。

社会人スキルって言うのは、いちどインストールできたら何十年も役立つものだから。

誤解されて傷つくことも多いだろうけれど、それも試行錯誤して一通り身に付くと、生きることがとてもとても楽になる。

それが身に付くまでは周りに取り残されているような気がして辛いだろうけど、身に付いたあとは「CPU」の速さをきっと活かせるようになるよ。



CPU」が早いおかげで元々できる子のように思われるけど、決まり事を「インストール」したり試行錯誤するのにどれだけ努力してきたかってのが分かってもらえないのがいちばん辛い。

http://anond.hatelabo.jp/20100621152320

レス元増田です。

見直さない気持ちはわかる気がしますw

社会人になった今でも資料の見直しとかは凄まじく苦痛ですね。

めんどくさいんですよ。もう一度状況をバッファにロードするのが。

キャッシュメモリとかほとんど無いんで、問題を解き終わったら情報は既に揮発しています。

いちいち脳内パーサを起動して構造解釈する作業がまた発生するので、負荷が凄く高いです。

個人的に子供の頃こう教育して欲しかったなあと思うのは、「見直すのが面倒なんだったら他の解法を考えてみろ」という考え方ですね。

結論が食い違えば嫌でも見直したことになります。

国語系(つまり社会人的な見直し)には役に立たないですけどね…。



で、小学生のお子さんに対して今何をしたらいいかですが

自分経験に即して考えると、何よりまず成功体験を積ませることが必要だと思います。

周りの子供先生の大多数は馬鹿なので、「空気が読めない」という時点でそれ以外の要素がどんなに優れていても落第者のレッテルを貼ります。

これは増田で日々繰り返される頭の悪いレッテル貼り合戦を見ても明らかです。

そうすると、本当は優れた面があるにも関わらず「自分は落第者なんだ」と自己認識してしまって委縮するようになってしまいます。これは負のフィードバックです。

それを跳ね返すためには、自分のやり方で成功した体験を積むのが手っ取り早いです。

成功への道筋が見えるようになれば、「ひょっとして馬鹿なのは自分じゃなく周りなんじゃないか」と考えることができるようになります。



社会人としてどうしたらいいかについては、まず確かに、高度な空気読みスキルを要求するような職種は困難だと思います。

ところが日本におけるそういった職種(≒総合職)は、一部の優秀な人を除いて単なる「特に何も得意なことが無い人」にすぎないため、国際競争の中で淘汰される傾向にあります。

自分の得意分野を持ってそれを軸に周辺分野に触手を広げていくような専門職価値は相対的に高まっていて、お子さんのようなタイプ専門職にはむしろ適性があると思います。

従ってお子さんの得意分野を伸ばすことが重要で、またその分野が社会的需要と結びつくように必要に応じて微妙軌道修正を掛けてあげることが重要です。



結論としては

  • 成功体験を積む(自身の価値観を構築するための土台を形成する)
  • 得意分野を伸ばす(土台の上に価値観を構築する)

これが重要だと思います。

うちのような学も調査力もない知的に下流な両親(両親が嫌いなわけではありません)の下に生まれ、全てを自分発見するしかなかった俺のようなケースに比べれば、お子さんには遥かに可能性があると思います。

あくまで参考までに、頑張って下さい。

日本はどうなんだろうという回答の一例

http://d.hatena.ne.jp/michikaifu/20100619/1277013348

読み終わって、日本ではどうなんだろうと思う人もいると思ったので、ちょっと書いておく。

自分自身も、子どもがこういう問題を抱えているとわかるまでは、なんにも知らなかったので、理解の一助となれば。

うちの子は、小学校の高学年。診断としては、高機能自閉症。知能に問題はないが、学習障害と、他人の気持ちがよくわからないし、空気が読めない。

今、住んでいる地域は、割と恵まれている方だ。個別対応もしてくれるし、デイサービスグループワークなど、発達障害についてのサービスは整っている。それでも、診断が下る前までに、いろいろ面倒な経緯があった。

今思えば、小さいころから、とにかく友だちができなかった。活発で、積極的なのに、長く付き合う友だちができない。

おかしいなと思っていたんだが、本人は気にしていないし、楽しそうに過ごしているので、特別に問題視はしなかった。

小学校に入って、すぐいじめにあった。

学校先生とも相談したのが、他にも気になる点があったので、自治体が行っている教育相談相談した。

なぜなら、いじめの件に加えて、漢字が全然覚えられないからだった。

「他の子になじめない。きつい言葉を投げかけてしまうようだ。いじめると同時にいじめられていると先生は見ている。

 加えて、漢字が書けないし、覚えられない。指を使っていつまでも計算している。発達障害があるのではないか?」

というような感じで相談をしたら、

「お母さんとの関係の問題ですね」とされてしまって……私が半年ぐらいカウンセリングに通うことになっただが。

その時受けたアドバイスが、「怒り過ぎるな、もっと愛情をかけろ、犬を飼え」

……犬ですか。

犬では解決しないだろうと思って、釈然としないまま、見守っていた。

その後、小学校3年のときに、習い事先生から指摘を受けた。

「ひとりだけ、指示とまったく違う行動をとるのだが、耳が悪いのではないか」

集団行動が苦手で、大勢の中にいるとひとりだけ逆方向に向いていたり、よくしていたので、そうかもと。

それで、検査をしたら、聴覚の問題で、それだけで指示が聞こえないということはない。

そのころ、ちょうど個人面談があり、先生から、問題がいろいろ起きていることを聞いた。

突然、教室を飛び出してどこかへ行ったり、突然、怒りだしてクラス全体が凍りついたり。

「原因がわからないのですが、おうちでなにかありましたか」

と言われて、今度は考えて、自治体が行っている障害相談サービスに「発達障害の可能性」と予約を入れて、待つこと1カ月。

専門的な検査をしたら、診断は下せないが、どうやら疑いがある。

学校で起きた事件や、いじめ、それ以前の友だちができない状態も、恐らくは発達障害に由縁するのでは。

そこから、「サービスを受けるには医師の診断が必要」と言われて、医師に診てもらうまでに、1カ月半以上。

10件ぐらいかけて、やっと予約がとれた。ほとんどが予約でいっぱいで来年にならないと無理や、既存の患者で手いっぱい。

しかも、「初見では診察したくない」とそれ以前に受けた検査や資料を準備しなければならなかった。

それで、やっと診断が出た。おかしいなと思ってから、3年以上。

他の地域でも似たような状況だと思うが、親がここまで動かないと、診断は出ない状況だ。加えて、程度の軽い子については、受け皿がない。

発達障害は、千差万別で、うちの子のような、空気が読めない分、限りなくポジティブで、自分自身が問題を感じないタイプは、誤解されやすい。

勉強ができないわけではない。漢字ダメでも、授業中の発言は活発で、国語以外の教科の成績は悪くない。

クラス全体と薄く付き合っているから、表面上は友だちが多いように見える。

だから、できないことが、理解されない。空気読めないとは、思われない。

「なまけもの」「大人を見下している」「反抗的」「手におえない」と先生から言われて、確かに、言動を見れば、そう捉えられてもしょうがないと思う。

大人がいちばん嫌がるようなことに気づいて、遠慮なく指摘するし、興味を感じる点については、延々と議論を吹っ掛けてくる。

逆に、うまく関係が築けているときは、「発想がクリエイティブ」や「おもしろい」、「楽しい」という評価を受ける。

学校では、先生によって、受けた印象が違うので、先生同士も混乱をするだろうなと思う。

この手の子は、10分ぐらい話しただけではボロは出ないが、1時間話しているとイライラしてくる。それが性格なんだと割り切るぐらいの気持ちがないとやっていられないが。初対面の大人は、不思議な苛立ちを感じると思う。話の展開が、常識とズレているので、まじめに聞いていると、船酔いするような感じ。

自分価値観を揺るがされるのは、楽しい体験ではない。

担当してくれている医師が、小児精神科医で、しかも、発達障害が専門だったので、理解してもらえて助かったが。

彼の説明がおもしろかった。

コンピューターに例えると、CPUの処理速度は猛烈に速いが、バッファがほとんどないタイプ

以前の経験フィードバックして、答えることが苦手なので、とにかく、何回も試行を繰り返して、解にたどり着いているんじゃないか。

一見頭の回転は速いが、いずれ、経験値を積むことがうまい子たちに抜かされて行くだろう。

見た目、バカじゃないから、バカなことをすれば、目立つ。それを指摘されても、本人は正すことが非常に難しいんじゃないか。

「これから、さらに誤解されるし、本人も傷つくことが増えると思います」

と言われて、親ができることは、なんだろうと。現状、模索している最中だ。

つらいだろうなぁ。誰でもできるようなことができないんだ。あるところだけ。

前置きが長くなったが、学習障害のこと。

うちの子は、とにかく漢字を覚えるのが苦手だ。あと、読むのが遅いし、行をよく飛ばす。

しかも、わかる漢字と、わからない漢字がまだらにある上に、読書はそれなりにしている。

ホントに識字障害なのかなぁと。疑われても仕方ない。

で、先生からも「まじめに練習をしろ」と言われて、ノート1冊分、泣きながら、漢字を書いていた。

それでも、忘れてしまうわけで。

それが、とにかく、いろいろな方法を試している中で、ある日、白川静漢字なりたちの本を読んで、ワークをはじめた辺りから、突然、書けるようになって驚いた。

漢字の成り立ちを絵で見て、漢字法則インストールされたようだ。

まるで、プログラム更新されたみたいに、それ以降は、覚えは悪いが、書けるようにはなってきた。

ポッカリ、穴が開いたようにできないことがある。

ってのは、困ると同時に、うまくはまるメソッドが与えられると、ぐんと伸びる可能性があるんだが。

そこまで細かく指導してもらうことは望めないので、親次第になってしまう。

また、白川静の本も、うちの子には合ったが、他の漢字が苦手な学習障害の子に合うかはわからない。

だから、安易にはすすめられないんだが。

突然、ぐんと階段を一段上がったような進歩を見せるときがあるので、もう仕方ないと放置しておくのもかわいそうだし。

丁寧な対応をしてもらう以前の問題とか、サービスはいろいろ整いつつあるが、あんまり簡単には解決しない状況だと言うことを書いてみた。

同じような状況にある子と周囲の参考になれば。

2010-05-19

http://anond.hatelabo.jp/20100519081705

例えばファイルダウンロード場合メモリバッファを取って特定容量ずつ書き込みを行う。

多分512KBとか1MBとか、つまりダウンロード途中でも一時ファイルごとの容量はOSに取って書き込み完了してる訳。


エクスプローラファイル管理な訳で、

ローカルで書き込まれて書き込みが完全に完了した後に

ファイル存在すると決定してインデックス部分に書き込みを行っている。


だからエクスプローラは途中でキャンセルしても一時ファイル存在しない、

完了しないと存在ファイルシステムに通知しないから


ダウンロードブラウザの一時フォルダに途中でも存在してる。


何故そうなるかというとエクスプローラファイル整合性の問題。

書き換え途中でファイル存在を通知して確定してしまうとキャンセルを押した場合に取り消しができないから

上書きしてる時にキャンセルした時に途中まで書き換わってたら困るでしょ?


ブラウザの一時ファイルの通知はメモリの容量の問題もあるし、キャンセルした所で一時フォルダゴミが残ったとしても問題ないから。


こんな感じでおk

2010-05-17

小手指ウォッチング 一日目

小手指モスバーガーで昼食を摂っていると、男一人、女二人の大学生と思しきグループが、談笑しながら通りを歩いている。

これから彼らはアパートの一室で3Pをする。そう直感が告げた。

直感でなくても、最近高校生セックスを覚えてから大学にくるので、目的は違っても手段としてカラダを求めることはあるだろう。

不況のさなかに危機感が無いと思われるかもしれないが、あくまでも彼らは、将来を嘱望されたエリート候補である。バッファはそこらの大学生とは比べものにならないだろう。

新学期も始まってまだひと月である。

しかし、彼らの風貌はよくいるリア充そのものだ。髪を染め、適度に着こなし、適度に肌の手入れをする様はまさしく現代の若者その者であると言えよう。

所沢早稲田大学の巣である。正確に言うと所沢には日芸や他の専門学校もあるのですべてがそうだとは言わないが、その環境早稲田大学生に特化したものである。

私が昼食を摂っているモスバーガーこそ社長日大だが、周りを見わたせば西友西武鉄道西武タクシー西武球場西武グループの管轄内に有り。

銀行三井住友銀行支店を出していて、みずほ銀行出張所こそ出しているが、支店ではない。MUFJに至ってはATMである。なんという待遇の違い。

出している店の数々も早稲田生をターゲットにしている。西友に似つかわしくないスタバみずほマクドナルドボボラマーマが西友と同じ敷地内にある。

通りの向かいにミスド和民、早稲アカなど、「ポスト早稲田生ならここを使え」と言わんばかりのメンツである。

ちなみに小手指駅は始発で鉄道が出る場所でもあり、交通の便はよい。

駅前のバスターミナルには、朝早稲田大学生と見える大学生が、エンジ色で早稲田大学の装飾が施された送迎バスを目当てに、開店前のラーメン屋のごとく列をなしている。ざっと20人はいるだろう。もっとかもしれない。これは大学イメージとしてどうなのだろう、と個人的には思っているが、まあ彼らはそれで満足しているのだから、何も言うまい

そんな小手指にも、将来を期待されてか、大手企業が手をとり、「小手指タワーズ」なるものを建設することが既に決定している。先のマクドナルドの向かい、MUFJのATMの隣の建物は、タワーズの外観ショールームを常設展示しており(水曜定休)、小手指で骨を埋めようという人たちに強烈なイムパクトを与えること請け合いである。

しかし、駅前に10階以上のビルが建つと、駅がひどくしょぼく見えるだろう。おそらく、そのタワーズ完成にあわせて駅舎も建て替えるにちがいない。そうでなければ駅前のなか卯オリジン弁当がかわいそうだ。

2010-05-14

充足感

僕は、「閉塞感」というより、「充足感」を覚える。

僕がいなくても、より優れた人がそこにいる。だから僕は必要とされないのだ。

理論上、僕がいないと困るような事態はないのだ。

これは「閉塞感」なのか?

何をしても変わらないのは事実だ。しかし、何もする必要がない、という発想は持てないか。

すなわち、「ニート脂肪のようなもので、そいつらは余剰なものであり、労働者より先に僕たちが死ぬことでバッファとなっている」ということだ。

誰しもがニートになりたくはないだろう。

誰しもが自分だけは助かりたいと思うだろう。

しかし、世の中優先順位というのがあるのだ。

必要とされる人が先に死んでは問題が多い。

ならば、必要とされない、努力しても報われなかったような人から死んでいくことで、「充足感」も失せ、飢餓に襲われるだろう。

飢餓は利便を産む。

不足な環境に至れば、必ず新たな文化が生まれる。

そのためには、人口、食料、すべての資源を枯渇させ、淘汰の嵐を持ち込む必要があろう。

たとえば、ニートが死ぬことで、労働者の「次は我が身」の意識がより強く働き、生産性が上がるだろう。

そのためなら、私はこのつまらない今から脱却することに躊躇いはない。

2010-03-22

http://anond.hatelabo.jp/20100322041907

回答ありがとうございます。

そうですか。

バッファとfork()の絡みは常識の範囲内ですか。

もっと精進します。

http://anond.hatelabo.jp/20100321231705

いや、普通そんなプログラム書かないから、わからんよ。

答えを言われれば、バッファ持ったままフォークしてフラッシュするから、そうなるんだというのは、常識の範囲内だが。

答えを言われる前に、わかるかといわれれば、そんな位置でForkするほうがどうにかしてると思う。

Forkするなら、Fork用の子プロセスなり、子スレッドなり用意しておけと。メモリもったいないだろと返すのでそういう意味では非常識

- 転職ならen
- 派遣ならen
3ページ中1ページ目を表示(合計:51件)