「カレンダ」を含む日記 RSS

はてなキーワード: カレンダとは

2019-11-25

忙しくないけど心が忙しい

予定があると予定が気になって落ち着かない。カレンダーに書いておいてカレンダ見るとき以外は忘れるようにしたい。ゲームしてる時も予定のことがよぎるの嫌だからね。早く人生終わってくれ。いろいろ大変だから。「死にたい」じゃなくて「終わってくれ」なのは俺は苦痛が嫌なのであって自殺とか絶対きついから。安楽死でも安楽死カプセルに入るのが怖すぎるよ。人生早く終わってくれ。嫌いな授業が早く終わってくれるよう祈ってる時と同じ気分。ずっと。うおおおおおお

2019-11-01

増田カテゴリーページ

https://anond.hatelabo.jp/c

#すけろく0get1get1人アドベントカレンダ2017ブコメ2ch3.11 東日本大震災@hazuma 鬱々メモBluetooth変態オヤジ日記BookmarkDIET女FAQFXFull movieITPerlRailsRubySPAMTweetbotJPWEBコミック感想WikipediaXbox萌えキャラ辞典anchorlivecxmemotwitterzonia☆レポート来ないあとで読むいない歴年齢日記うんち日記これはひどいしりとりだいえっとババアにゃーんはてなはてなキーワードはてなサーバはてなブックマークはてな統計はてブぷろとらまとめめだか日記めも゜π゜アニメイカ娘エアオナ禁カルトググレカスゲームゲーム日記コピペコメントタイケン学園タクティスマスダタグダイエット日記ダジャレディスガイアトニオニニコ動ニッキネタハイク観察記プリキュアプログラミングマスダとマスダの冒険マスダアニメメモメンバーライフハックランニングルー増田レシピレントシーキングロジカルクッキング一人大喜利不具合九路盤囲碁今日yahoo知恵袋今日のワイの餌今日筋トレ今日聖書を読む読む今日作った言葉今日知った人物今日知った言葉今日仕事仮説休職日記似非原俺も日記書く健康投稿は甘え勝手ホトトギス千の桃太郎反証可能性名前名言国会ウォッチャー国会会議地球温暖化増田増田5五将棋増田AC2016増田BGM増田advent2017増田うどん増田お嬢サバイバル増田お嬢様部増田お嬢鯖部増田しぐさ増田なぞなぞ増田の箱舟増田ぽえ夢増田アドベント2018増田アナル普及協会増田アース増田オセロ増田マッチングサービ増田二段JUMP普及協会増田保存部増田共感増田山手線増田戦国史増田旅行記増田暇部増田知恵袋増田統計声優決めまっしょい夢日記天華の救済婚活出会った変な人字下げ増田字幕学閥専門サイト小禄ちゃん応援日記小説小説日記弊社用語辞典引用後で読む恋愛愚痴感想投資政治料理二十四節気日刊増田日本eリモデル日本語サイトはてブ日記映画感想本日の1曲朴念仁東京五輪まで権内権外水耕栽培日記海外サイトはてブ百合知力知識禁煙科学経済統一協会総合サイト艦これ英語著作権衛生改善日記計画認知節約認知資源読んだ読書議論起床直後日記返信連載増田小説過去問題集鍛練日記鍛錬日記関西オフ音楽風説否定飲み会馬渕教室高橋隆次郎鬱日記(Φ皿Φ)クワ!( ・ิω・ิ)🐈

2019-07-05

伸ばし棒を抜くんじゃねえよ

会社でのことだ。

なぜかハンマーをハンマと書くジジイがいる。なんだこのジジイ刃牙でも読んでるのかと最初記載ミスに笑った。

が、その後もずっと伸ばし棒を外していた。

馬鹿やってんだこいつとブチきれそうになった。

そしてこれだけじゃなかった。

ドライバードライバとか、

プリンタープリンタとか、

カレンダーカレンダとか、

ひたすた伸ばし棒を抜く。

だというのに

ボートボトと書かないし

ハードをハドとは書かない。

意味が分かんねえ。

こういう意味不明なことするジジイがすげーうざい。

早く会社を辞めてくれ

