「カレンダ」を含む日記

■[増田アドヴェント2023] 増田 カレンダリオ デ アッヴィエント 2023

Permalink | 記事への反応(2) | 20:18

ツイートシェア

■[増田アドヴェント2023] 増田アドベントカレンダー、10年のあゆみ

Permalink | 記事への反応(1) | 19:49

ツイートシェア

■[増田アドヴェント2023] 1人アドベントカレンダ

2015年に開催の1人アドベントカレンダ

Permalink | 記事への反応(2) | 20:03

ツイートシェア

■

ネムミアドベンドカレンダァ

Permalink | 記事への反応(1) | 16:45

ツイートシェア

■[増田アドヴェント2022] 増田 カレンダリオ デ アッヴィエント 2022

Permalink | 記事への反応(2) | 06:20

ツイートシェア

■[増田アドヴェント2021] 増田 カレンダリオ デ アッヴィエント 2021

Permalink | 記事への反応(2) | 01:03

ツイートシェア

■[増田アドヴェント2021] Calendario de Advientoってどう読むの？

↑がアドベントカレンダーのスペイン語訳らしい。

どう片仮名表記するのが適当？

「スペイン語はローマ字読みでほぼOK」とどっかで聞いたことある。

すると「カレンダリオ デ アドヴィエント」で良いのかな？

発音を聞いてみる。

Calendario de adviento 語 スペイン語 でどう発音するか | HowToPronounce.com

https://ja.howtopronounce.com/spanish/calendario-de-adviento

「カレンダリオ デ アヴィエント」みたいに「d」の音がほぼ聞こえない。

d: ダ行音 /d/。

発声の始め～と語末～以外の位置では摩擦音化し、[ð]

スペイン語 - Wikipedia

https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%9A%E3%82%A4%E3%83%B3%E8%AA%9E

摩擦音て言われても殆ど聞こえない。

adviento - Diccionario Español-Portugués WordReference.com

https://www.wordreference.com/espt/adviento

別ソースの音声聞いても強いて片仮名表記するなら「アッヴィエント」みたいな感じ。

スペイン語に詳しい増田、これで合ってる？

Permalink | 記事への反応(1) | 01:08

ツイートシェア

■年収26万ペソのリアルを教えよう

年収26万ペソのリアルを教えよう

そこの「海外では～」って言ってる君！海外に行けば贅沢で優雅な暮らしをしていると勘違いしていないか？

今日はそんな誤ったイメージを正し、実際にどれくらいの生活レベルか教えよう。

まず自分のスペック。

39歳男、フィリピン人妻、セブ在住、年収26万ペソほど。26万円と26万ペソではだいぶ変わるのでこれは誤差じゃない。

なおマウンティングなどと言われるかもしれないが、そんなつもりは全く無く、

ただただリアルを伝えるために書いた記事である。

家賃について

家賃は3千ペソ、壁が板だけで出来てて街灯を明かりとする部屋を完備した東屋と呼んだ方が正確であろう一軒家。トタン屋根で扇風機がカラカラと音を立てて回るフィリピンでは普通の部屋。

ガチの平均的な現地人が住むような家で何も盛ってないけど、5万ペソくらい出せば日本人でも住める家を借りられる。

基本的に洗濯機は高級品だから手洗い。

まわりの治安は１０年前の台東区の日本〇を１０倍くらい面倒な人を増やした雰囲気。

夜は歩く方が頭おかしいと言われるレベル。

日本のDQNなんて小指でひねりつぶせるくらいのガチ勢がたくさんいるけど仲間になると何でもしてくれる頼りになる存在。

自宅の水は濾過した工業用排水みたいなもの。

飲み水はサリサリストアとかの１ペソで買う水が大正義。

普段の食事について

カレンダリア（現地の食堂みたいなもん）のご飯。

１食４０ペソくらい。

ジョリビー（マクドナルドが唯一勝てないファーストフードチェーン）なんて高級品。

コロンとか行けば食材は安く買えるけど安全に帰ってこれるかの死活問題の方が大きい。

チャタイムのタピオカミルクティーが７０ペソくらいだからカレンダリアは正義。

コンビニ・スーパーでの買い物

近所にセブンイレブンがあるけど基本的に何も買えない。

基本的に洗剤１回分とかのパックをサリサリストアで買い物する程度。

ファッション

ウカイウカイ、要するに古着屋で買う。

１着１０ペソくらいで買える。

シャツと短パンと草履で一年過ごせるという意味では日本に住むよりメリットがある。

女性関係について

不倫しようものならサンゴ礁の餌にされる。

あと基本的に離婚という制度がない。

車について

は？じ、ジープニーって便利な乗り物があるから、く、kるまなんていらないんだからっ///

なおアテネオ大学に行くような学生は下手したら日本よりも金持ちで、父親用の車、母親用の車、子ども送迎用の車、家政婦用の車などがあったりする。

これぞ本場の格差社会さ！！

というわけであまりに普通すぎて、やま無しオチ無しになってしまった。

良くも悪くも、26万ペソは日本人の生活水準を捨てれば十分に生活できる。

ちなみにフィリピン人がメインのオンライン英会話あるでしょ？俺の給料はそのフィリピン人講師たちと同じと考えていい。

オンライン英会話は学校というよりコールセンター扱いにしてるから、まあそのあれなんだけど、基本的に韓国資本の会社が多い。

表向きは日本の会社だけど講師は韓国企業から派遣されてるとかね。

オンライン英会話の月謝は安いけど、その分フィリピン人の給料も低い。

