2011年12月12日の日記

2011-12-12

スカイプ流通してるから誕生日が知りやすくなったと思う。普通って、誕生日友達に言うのってなんか気がひけるよね。ちなみに僕の誕生日は11月16日です

サプライズ

誕生日だった10年前のある日、誕生日入力した覚えがないのに、職場マックを起動したら「Happy birthday!」のメッセが出たり、日帰りで自分だけ帰るつもりだったのに、彼氏勝手宿泊をおごりでで予約されても困るよねえ。本当に困るよね。

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

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

再利用の効く、フレームワークコンポーネントみたいなコードを書いてくれというお客さんは異常に多い。

しかしだ・・・どこのフレームワークコンポーネントでも、とりあえず作る>テストしてみる>何回か作りなおすしバージョンアップを繰り返す。

というフェーズを経てIFが増えたり、減ったりすることからもわかるように、一朝一夕出来るものじゃない上に、

下手なコンポーネント化が弊害になることすらあり得る。

 

にもかかわらず、なんで、1ヶ月や2ヶ月のプロジェクトコンポーネント化ができて、すぐに再利用可能で、とかそんな夢みたいなことを言い出すんだろう。

http://anond.hatelabo.jp/20111212213847

そんなことしてもDeNAは何も得しないだろwwwwwwwww

http://anond.hatelabo.jp/20111212213847

かなり同意だけど、コレを他人に言おうものなら「説教くさい」だの「自分価値観をおしつけるな!」だのと言われそうだよね。

そういう口うるさくても相手のために意見してくれる頑固オヤジのような存在が今の日本はいないのだなあと思った。

http://anond.hatelabo.jp/20111212135355

軽度の鬱では?

  

日常の延長線の問題として解決をしようとする前に

一度大きく気分転換できるようなことをした方が

いいような気がする。

http://anond.hatelabo.jp/20111212212540

逆に、自分のことを直接痛めつけられる立場にない人にいくら嫌われようが、全く気にする必要ないとも取れる(むしろそういうことをいち早く体感できた人が勝つみたいな感じ)。

モバゲーとかグリーがまさにそうだろ。カネを巻き上げる相手以外は完全にシカトしてるんだから

携帯電話ゲームに思う

NHKDeNAグリーについて朝放送していた。

モバゲーDeNAグリー楽天である

 

グリー海外にこの金を搾り取るシステムが通用するか試すという。

いろいろ試すのはいいことだ。

 

NHKの放送では、ソーシャルという部分それから課金システム

このふたつをとりあげていた。

 

1つ目の「ソーシャル」これはNHK言葉の使いかたが間違っている。

ソーシャルゲームは何もモバゲーのような携帯電話ゲームだけではない。

MMORPGMIXIアプリだってソーシャルゲームである

 

仲間と一緒に遊ぶのが面白い、他の人と協力してボスキャラを倒す

いつでもどこでも遊べる、無料からよい

ゲームの楽しさを、こう利用者は語っていた。

 

アホだ。貴重な時間を使ってしまっていることに気づいていないのだ。

自分に必要なことよりも不必要なことに時間を使ってしまっていて

幸せになれると思っているのか。

幸せ=充実感=自分が生きていて他の人に役立っていると実感すること

 

他の人のために役立つには、何か仕事をしなければいけない。

自分が他の人のために働き、その人のために良いことをしたかお金をもらえる

仕事をするには3つ必要なことがある

 

学校でまなぶこと

他人のために働く

技術

 

技術は、人によって得意不得意があるので

世の中の人はいろんな職業につくことになる。

 

あなた仕事に就くために今何かしていますか。

早いうちに始めるのに越したことはない。

なりたい将来の自分について「紙に書きましょう」

 

携帯電話ゲームはそのための時間を奪っていることに

気づこう。

テレビネット巡回など

やる必要のないことはできるだけやめることだ。

 

遊ぶことは必要な場合もある。知的作業の後20分以上遊んだほうが

いいアイディアをひらめきやすい研究結果がでている。

うまく利用してください。

 

2つ目の「課金システム

これもクソである問題点を書こう。

パソコンオンラインゲームの時からこの問題は続いている。

 

NHKの放送では、100円で一定時間待たなくてもプレイできたり

強い武器のようなアイテムを買ったりという例を挙げていた。

まり課金システム」とは

自制心の低い人間を育ててしまっていることにほかならない。

お金を使うならもっとましなことに使いましょうよ。

欲や怒り嫉妬を発生させてお金を知識のない弱者からむしり取る。

プロ野球スポンサーの中でもかなり悪い部類に入る。

プラシーボ効果があると言われる健康食品ロゴ

日本シリーズに出てきた選手が肩に付けてたとき

おいおいと思ったが、DeNAも気をつけなければいけない。

 

プロ野球球団を助けることはとてもいいことだ。

いい社会貢献である