2018-10-26

妻の負担を減らす方法はてなまとめ

妻の家事育児などの負担を軽減するのに協力


以下に列記するけど他になんかい方法ありませんか?

 育児関係

餓鬼を一人で連れ出すようにする。シンパパみたいだけど( ^ω^)・・・餓鬼が部屋を散らかしたとき指導することを忘れないようにし。子供ポロポロしたときすぐに絶対掃除させるようにする。風呂を一緒してやる。寝かしつけ担当する。翌日の小学校の準備を監督する。

 調理関係

妻は、ヨシケイとかスーパーの総菜とか半調理済み食材とか毛嫌いするので、その辺には突破口はない。

夕食の調理に間に合うように帰宅するとか現実的じゃないし( ^ω^)・・・スロークッカーを朝仕込んでおいて夕ご飯時間帯に出来上がっているようにするとか???

朝食後の食器洗いとか( ^ω^)・・・妻は食器洗浄機反対派だからな。マシンでは解決できん。

 風呂関係

風呂掃除は手伝えるな。餓鬼ももう少し育てば委嘱できそう。常に念頭に置いておこ。冷蔵庫カレンダ風呂洗日をマークさせておこう。

 洗濯関係

部屋干しとか衣類の畳み込み、タンスへの片づけとかは手伝おう。スマホリマインドさせるように!!洗濯を始める時刻を早めることを提案したが反対された。妻は集中して視聴したい人だけど、増田は筋さえ追えればいいので、一緒にドラマ見たり酒飲んだりしてる間に(片手間で)洗濯連作業してあげてもいいなぁ。多し蟹。

除湿器タンクが満杯になってないかチェック!!!!(←これは習慣化しつつある)。

 掃除関係

ロボット購入→ 要検討。朝食後クイックルワイパー(←これは習慣化しつつある)。

2018-07-02

ブロガーカンファレンスカレンダとか無いの?

予定が近づいたら増田で警告文書いて啓発するようにしていこうぜ。

2017-11-18

anond:20171118192529

(ただの雑談というか、今日知ったロフトでの出来事というか思いつきでした。)

世の中には、原価割れに近いか形で、販売される物があるのは、知っています

例えば、漫画雑誌のように広告費や単行本の売り上げ、利益を得ているタイプビジネスモデルもあるんでしょうが

世の中の仕組みで、ピンとこないこともあります

  

今日は、たまたまロフト佳子様カレンダを見掛けたのですが、ほぼアイドルですよね。。

佳子様皇后陛下カレンダーもあるんだーと、驚いたのです。

少子高齢社会を迎える中で、宮内庁皇室を維持する予算って、どうなっていくのかと、少し不思議に思いました。

それで、増田に書いて見ました。

ググってみると、掲載写真公務のものであり、報道会社を通じて取られたものからお金は動かないのでは?みたいなコメントつけました。

売っているからと行って、直接、お金が動くとも限らないのですね。

勉強になりました。

ありがとうございます

ところで。集金ということですが。

以前、離島への民間救急ヘリチャリティーカレンダー沖縄消防士カレンダー」のニュースが頭にあったので、カレンダーは集金に利用されるシステムだという断片的な知識をなんとなく、頭の隅に合りました。

カレンダーのコーナーは、書店や文具店で誰もが足を運ぶコーナーだと、思います

集金よりも、広告話題作りとして一つとして、いいのかもしれないですね。

会社に勤めていたら無料で、業者の人が広告代わりに置いてくれたりしますね。)

2014-11-29

人月アドベントカレンダのご提案

受託開発やSIer、そこで採られる人月での見積契約スタートアップWeb系・ベンチャーな方々から軽蔑されがちです。

けれど社会インフラ企業の基幹を担うこともある重要システムでは残念ながらこれらの手法をとらざるを得ないのが現状となっています

これを打破するイノベイティブでエポックメイキングパラダイムシフトな変革は期待されていますが、文化や慣習、人手不足レガシーコードはなかなかそれを許してくれません。やり玉にされがちなSIerスタンスだけに帰せる問題ではないのです。