講師の態度に文句を言ってやるな、彼ら彼女らも辛うじて生きるだけの給料しかもらってない上に翌日にシフトを変えられたりするからね。

日本や韓国、あるいは中国の生徒から搾り取って講師を安月給（平均月給だけど）で働かせる会社に文句を言ってやってくれ。

CMがバンバン打てるってそういうことだよ。

「コロンとかに行けば、もっと貧しい人がたくさんいる、わかってない」と言われそうだが、海外に住むのが必ずしも日本での生活より良くなるとは限らないことを伝えたかった。

ちなみにインターネットなんて高級品なので、携帯電話にロード（プリペイド携帯みたいなのがフィリピンではメジャー）して、たまに日本語のホームページとか見てる。

たとえば毎日1GB分のYouTubeとかが見れて、2GBのインターネット接続（俺のうんこみたいに遅い）、テキストメッセージとか電話が７日間もできちゃうプランが１９９ペソする。

日本のインターネットってすげえよ。

結論

「海外は～」なんて言ってる奴の声に耳を貸すな。

あいつらが見てるのは都合のいい海外だけだ。

言っておくが俺は今の生活は嫌いでも惨めだとも思ったことはない。

Permalink | 記事への反応(3) | 12:51

ツイートシェア

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

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

Permalink | 記事への反応(0) | 23:53

ツイートシェア

■増田のカテゴリーページ

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曲朴念仁侍東京五輪まで権内権外水耕栽培日記海外サイトはてブ数百合知力知識禁煙科学経済統一協会総合サイト艦これ英語著作権衛生改善日記計画認知的節約認知資源読んだ読書議論起床直後日記返信連載増田小説過去問題集鍛練日記鍛錬日記関西オフ音楽風説否定飲み会馬渕教室高橋隆次郎鬱日記（Φ皿Φ）クワ！（　･ิω･ิ）🐈

Permalink | 記事への反応(0) | 16:27

ツイートシェア

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

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

Permalink | 記事への反応(0) | 14:42

ツイートシェア

■anond:20171118192529

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

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

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

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

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

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

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

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

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

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

勉強になりました。

ありがとうございます！

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

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

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

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

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

Permalink | 記事への反応(1) | 21:38

ツイートシェア

■http://anond.hatelabo.jp/20160614000710

Twitterとかフェイスブックのシェアするみたいな感じでカレンダに登録するみたいなのがあってもいいと思った

Permalink | 記事への反応(0) | 01:31

ツイートシェア

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

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

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

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

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

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

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

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

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

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

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

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

• 保守案件における契約形態の問題とその対策
• 出稼ぎSE入門
• オフショア開発契約時の為替の話
• 決めてくれないお客様の傾向と対策
• 実践プロジェクトマネージャーコントロール
• 単価算出概論
• 生産性向上のための人月計算
• 半年に一回しか会わない上司に成果をアピールする方法
• ぼくはこうやって単価をあげた
• 遡及契約の対策と実際
• デスマーチ・サバイバルマニュアル
• デスマから逃れるための権謀術数
• このプロジェクトのここがへんだよ
• アジャイル開発の契約で考えるべき3つのこと
• 某メガバンクＭの更改が想像以上にすごかった
• 内製案件での人員確保とその後
• たまには昔つかったベンダーのこと、思い出してあげてください
• 退屈な保守案件でもできるシステム改善・スキルアップ
• 顧客が本当に必要だったもの
• 受託開発でもお客様と近づく方法
• 下請けソフトハウスでの人材育成

Permalink | 記事への反応(1) | 11:27

ツイートシェア

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

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

　　↓

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

部下「さーせん」

　　↓

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

　　↓

らべる１：改善フェイズ

　　↓

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

部下「工夫してみます」

　　↓

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

　　↓

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

　　↓

　No（これ以上はダメージが大きい！）

　　↓

らべる２：圧迫フェイズ

　　↓

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

部下「ぐぬぬ」

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

部下「ぐぬぬ」

上司「ねえなんで、なんで、なんでなんで？」

　　↓

上司：部下が退職したか？　→　No　→　らべる２へ

　　↓

　Yes（退職処理終了）

　　↓

新規雇用フェイズへ

Permalink | 記事への反応(4) | 14:44

ツイートシェア

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

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

Permalink | 記事への反応(1) | 23:23

ツイートシェア

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

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

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

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

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

Permalink | 記事への反応(1) | 23:52

ツイートシェア

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

ヒロインのもつ「リセット」の能力は、厳密には時間遡行ではない。一部の例外を除き、全てのものの状態を特定時点に復元する。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日に伝言が届くのは不合理となるだろう。他方、絶対説をとった場合、伝言の到達時はカレンダに対して紐づいている。リセットによりカレンダが巻き戻ったとすれば効果が再度発生するのは当然と言える。これは伝言＞リセットという立場と矛盾しない（リセットはカレンダに干渉しているだけであって、伝言とカレンダの結びつきには干渉していない）。問題は、基準となるカレンダをどこに置くかだが。案外、自室の壁時計を発動タイマにしているとか。

Permalink | 記事への反応(0) | 11:26

ツイートシェア

■http://anond.hatelabo.jp/20090511084854

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

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

Permalink | 記事への反応(1) | 09:48

ツイートシェア

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

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

　

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

http://anond.hatelabo.jp/20070116221510

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

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

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

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

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

Permalink | 記事への反応(1) | 23:16

ツイートシェア

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Permalink | 記事への反応(2) | 22:15

ツイートシェア