はてなキーワード: バッファとは
第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年度ドラフト会議を鑑賞する巨人ファン(http://www.youtube.com/watch?v=J4fanzhZrBo)で一躍有名となったピアキャス配信者。
糞貫とは
決め台詞
沿革
1 名前:名無しさん[] 投稿日:08/04/01(火) 18:06:59 ID:2RwJz0c7
はじめまして^^
『配信者でよかったぁーーっ!』
理由は"デブな男は嫌い"とのこと
と福貫自身は語っていたが後にm9板ニュース速報スレで福貫の嘘が暴かれる。
346 伊藤かな恵 mail:sage 08/08/22(金) 20:35:46 ID:NVBCmxj3
ゆかまとピー太のスカイプ終了後
福貫がゆかまのスカイプに凸して
福貫がピー太と話しゆかま無視で会議通話乗っ取られる
ちなみに>>342は捏造
一緒にビールかけを試みるも放映権を持っているフジが中継せず朝日の報道ステーションまで待つ事に。
待たされている間にすっかり落ち着いた福貫は報ステでビールかけが中継されると同時に
自分も頭からビールをかけるがカメラの解像度が低いためリスナーにはよくわからないという体たらく。
あっというまに朝日の中継が打ち切られ、残されたビールまみれの福貫はジョッキ一杯のビールをかけて配信を締める。
パワプロ15 栄冠ナイン 目指せ甲子園 →甲子園優勝までやり続けると宣言したが、結局うやむや
マリカー →全コースのレコード更新を掲げるが、やはり結局うやむや
22時間を過ぎたところで、サライを流して配信を止めてしまい 24時間不達成
福貫、誠意とは何かね?
本物だったら次で抜けてくれというレス通りにNOBUOは次のレースの後去っていった。
始めは偽物と叩いていたがどう考えても本物でした本当にありがとうございます。
↓偶然にもNOBUOに勝った瞬間
チーズケーキと山盛りの雑炊を一人、黙々と食す
レス「お前本当に一人なんだな.....」
二つ合わせて約216万円の大勝利配信でピアキャスドリームを作る
デモでよかったなw
この可笑しな自信家を誰も止めない点から見て、リスナーは相当の精鋭の模様
しかし今のバイト先に迷惑をかけないように徐々にシフトを減らして辞めようとするが・・・
866 名前:福貫 ★[] 投稿日:09/01/28(水) 18:36:11
休憩中に携帯で書き込んでたんだよw
帰り際に株やりたいから減らして~的な事を伝えました
そんでありがたい事に、軽くお説教してもらいました
みんなもありがとね
しかし格ゲーの敷居はズブの素人にとってあまりに高く数日後に挫折転売
結果、糞アフィブログの持ち主、頃飯だけがおいしい汁を吸った
ネットヤクザ福貫『おいリスナーどもいいか?俺のとこのアフィ踏め』
その報告と今後の相談をするためにニートから正社員になった配信中の葉月さんにスカイプで凸
有馬記念から4ヶ月で福貫の人生をここまで転落させたリスナーは相当の精鋭の模様
つまり引退
つまり復活
福貫いわく、一日一巨人と徐々に進めていくということ
腹いせに箱○をサクリファイス
打開したもの
| 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設定
| 配信対象 | |
|---|---|
| オーディオコーデック | |
| オーディオ形式 | |
| ビデオコーデック | |
| ビデオビット レート | |
| ビデオサイズ | |
| フレームレート | |
| キーフレーム | |
| 画像の品質 | |
| バッファ サイズ |
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 の扱いの問題?
と、いろいろ迂回してしまった。
解消したら、無事動き出した。
いや、俺は城には生まれてないよ。
既得権益層に歯向かう人って、それがあたかも勝手に出来上がったものだと思ってるひとが多いでしょ。
あれって様々な努力のおかげで生まれた当然の対価なんだよ。
その努力を底辺の嫉妬で打ち崩されるのが嫌だって言ってるだけ。
あ、ちなみに俺は非正規雇用の残念な人だからそんなお城はおろか庭番もさせてもらえてません。
だけどそれは相応の人間が相応の生活をしているだけだから関係ないよね。
移民たくさん入ってきて俺より優れた人がバッファの殆ど無い俺を蹴落としても当然だと思うし、俺はそれを受け入れるけど。
ああいうのに歯向かう人ってなんだか「俺のがうまく立ち回れる」とか「俺が国を動かすにふさわしい」とかマジで考えてそうできもちがわるいよね。
特に東北に知り合いはいないのだけれど、第一原発から10kmのところに金型屋さんがあって取引停止してたり
東北工場の新卒内定者の半分とは連絡のつかない状態になってたりと、やりきれないのでこれからの日本を考えてみた。
自分は研究者でもなんでもない、ただの事務員(どちらかというとアンチ原発)なので、非正確な情報や偏見もあると想いますが、そこはご容赦を。
国民の原子力に関する関心がたかまり、すべての国民が納得するまで安全管理を見直した結果、
システムの輸出ができるほどの原理的に安全なシステムができる。
今回の震災や津波被害を教訓とした、新しい防災システムを輸出できるようになる
(津波の勢いを沖合で提言する何かとか?柳に風で津波の勢いさえ受け流してしまえる住宅とか?漂流カプセルみたいなのを家屋内に自然に組み込むとか?)
マイクロ水力発電や、風の通りやすい建築構造により、夏の停電を回避
そえぞれの業界のそれぞれの設備で蓄電や発電をすることにより通常営業に近い状態に
東京への一極集中がなくなったり、電力に頼らない快適性の確保のため、日本に住み良い街が増える
安く大量に生産することを売りにする製造業は成り立たなくなるかもしれないが、
医療技術や、高度な技術開発に人と資源を集中することができる。
情緒やコネに頼らない、論理性の高いビジネスを行えるようになる。
その態度に外資企業が不安を覚え、情報産業等地場に関係ないモノは次々と日本脱出
東海・東南海・南海連動地震がおき中部圏の原発で大事故、中部に人が住めなくなり、製造業終了。
製造業以外も倒産が相次ぐ、流通がなくなり野菜や米や生活必需品がやたら高くなる
電力不足に電力会社が何の対策も講じず、3年ほど計画停電が繰り返される。
情報産業も製造業も医療も成り立たず、じわじわと海外にシェアを奪われていく。
海外にシフトできる企業や個人事業主はシフトして、日本国内では失業率が高まる
仕事を失った人がアル中等になり、生活保護人口が増大、税収は減少
原子力があるにしろないにしろ、技術開発と仕事の仕方の変革が必要なんじゃないのかなと。
あと今までは、暮らしていくのに十分なだけのお金があれば良いとおもってたけど、
今年は社会人として一区切り付く年となりそうなので、これまでに
仕事をしてきて思った事などをまとめたいと思います。備忘録です。
客先だけでなく、社内、グループ内を含め時間は必ず守るようにしましょう。
レビューの日にち、時間、資料の提出期限、飲み会の参加表明の記入などなど、
周りに与えるインパクトに大小はありますが、時間を守るのは絶対です。
もし、遅れる場合は必ず連絡しましょう。遅れてからでは遅いです。
連絡するタイミングも重要です。直前の連絡は遅れた事と同じです。
ただし、遅れる事を連絡するタイミングは、早すぎるのも良くありません。
できる努力をしていないと思われるからです。連絡のタイミングは見極める
必要があります。
作業を依頼する時は必ず期限を切りましょう。
なぜその期限に完了する必要があるか説明できないと、人は動きません。
また、逆に期限を設定されない作業が降ってきた場合は、期限を設定しましょう。
そして、なぜその期限までに完了させないといけないのか聞きましょう。
自分は誰に管理されているのか、エスカレーションは誰にすればいいのか、
必ず明確にしましょう。
また、自分が人の上に立つ場合は、管理下の要員以外は原則動かせません。
管理下以外の要員を動かす場合は、その人の管理者と調整する必要があります。
作業の基本は Plan→Do→Check→Action です。
このPが曖昧だと火を噴きます。計画は絶対に手を抜いてはいきません。
1.出来るだけ細かく作業項目を洗い出します。
例)xx機能の詳細設計書の作成、xx機能のyy処理の試験実施、
2.どのくらいの量があるか洗い出します。
xx機能 -
yy処理の項目数:100項目
この時、上の例で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でも使われます。
具体的には、結果の報告です。
見積もりと乖離があった場合の説明に用いたり、見積もり通りに進捗した場合の
振り返りに用いたりします。
リスクとしては、障害の発生、バグ検出による改修からリリースまでの作業、
上乗せしておきます。
末端にいて、客先を意識しにくい場合は、自分がいる立場の一つ上に立って
担当者の場合は管理者の、管理者の場合は更に上の管理者の立場で物事を
考えます。
例えば、報告資料のフォーマットから、エクセルの文字の大きさや網掛け等の
書式といった、細かいところまで、人に見てもらう資料は気を使わないと
いけないところがたくさんあるはずです。
。。。うん、当たり前の事書いてますね。でもなかなかやってくれないし、
★今日はここまで。
いや東京から来たらそりゃ田舎かもしらんけど、地味にあちこちに面白い店あったりするんよ!
外の人間の知らんおいしいものもいっぱいあるんよ!水が軟水だし、風が関東ほど乾燥しとらんけー、冬場の髪肌にええんよ!
というか、休みはどんくらいあるの?
土日出勤上等とかでなければ、なんか習い事いくとか趣味サークル入るとかしてみるのもええかもしれんよ。
もともとやってる趣味があればそっちでもいいし、スポーツ経験あったらムダにあちこちある体育館で市民サークル的なことやってると思う。そういうのだったらたいして金もかからんし。
あとは、やってたらmixiの地域コミュとかにもぐりこんで、オフ会出るとか。
会社辞める辞めないは別として、やっぱり会社の人としかしゃべらんちゅうのは精神に悪いけんね。
もし転職するとしても、会社&プライベートのほかにもうひとつバッファになる場所を確保するノウハウちゅうのは絶対また役に立つことだから、適宜探してみてください。
気持ちが落ち着けるようないい友達できるように、祈ってます。
まずはコレを見てほしい。
http://gyao.yahoo.co.jp/userreview/00603/v07421/
本日、たまたまYahooの宣伝にあったGyaoのリンクをたどったときに、たまたま見つけたドラマなんだけど、とにかくユーザーレビューが酷い。
何が酷いってもう、ドラマのことなんかそっちのけで、Yahoo版Gyaoのことをけっちょんけちょんにけなしているんだからヒドイw
三行で説明すると、
2.天下のYahooと組んだらどうなるんだ、と期待ふくらみ株急騰
3.GyaoがYahoo傘下になったとたん、画面最大化できず字幕みえない、バッファが足りず停まる、商売っ気出しすぎてうんざり(←今ココ
といった感じ。
今ココといったものの、これ2009年9月時点でのお話なんだけどね^^;
もうこんだけ酷いレビューがあがるくらいだから、合併後は惨憺たる結果を示しているのかと思いきや、以下の記事。
http://internet.watch.impress.co.jp/docs/news/20091027_324569.html
「Yahoo! 動画と統合した「GyaO!」の利用者数がニコニコ動画を上回る」と、
さも誇らしげに語る記事が散見された。はて、これはまた異なこと。
そこでいろいろ調べているうちに以下の記事を発見。
http://japan.internet.com/wmnews/20091027/3.html
先ほどと同じグラフでYahoo版Gyaoの躍進を伝えているが、こちらはもうひとつ突っ込んだ内容を入れている。
1人あたりの利用時間と利用者層だ。
Youtubeとニコニコ動画が1時間半を超える長い利用時間であるのに対し、Gyaoはたったの20分しかない。…20分!?
ためしにこの利用時間を利用者数で掛け算してみよう。
Gyao!→238,060
ニコニコ動画→784,686
Youtube→2,292,960
(単位:千分)
なんと、国内2位だったはずのGyao様がYoutubeに10倍近い大差で負けてしまうではないか。
「勝った勝った!」とはしゃいでいたニコ動にすら3倍の大差で負けている…
総視聴時間を比べたところでさほど意味がないようにも思えるけど、
それでも平均視聴時間が20分ってちょっとおかしくはないか…??
当時、最長10分までしか投稿できなかったYoutubeが1時間半超えしているのに、
そんなことはありえないだろう。
考えられる結論は一つではないか?
つまり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視聴者推移は、ボクには見つけられなかった…
さらに、実はGyaoとほぼ同じ成長曲線を描いていたYoutubeの存在を発見。
http://www.atmarkit.co.jp/news/200703/22/youtube.html
Youtubeはこれから2年半で利用者数を倍の2千万人に増やし、
Gyaoは半数以下の5千万人に減らした、ということだろうか。
2007年2月が、Gyao人生最大のモテ期だったのかもしれない。
(追記2)
2009年4月、つまりYahooとGyaoの統合が発表された直後に興味深い記事を発見した。
http://internet.watch.impress.co.jp/cda/news/2009/04/23/23251.html
さきほど単純計算で試算した総視聴時間が、思いのほか二アリーな数値であったことがわかる。
Gyao時代は30分はあったのね。でも30分か…アニメ1本分だなぁ。
1本が長いと連続視聴が疲れるので、結局、総視聴時間が減るということなのかな。
しかしYahoo動画の総視聴時間はヘタレ度合いが半端ないwww8分未満とか何なのwwwww
(追記3)
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/
地方出身同士カップル×共働きで子育てしてる人とか普通に山ほどいると思うんだけど…
大変は大変だけど、なんとかなるちゃーなるんじゃない?
自分が直接知ってる範囲だと、友達が23区内在住の地方出身同士カップルで、子供3人いるけど、子どもちっさい時は近所の子育て中の人と預けあいサークル的なことをやってたよ。
詳しいことはあんまり聞いてないんで、どういうきっかけでそーいうものが出てくるのか、どこで募集してるもんなのかよく知らないけど。
事故とかトラブル起きたときはどうするんだろう…そのへんの保険とか、うまいことやりやすくなってるといいんだけど。
うーん、「老人と現役世代の比率だけ比べるプロパガンダ」よりましなんだけど
将来の労働力が増えるといっても出生率を高いまま維持するなら、将来の子供も老人も増えるので、
子供も非生産年齢人口だから、そこもカウントしなきゃ、はいいんだけど、
総人口に占める労働者の比率はあまり変化しない。
もやっぱり間違い。これから始まる第2次人口転換(高齢化社会)で最大の問題になるのはピーク時にどれだけ非生産年齢人口の比率が大きくなるか、ということ。
日本だと女性就業率の低さにバッファがあるとしても、一時的に就業者比率が50%割っちゃう可能性が高い、てのが大問題。
これを緩和するには、2050年とかのピーク時に備えて、まだ余裕があったここしばらくについては出生率は上がっていた方が良かったんですよ。なんでそうなるか、というのは実際にシミュレーションしてみないことには説明は難しいんだけど、要は「出生率が低い」ことに問題があるんじゃなくて、「急速に出生率が(低い方に)変化した」ことが問題で、どうしても一時的にひどい状態になっちゃう、ということ。(急に高くなっても実は似た問題は出てくる)
まあ、この変化は既に起きてしまったので、今から出生率向上を頑張っても、今世紀中くらいは焼け石に水にしかならないんだけどね。
オブジェクトのシリアライズツールであるプロトコルバッファについて書きます。
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
プロトコルバッファは異種言語間でオブジェクトのやりとりをするための規格です。
独自の言語によりオブジェクトのインターフェースを規定することで、多言語対応を行っています。
例えばこんな感じ。
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用のライブラリが作成されましたが、他の言語に対応したサードパーティー製のライブラリがいくらでもあるので、実質的にほぼすべての言語で使えると言っても過言ではありません。
数字が多きければ大きいほど、長いバイト長で保存されます。ただし、負数の場合は符号ビットが立つ関係で、ほとんど常に変換後のバイト数が最長バイト数(10)になってしまいます。フィールドの型をsint32, sint64で宣言しると、各数値にzig-zags変換が行われるため、負数であってもその値の絶対値で使用バイト数が決まるようになります。
バイナリに保存されるデータは各メッセージのID/型/値のみです。なので、同じ定義の二つのメッセージ型は、プロトコルバッファ上では全く同じように扱うことが出来ます。例えば、片方からシリアライズしたデータを、もう片方の型でデシリアライズすることが可能です。
またオブジェクトを連続でシリアライズ/デシリアライズすることもできます。
すでに存在する継承関係のあるクラスを、Protocol Buffersでシリアライズ/デシリアライズしたい場合は次のようにします。
(ソースコード中になぜか日本語が書けないので、コメントはすべて英語になっています)
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; }
あ、私もだ。と思ったので思わずTB。
コンピューターに例えると、CPUの処理速度は猛烈に速いが、バッファがほとんどないタイプ。
以前の経験をフィードバックして、答えることが苦手なので、とにかく、何回も試行を繰り返して、解にたどり着いているんじゃないか。
というのは言いえて妙ですね。
私も精神科医にかかったけど、適切なアドバイスをもらえず自力で処世術を身につけてきたので、そんな先生に出会えたことが羨ましい。
今からでもお会いしてみたいなぁ。
というのが、とてもよく分かる。
社会に出る前に、ビジネス本とか読めれば沢山読んで決まり事を理解しておくと、社会人として新しい環境に入っても少し楽だと思う。
社会人スキルって言うのは、いちどインストールできたら何十年も役立つものだから。
誤解されて傷つくことも多いだろうけれど、それも試行錯誤して一通り身に付くと、生きることがとてもとても楽になる。
それが身に付くまでは周りに取り残されているような気がして辛いだろうけど、身に付いたあとは「CPU」の速さをきっと活かせるようになるよ。
「CPU」が早いおかげで元々できる子のように思われるけど、決まり事を「インストール」したり試行錯誤するのにどれだけ努力してきたかってのが分かってもらえないのがいちばん辛い。
見直さない気持ちはわかる気がしますw
めんどくさいんですよ。もう一度状況をバッファにロードするのが。
キャッシュメモリとかほとんど無いんで、問題を解き終わったら情報は既に揮発しています。
いちいち脳内パーサを起動して構造を解釈する作業がまた発生するので、負荷が凄く高いです。
個人的に子供の頃こう教育して欲しかったなあと思うのは、「見直すのが面倒なんだったら他の解法を考えてみろ」という考え方ですね。
結論が食い違えば嫌でも見直したことになります。
国語系(つまり社会人的な見直し)には役に立たないですけどね…。
で、小学生のお子さんに対して今何をしたらいいかですが
自分の経験に即して考えると、何よりまず成功体験を積ませることが必要だと思います。
周りの子供や先生の大多数は馬鹿なので、「空気が読めない」という時点でそれ以外の要素がどんなに優れていても落第者のレッテルを貼ります。
これは増田で日々繰り返される頭の悪いレッテル貼り合戦を見ても明らかです。
そうすると、本当は優れた面があるにも関わらず「自分は落第者なんだ」と自己認識してしまって委縮するようになってしまいます。これは負のフィードバックです。
それを跳ね返すためには、自分のやり方で成功した体験を積むのが手っ取り早いです。
成功への道筋が見えるようになれば、「ひょっとして馬鹿なのは自分じゃなく周りなんじゃないか」と考えることができるようになります。
社会人としてどうしたらいいかについては、まず確かに、高度な空気読みスキルを要求するような職種は困難だと思います。
ところが日本におけるそういった職種(≒総合職)は、一部の優秀な人を除いて単なる「特に何も得意なことが無い人」にすぎないため、国際競争の中で淘汰される傾向にあります。
自分の得意分野を持ってそれを軸に周辺分野に触手を広げていくような専門職の価値は相対的に高まっていて、お子さんのようなタイプは専門職にはむしろ適性があると思います。
従ってお子さんの得意分野を伸ばすことが重要で、またその分野が社会的需要と結びつくように必要に応じて微妙な軌道修正を掛けてあげることが重要です。
結論としては
これが重要だと思います。
うちのような学も調査力もない知的に下流な両親(両親が嫌いなわけではありません)の下に生まれ、全てを自分で発見するしかなかった俺のようなケースに比べれば、お子さんには遥かに可能性があると思います。
あくまで参考までに、頑張って下さい。
http://d.hatena.ne.jp/michikaifu/20100619/1277013348
読み終わって、日本ではどうなんだろうと思う人もいると思ったので、ちょっと書いておく。
自分自身も、子どもがこういう問題を抱えているとわかるまでは、なんにも知らなかったので、理解の一助となれば。
うちの子は、小学校の高学年。診断としては、高機能自閉症。知能に問題はないが、学習障害と、他人の気持ちがよくわからないし、空気が読めない。
今、住んでいる地域は、割と恵まれている方だ。個別対応もしてくれるし、デイサービスやグループワークなど、発達障害についてのサービスは整っている。それでも、診断が下る前までに、いろいろ面倒な経緯があった。
今思えば、小さいころから、とにかく友だちができなかった。活発で、積極的なのに、長く付き合う友だちができない。
おかしいなと思っていたんだが、本人は気にしていないし、楽しそうに過ごしているので、特別に問題視はしなかった。
学校の先生とも相談したのが、他にも気になる点があったので、自治体が行っている教育相談に相談した。
なぜなら、いじめの件に加えて、漢字が全然覚えられないからだった。
「他の子になじめない。きつい言葉を投げかけてしまうようだ。いじめると同時にいじめられていると先生は見ている。
加えて、漢字が書けないし、覚えられない。指を使っていつまでも計算している。発達障害があるのではないか?」
というような感じで相談をしたら、
「お母さんとの関係の問題ですね」とされてしまって……私が半年ぐらいカウンセリングに通うことになっただが。
その時受けたアドバイスが、「怒り過ぎるな、もっと愛情をかけろ、犬を飼え」
……犬ですか。
犬では解決しないだろうと思って、釈然としないまま、見守っていた。
「ひとりだけ、指示とまったく違う行動をとるのだが、耳が悪いのではないか」
集団行動が苦手で、大勢の中にいるとひとりだけ逆方向に向いていたり、よくしていたので、そうかもと。
それで、検査をしたら、聴覚の問題で、それだけで指示が聞こえないということはない。
そのころ、ちょうど個人面談があり、先生から、問題がいろいろ起きていることを聞いた。
突然、教室を飛び出してどこかへ行ったり、突然、怒りだしてクラス全体が凍りついたり。
「原因がわからないのですが、おうちでなにかありましたか」
と言われて、今度は考えて、自治体が行っている障害相談のサービスに「発達障害の可能性」と予約を入れて、待つこと1カ月。
専門的な検査をしたら、診断は下せないが、どうやら疑いがある。
学校で起きた事件や、いじめ、それ以前の友だちができない状態も、恐らくは発達障害に由縁するのでは。
そこから、「サービスを受けるには医師の診断が必要」と言われて、医師に診てもらうまでに、1カ月半以上。
10件ぐらいかけて、やっと予約がとれた。ほとんどが予約でいっぱいで来年にならないと無理や、既存の患者で手いっぱい。
しかも、「初見では診察したくない」とそれ以前に受けた検査や資料を準備しなければならなかった。
それで、やっと診断が出た。おかしいなと思ってから、3年以上。
他の地域でも似たような状況だと思うが、親がここまで動かないと、診断は出ない状況だ。加えて、程度の軽い子については、受け皿がない。
発達障害は、千差万別で、うちの子のような、空気が読めない分、限りなくポジティブで、自分自身が問題を感じないタイプは、誤解されやすい。
勉強ができないわけではない。漢字はダメでも、授業中の発言は活発で、国語以外の教科の成績は悪くない。
クラス全体と薄く付き合っているから、表面上は友だちが多いように見える。
だから、できないことが、理解されない。空気読めないとは、思われない。
「なまけもの」「大人を見下している」「反抗的」「手におえない」と先生から言われて、確かに、言動を見れば、そう捉えられてもしょうがないと思う。
大人がいちばん嫌がるようなことに気づいて、遠慮なく指摘するし、興味を感じる点については、延々と議論を吹っ掛けてくる。
逆に、うまく関係が築けているときは、「発想がクリエイティブ」や「おもしろい」、「楽しい」という評価を受ける。
学校では、先生によって、受けた印象が違うので、先生同士も混乱をするだろうなと思う。
この手の子は、10分ぐらい話しただけではボロは出ないが、1時間話しているとイライラしてくる。それが性格なんだと割り切るぐらいの気持ちがないとやっていられないが。初対面の大人は、不思議な苛立ちを感じると思う。話の展開が、常識とズレているので、まじめに聞いていると、船酔いするような感じ。
今担当してくれている医師が、小児精神科医で、しかも、発達障害が専門だったので、理解してもらえて助かったが。
彼の説明がおもしろかった。
コンピューターに例えると、CPUの処理速度は猛烈に速いが、バッファがほとんどないタイプ。
以前の経験をフィードバックして、答えることが苦手なので、とにかく、何回も試行を繰り返して、解にたどり着いているんじゃないか。
一見頭の回転は速いが、いずれ、経験値を積むことがうまい子たちに抜かされて行くだろう。
見た目、バカじゃないから、バカなことをすれば、目立つ。それを指摘されても、本人は正すことが非常に難しいんじゃないか。
「これから、さらに誤解されるし、本人も傷つくことが増えると思います」
と言われて、親ができることは、なんだろうと。現状、模索している最中だ。
つらいだろうなぁ。誰でもできるようなことができないんだ。あるところだけ。
前置きが長くなったが、学習障害のこと。
うちの子は、とにかく漢字を覚えるのが苦手だ。あと、読むのが遅いし、行をよく飛ばす。
しかも、わかる漢字と、わからない漢字がまだらにある上に、読書はそれなりにしている。
ホントに識字障害なのかなぁと。疑われても仕方ない。
で、先生からも「まじめに練習をしろ」と言われて、ノート1冊分、泣きながら、漢字を書いていた。
それでも、忘れてしまうわけで。
それが、とにかく、いろいろな方法を試している中で、ある日、白川静の漢字なりたちの本を読んで、ワークをはじめた辺りから、突然、書けるようになって驚いた。
漢字の成り立ちを絵で見て、漢字の法則がインストールされたようだ。
まるで、プログラムが更新されたみたいに、それ以降は、覚えは悪いが、書けるようにはなってきた。
ポッカリ、穴が開いたようにできないことがある。
ってのは、困ると同時に、うまくはまるメソッドが与えられると、ぐんと伸びる可能性があるんだが。
そこまで細かく指導してもらうことは望めないので、親次第になってしまう。
また、白川静の本も、うちの子には合ったが、他の漢字が苦手な学習障害の子に合うかはわからない。
だから、安易にはすすめられないんだが。
突然、ぐんと階段を一段上がったような進歩を見せるときがあるので、もう仕方ないと放置しておくのもかわいそうだし。
丁寧な対応をしてもらう以前の問題とか、サービスはいろいろ整いつつあるが、あんまり簡単には解決しない状況だと言うことを書いてみた。
同じような状況にある子と周囲の参考になれば。
例えばファイルのダウンロードの場合、メモリにバッファを取って特定容量ずつ書き込みを行う。
多分512KBとか1MBとか、つまりダウンロード途中でも一時ファイルごとの容量はOSに取って書き込み完了してる訳。
ローカルで書き込まれて書き込みが完全に完了した後に
ファイルが存在すると決定してインデックス部分に書き込みを行っている。
だからエクスプローラは途中でキャンセルしても一時ファイルは存在しない、
何故そうなるかというとエクスプローラはファイルの整合性の問題。
書き換え途中でファイルの存在を通知して確定してしまうとキャンセルを押した場合に取り消しができないから
上書きしてる時にキャンセルした時に途中まで書き換わってたら困るでしょ?
ブラウザの一時ファイルの通知はメモリの容量の問題もあるし、キャンセルした所で一時フォルダにゴミが残ったとしても問題ないから。
こんな感じでおk?
小手指のモスバーガーで昼食を摂っていると、男一人、女二人の大学生と思しきグループが、談笑しながら通りを歩いている。
これから彼らはアパートの一室で3Pをする。そう直感が告げた。
直感でなくても、最近の高校生はセックスを覚えてから大学にくるので、目的は違っても手段としてカラダを求めることはあるだろう。
不況のさなかに危機感が無いと思われるかもしれないが、あくまでも彼らは、将来を嘱望されたエリート候補である。バッファはそこらの大学生とは比べものにならないだろう。
新学期も始まってまだひと月である。
しかし、彼らの風貌はよくいるリア充そのものだ。髪を染め、適度に着こなし、適度に肌の手入れをする様はまさしく現代の若者その者であると言えよう。
所沢は早稲田大学の巣である。正確に言うと所沢には日芸や他の専門学校もあるのですべてがそうだとは言わないが、その環境は早稲田大学生に特化したものである。
私が昼食を摂っているモスバーガーこそ社長は日大だが、周りを見わたせば西友、西武鉄道、西武タクシー、西武球場と西武グループの管轄内に有り。
銀行も三井住友銀行が支店を出していて、みずほ銀行も出張所こそ出しているが、支店ではない。MUFJに至ってはATMである。なんという待遇の違い。
出している店の数々も早稲田生をターゲットにしている。西友に似つかわしくないスタバ。みずほとマクドナルド、ボボラマーマが西友と同じ敷地内にある。
通りの向かいにミスド、和民、早稲アカなど、「ポスト早稲田生ならここを使え」と言わんばかりのメンツである。
ちなみに小手指駅は始発で鉄道が出る場所でもあり、交通の便はよい。
駅前のバスターミナルには、朝早稲田大学生と見える大学生が、エンジ色で早稲田大学の装飾が施された送迎バスを目当てに、開店前のラーメン屋のごとく列をなしている。ざっと20人はいるだろう。もっとかもしれない。これは大学のイメージとしてどうなのだろう、と個人的には思っているが、まあ彼らはそれで満足しているのだから、何も言うまい。
そんな小手指にも、将来を期待されてか、大手企業が手をとり、「小手指タワーズ」なるものを建設することが既に決定している。先のマクドナルドの向かい、MUFJのATMの隣の建物は、タワーズの外観ショールームを常設展示しており(水曜定休)、小手指で骨を埋めようという人たちに強烈なイムパクトを与えること請け合いである。
しかし、駅前に10階以上のビルが建つと、駅がひどくしょぼく見えるだろう。おそらく、そのタワーズ完成にあわせて駅舎も建て替えるにちがいない。そうでなければ駅前のなか卯とオリジン弁当がかわいそうだ。
僕は、「閉塞感」というより、「充足感」を覚える。
僕がいなくても、より優れた人がそこにいる。だから僕は必要とされないのだ。
理論上、僕がいないと困るような事態はないのだ。
これは「閉塞感」なのか?
何をしても変わらないのは事実だ。しかし、何もする必要がない、という発想は持てないか。
すなわち、「ニートは脂肪のようなもので、そいつらは余剰なものであり、労働者より先に僕たちが死ぬことでバッファとなっている」ということだ。
誰しもがニートになりたくはないだろう。
誰しもが自分だけは助かりたいと思うだろう。
しかし、世の中優先順位というのがあるのだ。
必要とされる人が先に死んでは問題が多い。
ならば、必要とされない、努力しても報われなかったような人から死んでいくことで、「充足感」も失せ、飢餓に襲われるだろう。
飢餓は利便を産む。
そのためには、人口、食料、すべての資源を枯渇させ、淘汰の嵐を持ち込む必要があろう。
たとえば、ニートが死ぬことで、労働者の「次は我が身」の意識がより強く働き、生産性が上がるだろう。
そのためなら、私はこのつまらない今から脱却することに躊躇いはない。