そんな状況でもわれわれSE社会繁栄のために、愛する(現在の/未来の)家族のために、そしてご飯を食べていくために働く必要があります

しかし、この業界で難しいのは流動性が高い割にキャリア形成が難しいこと、自分精神的・肉体的な健康を損ないやすいという問題があることで、苦労されている方も多いかと思います

そして働く人が多いにもかかわらず、会社システムプロジェクト固有の用語や知識が多いことやセキュリティポリシー抵触するか微妙なこともあってかなかなかノウハウや知見が共有されていないように感じています。一方で個々のプロジェクトに埋没している問題が共有されていないことへの懸念もあります

今回は、これを打破するためにアドベントカレンダという不思議文化に乗ってみなさまがこれまで得てきたノウハウドキュメント化していただけないかというご提案になりますノウハウの共有は日本ソフトウェア開発文化の発展に、問題の共有は社会発注企業元請け上層部含む)への啓発につながればと期待しており、なにより自分がみなさまの環境に興味を持っています

ぜひ、書いてみませんか?

トラックバックブクマを送っていただければここにリンクを貼っていきます増田でも可ですし、重複・フライングも気にしません。

また、ご質問・ご不明な点があれば可能な限り回答いたします。

期待するタイトル例(もちろん全然違ってもかまいません)

2013-09-05

うっかり防止と上司の行動プログラム

部下「うっかりしてしまったor忘れてしまった」

  ↓

上司「次からは気をつけろよ」

部下「さーせん」

  ↓

また「またうっかりしてしまったor忘れてしまった」

  ↓

らべる1:改善フェイズ

  ↓

上司メモカレンダToDoなどの改善策を指示

部下「工夫してみます

  ↓

部下「またうっかりしてしまったor忘れてしまった」

  ↓

上司仕事へのダメージが損害許容限界内か? → Yes → らべる1へ

  ↓

 No(これ以上はダメージが大きい!)

  ↓

らべる2:圧迫フェイズ

  ↓

上司「なんで忘れるの?」

部下「ぐぬぬ

上司「ねえなんで忘れるの?」

部下「ぐぬぬ

上司「ねえなんで、なんで、なんでなんで?

  ↓

上司:部下が退職たか? → No → らべる2へ

  ↓

 Yes退職処理終了)

  ↓

新規雇用フェイズ

  

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

2010-05-14

Wiiを数年ぶりに起動した。

Wiiカレンダ確認してみたら2年2ヶ月ぶりくらいの起動だった。しかもその2年2ヶ月前は8分くらいしか起動してなかった。

ファームウェアが古くて、Wiiショッピングが起動できなかったのでファームウェアを3.2Jから4.2Jに更新WiiショッピングWiiウェアとかWiiチャンネル眺めてたら凄いものを発見した!『出前チャンネル』ってなんだよw

説明読むとWiiから出前の注文ができるとかなんとか。

今の世の中はWiiから出前がとれる時代になったのか。。。なんか凄え!未来っぽい!って興奮してこの興奮を誰かに伝えたい!と思って増田に書き出したんだけどよく考えたらインターネットでも既にやってるんじゃね?て思ったのと出前の注文なんて電話で十分だよって思ってしょんぼりした。

2009-06-09

河野裕サクラダリセット』

ヒロインのもつ「リセット」の能力は、厳密には時間遡行ではない。一部の例外を除き、全てのものの状態を特定時点に復元する。6月9日リセットをかけて6月6日時点に「戻した」としても、その間に経過した3日間が消滅するわけではない。6月7日に死んでしまった人は生き返るが、これは「死ななかったこと」になるわけではなく、文字通り生き返っているわけだ。カレンダこそ6月6日に「戻って」いるが、時間軸は連続しており、6月9日6月6日の状態を持ち込んでいる。神の視点からすると、リセット後の6月9日は本来の6月6日から6日目ということになる。

さて、能力には強弱関係があるとされている。主人公のもつ「記憶」の能力リセットよりも強い。そのためリセット後もリセット前の情報を保持することができ、ものごとのやり直しが可能となっている(ヒロインの脳はリセットされてしまうため、彼女自身ではリセット活用できない)。同様に主人公の友人がもつ「任意の時間に任意の相手に声を伝える」能力リセット耐性を有する。よって彼がリセット前に発した伝言は、リセット後にも有効に伝達される。これが物語の鍵になるのだ、が。こいつが結構むずかしい。