しか

モバゲー子供に勧めるのはおすすめできない。

知識のない大人がモバゲーを遊ぶのは

パチンコをやったりTVを見て暇を潰すようなものだ。

 

DeNAはどうしたらいいか

携帯電話ゲーム内容を変えるべきである

ゲームというのは暇つぶしや欲怒りに使えば恐ろしいツールだが

学習仕事に使えば、これほど役立つ効果のあるものはめずらしい。

例えば

家の仕事をするとポイントが貯まるとか

弟が、行政試験勉強DSでやっていたが

そういうのでもいいと思う。

ゴミ拾いや放置自転車の整理とGPSを組み合わせてもいい。

対戦ゲームで欲を煽るより、協力してお互いのプレイヤーがいいことをする

そういう流れにするべきだ。

 

以上、私が携帯電話ゲームに思ったことを書きました。

プログラマーにとってGoogle転職したらある意味ゴールなのかね。

他にいい会社ないのかなー

バカだからいろいろ取られて

バカだからいろいろ騙されて

結局、騙される奴が悪いんだと言われて

なーんだろうねー。本当に疲れちゃう。

なんだか凄い時代になったものだと思った

http://ulog.cc/a/fromdusktildawn/12153

↑の記事を読んで思ったけど、結局本気でアンチ活動をするなら、明らかに対象が不利益を被り且つ合法的な手段を選ばないと意味が無いと言えるのかも(合法的じゃない場合、最悪逮捕されるリスクがあるので)。

逆に、自分のことを直接痛めつけられる立場にない人にいくら嫌われようが、全く気にする必要ないとも取れる(むしろそういうことをいち早く体感できた人が勝つみたいな感じ)。

まあ、今の時代はその程度にムラ社会崩壊したということなんだろう(「あ?世間が許さねえ?俺にはそんなの関係ねえ」が割と通じる社会)。

自己顕示欲の赴くままアグレッシブに生きたい、ナルシストタイプリア充には願ったり叶ったりな時代というか。

人と付き合うということはその人の資源を略奪するということです

http://anond.hatelabo.jp/20111205081836

風俗に限った話ではないけど、他人と関わるということは、相手の資源(金銭、時間、労力)を奪うということなんだよ。

自分資源を略奪されることでもあるけどね。

極端な話、挨拶を返してもらうにも金を払わなければいけない社会があったっておかしくない。

他人と付き合えるかどうかということは、言ってみれば「資源の収奪戦に勝つか負けるか」なんだよ。

から、「付き合ってほしい」と言ったほうが負けなの。

相手の資源を奪いたいと言っているんだから、相手にその補填をしなければならない。

相手が自分と付き合うことによって失う機会を補償しなければならない。

「惚れた方が負け」とはそういうことだ。

人付き合いは戦争だ。

自分から誘ったらそこで負けだ。相手に誘わせるのだ。

もう勝てない、この人なら身銭を切って人生を買い取ってあげてもいい、

観念して初めて、交際を申し込むのだ。

http://anond.hatelabo.jp/20111212135355

去年まで彼女がいたのに死ぬしかないとか、もう俺はどうしたらいいんだ。

今すぐ死ねというのか。

http://anond.hatelabo.jp/20111212202104

お前の言いたいことがわからねえ。レッテル貼りに熱心なだけでは同意を得るのは難しいぞ。ど素人にもわかるように筋道を考えて書いてくれよな。

「程度にもよりますが、糖質制限食が糖尿病改善するというのは事実であろうと思います」というコメントを批判する立場というのは、i)糖質制限効果ない、あるいは、ii)極端な糖質制限が有効と考えるのどちらかだと思ってレスしたんだが、そうじゃないわけ?

その極端の程度なんだな。極端ってのはね、1日の糖質量が1gとかそういうことだよ。野菜にも糖質があるから、それじゃ野菜も食べられないことになるからね。NATROMを見ると、1日の糖質量を20gにするなんてとんでもない!とかそういうレベルじゃないのか?20gが極端じゃなくて、1日の糖質量を1gとかにするのが、「極端な糖質制限食」だからな。

極端の程度なんてNATROMのコメントにぜんぜん書いてないし。どういうことなの?糖質制限がきつすぎるってこと???

http://anond.hatelabo.jp/20111212102510

これってさあ

俺はよく知らないんだけど、

色々人として終わってるな

http://anond.hatelabo.jp/20111212194611

また、よく分からないのが口出しか

↓のことを書いたよ。

その極端の程度なんだな。極端ってのはね、1日の糖質量が1gとかそういうことだよ。野菜にも糖質があるから、それじゃ野菜も食べられないことになるからね。NATROMを見ると、1日の糖質量を20gにするなんてとんでもない!とかそういうレベルじゃないのか?20gが極端じゃなくて、1日の糖質量を1gとかにするのが、「極端な糖質制限食」だからな。