6月7日に、6月8日に友人が特定の相手に伝える目的伝言を発したとする。その後、6月9日に主人公たちがリセットをかけて6月6日に戻った。2回目の6月7日には友人は動機を失っていたため伝言を発しなかった。それでも2回目の6月8日には彼の伝言が届く。さて作中にこんな描写があるのだが、これを前提に考えたとき、伝言リセットと言えるか。

神視点で考えてみよう。1回目の6月6日を第0日とする。伝言は第1日に発せられ第2日に到達した。第3日にリセットされた。第4日(2回目の6月7日)には伝言は発せられない。そして第5日(2回目の6月8日)に伝言がふたたび到達する。つまり第1日の原因行為に対して2回の結果が生じている。能力の効果に対して影響が出ているかいないかで言えば、伝言は明らかにリセットに影響されているのだ。

2つの考え方ができると思う。ひとつは、伝言は相対的に、「今からN日後」に対して送信されるという説。もうひとつは、伝言は絶対的な指定として「X月Y日」に対して指定して送信されるという説。相対説をとった場合、伝言リセットよりも弱いことにしなければ上の現象の説明がつかない。しかしこのとき、リセットにより原因行為が消滅した(第4日)のだから第5日に伝言が届くのは不合理となるだろう。他方、絶対説をとった場合、伝言の到達時はカレンダに対して紐づいている。リセットによりカレンダが巻き戻ったとすれば効果が再度発生するのは当然と言える。これは伝言リセットという立場と矛盾しない(リセットカレンダに干渉しているだけであって、伝言カレンダの結びつきには干渉していない)。問題は、基準となるカレンダをどこに置くかだが。案外、自室の壁時計を発動タイマにしているとか。

2009-05-11

http://anond.hatelabo.jp/20090511084854

どっちかというとラテン語読みなんじゃね。

世の中ラテン語も知らない無教養な蛮族が多すぎる。「カレンダ」のアクセントを「レ」に置いて発音すると得意げに「カ」がアクセント位置だよーなんて訂正してきやがる。「エトセトラ」なんて読み方恥ずかしすぎるからやめろ。

2007-01-16

女性心理というやつが理解できないんだけど

カレンダに入ってた食事って誰とー?』

 

こう聞いた場合、相手も詮索されてるのかな?と思ったりするのだろうか。

http://anond.hatelabo.jp/20070116221510

女という生き物は聞かれて困るようなことを人目につくところにわざわざ書くのかね?

 

俺は聞かれて困るようなことはどこにも書かない。死ぬまで言わないぞ。

詳しく言わないのは「敢えて言う理由がない」から。

そんなことが聞きたいなんて「考えもしない」から。

 

詮索が後ろめたいなら予め「興味があるから、いろいろ教えて」といっておけば?

恋人への詮索ってどこからだ。

恋人Googleカレンダを共有しているわけだが

例えば『食事』と予定を入れたとする。

私の場合、おしゃべりな生き物なので 次に彼に会うときに

『あの日ね、○○さんと食事をしてこんな話をしたんだ!』と話をする。

それが異性との食事であっても伝える。

私は普段、こんな会話・考えをしているんだ!ってのを伝えたいから。

ただ、彼の場合は話をしない。もともとあまり自分のことを話さないようだ。

カレンダに入ってた食事って誰とー?』

聞けば答えてくれるのだが、聞くほうは相手を詮索してるみたいでなんとも・・・微妙な気分。

本当は、彼がどんな話を友達(異性であれ同性であれ)としているのかが興味あるだけで。

#というのも年下(学生)と付き合うのは初めてでその世界を覗いてみたいというか・・・。

こう聞いた場合、相手も詮索されてるのかな?と思ったりするのだろうか。

こう考えて気になりだすと、そもそも予定を共有しないほうがいいんだろうな。

見えるから知りたいというスパイラルがいけない。そのうち嫉妬という余計なものまで・・・。

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