精神論ではない仕事を速くこなす技術」のfromdusktildawnさん添削Ver:メモ

作業をやるな

 仕事とは作業をやることではない。仕事とは目的を達成することだ。だから、相手から頼まれた方法が必ずしもベストなやり方ではない。相手の目的を達成することが重要だ。だから、その仕事は誰のために、何のために必要で、ゴールは何がどうなっている状態なのか、をしっかりヒアリングすることが大事。ゴールを聞いて、それを達成するための近道を常に考える事。

意思決定者を意識しよう

 ほとんどの僕らにとって、仕事とは「関係している一番偉い意思決定者が満足するものをつくること」だ。だから、誰がその仕事の成果を評価する役割を担っているかを常に追いかけて、彼のニーズ・評価基準を見つけ出そう。これをするだけで、後からひっくり返されることがなくなる。

いから捨てちまえ

 全てを完璧にしようとすれば時間なんていくらあっても足りなさすぎる。だから、その作業の中で「適当にしていいもの」「絶対に抑えて置かなければならないもの」をヒアリングをして見つけ出し、手を抜けるところは徹底的に手を抜こう。時間内に求められたアウトプットを出すことが仕事目的で、誰もが見惚れる配色のパワーポイントをつくることは僕達の仕事ではない。完璧主義なひとほど完璧から遠ざかる。捨てるべきは捨てよう。

10分の1の状態で見せること

 作業をする方向性の大枠が決まったら、その状態で見せるとムダな差し戻しが防げる。たとえば、パワーポイントを作る作業なら、アウトラインと主なメッセージが決まった時点で見せる。相手がダメ出しをする部分を先に出し尽くせば、ムダな差し戻しなく作業ができる。

遠慮無くパクれ

 組織の大抵の仕事前例があるものだ。たとえば、コンサルタントの提出する資料のかなりの部分が既存の資料の使い回しかアップデートだったりする。すでにあるものを再度創りだすことほど馬鹿な事はない。遠慮無くパクろう。とにかくパクる。で、自分よりもっとうまいやり方をしている人がいたら、躊躇せず彼の秘訣を聞き出す。とにかく、パクろう。

1分だけやる

 重いタスクほどすぐに着手するべき。なぜかというと、人間には認知的不協和というのがあって、着手したものが終わっていないと気持ち悪いと感じる心理があるからだ。着手したら終わっているべき、という認知があって、それが解決されていない状態は気持ちが悪い。だから、解決しようと集中して作業できるように心が動く。重い作業ほど、とにかく1分だけでいいので着手しよう。きっと1分は一時間になっているはずだ。

時間を区切る

 「時間をかけて頑張って解決しよう」と考えている時点で、あなたは最も効率の悪い仕事のやり方を選んでいるといえる。なぜなら、「時間で解決しよう」というのは、創造的な解決方法放棄していることだからだ。たとえば、「象を3秒以内にかけ」といわれたら、誰でも象を表現するために最適かつ短時間で終わる方法を考えだそうとする。時間による制限は人の創造性を引き出すシンプルかつ効率的方法だ。だから、「イマイチ効率が悪いやり方をしているようだな」と感じるなら、自分がどれだけ時間を区切って作業できているかをみなおそう

http://anond.hatelabo.jp/20111209095945

から本文以外の記述をきって、言葉を削った

http://anond.hatelabo.jp/20111212191013

NATROMは「極端な糖質制限はよくないよ」って言ってるだけに思えるけど。

なんか受信してない?

http://anond.hatelabo.jp/20111212192844

ていうか、どう考えてもそういう正論が通じる段階じゃないと思うんだが…。

もちろん増田情報からだけで言いきれるもんじゃないが、説得しようとしても逆切れされて終わるだけにしか見えない。

成果も出してないくせに書斎がどうとか、そういうワガママを許してきてしまった経緯があるから

調子ぶっこいちゃったボンボン息子みたいなもんで、ここから軌道修正を図るのはかなり困難に思える…。

ゲーマーなんだ元増田

http://anond.hatelabo.jp/20111212173754

じゃあ、奥さんに「ゲームノベライズ」を何本か書いてみるよう薦めてみなよ。

ゲーマー面白いと唸る原稿が書けたら、才能があると認めてやる。出来なかったら、フルタイム勤務を探すか、もっと真面目に家事に取り組むか、しろ」と言い渡してやれば?

正直、大手の長編新人賞取ったって、それっきりの人が出る世界なんだから、15年も前の短編の賞にしがみついてても、得るものは何もないと思う。

本を読むならシェークスピア全集読破して、全部の話のあらすじ書くとか。真剣努力する気があるのなら、やることはいくらでもある。

1日20枚書かないと本気とは認めない。とか、生活費握ってるのなら、どうとでも言いようがあるだろ?

がんばれ、元増田

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん