  |
はてなキーワード: モニタとは
SF映画に登場したもので多くの科学者とかエンジニアとかが憧れるものがいくつかある。それらはもう僕らの間では常識化していて“作名のアレ”で通じるほどだ。
「マイノリティーリポートのアレ」（＝空間にモニタが表示され、ボディジェスチャでフルアクセスできるUI）
挙げるとキリが無い。他にもナウシカのメーヴェとか。とにかく、実現に当たって現在解明されている科学で物理的に可能なものには憧れる人が多い。ドラえもんのどこでもドアやタケコプターは無理だ。
さて、これらについて、最近思うことがある。いや、逆だ。最近だから思うのだが。「最近のもの」じゃないんだ。この中ではマイノリティーリポートは比較的新しいが、公開は2002年、10年前だ。そしてこれらは本気で実現しようと毎日研究している人が世界中にたくさんいる。
何が言いたいか。この語り口だと「これだけ時間が経っているのにまだ実現してない、技術なんて所詮そんなもんだ！」みたいな普通な論調がありえそうなものだが、それならわざわざこんな記事を書いたりはしない。
「最近の作品にそういうものとして挙げられるものがない」んだ。
ないんだ。最近。本当にないんだ。
昔は「未来」を描いていた。が、最近は「近未来」を描くものが多い。これは言葉のアヤかもしれないが、僕らの考える「未来」が、すごく遠い未来を意識できなくなっている。中途半端に発達した文明、もしかすると「現状どう考えてもありえない事」を「未来」として描く、想像する、そういうことが出来なくなってきているのかもしれない。これは由々しき事態ではないだろうか。
クズみてーな文章書きたいけど思い浮かばない。手元にある文章ネタを公開。小町向けの多し。
先週母方の祖母が亡くなった。
小さい頃は家が近かったこともあり、祖母には頻繁に面倒見てもらってたし、
遠方に引っ越してからも盆正月は会いに行って一緒にご飯食べて話して、縁遠かったという事はない。
そして先日、そんな親しい人が亡くなった。
26歳にして初めて初めて親しい人を亡くした。
訃報については亡くなる数日前の時点で「そろそろ覚悟決めて」って親からメール来てたから、さほど驚かなかった。
訃報聞いてからすぐに飛行機で祖母宅にいって通夜、翌日に告別式やって帰ってきた。
危篤の連絡時点で覚悟を決めるために、祖母が死んだらどう思うか考えたし、
実際に対面したときから遺骨を拾うときまでの想像とのズレも確認した。
驚いたことに、一貫してそんなに悲しくなかったのである。
この考えを放置することは、社会生活を営む存在が幸福を享受することを目的とすれば、非常に「良くない」。
原因は特定して公開するべきであり、可能なら思考を変更し、最低でも自分の中で落とし所を作る必要がある。
そんなわけでこの数日間で思いつく限り可能性を出した。
自身の中で腑に落ちた原因を以下に記載する。
真っ先に思いついて胸糞が悪くなった。
ただ一件唾棄するべき原因に見えるが、そればかり考えて他の事に手がつかなくなる事はより悪い。
本能的に感情の配分を調整しておめでたい心になっている可能性は否定出来ない。
数年前から入退院を繰り返し、何度か危篤状態になっていたこともあり、
逆にこれまで持っていたことを幸運だとする考え方もできる。
ただ解釈によっては「死ぬことが予定調和になっている」「生きている人を死人扱いしている」にもなる。
世の中に積極的に関わらないこと、フィクションの摂取のしすぎが原因で、目の前の事実が
ガラス1枚隔てて見えたり、モニタの向こう側に存在している感覚に囚われることがある。
世の中に参加することが好きでないなら、自身の心と身体を安全な状態にして世の中を見れるので居心地の良い考え方である。
一方でこのスタンスで生きていると他者から観察されるとき、檻の中のサルを見る目で見られる。
葬儀の参列者も、臨時で席を相当数追加する程度に多かった。
ここまで数があると悲しむ気持ちに「働かないアリに意義がある」の理屈が通る。
人気者は放っておいても誰かが救済するため、参加する意義を見出せない。
葬式中に周りを観察していたら、良く泣く人はいわゆる「リア充」だった。
昔テレビのバラエティとかドキュメンタリーとか、なんであんな簡単に人が泣くかが理解できなかった。
理屈をもう少し若い頃に理解しておきたかった事項ではあるが、人前に出るのが好きな人間は演出家だった。
内面で生まれた感情を外に向ける際に、ごついアンプを通している。
そこまでで事態が完結すれば大したことはないが、人は悲しいから泣くのではなく、泣くから悲しくなるらしい。
模倣を通じて本物に至る概念が感情にも該当するとは思っていなかった。
1とリンクした原因でもある。
祖母の死顔を初めて見た時に、悲しい感情よりも怖い感情が強く出た。
骨あげ時に特に感情が動かなかったことから、顔の造形に対する違和感、不気味の谷が原因である可能性が高い。
また今回親しい人の初めて葬式ということで、事をうまくやろうとして調べごとしたり周りを観察することに注力していた。
意図してかせずか、別のことを思ったり考えていたために悲しまなかった可能性はある。
とりあえず6つ原因を挙げた。
この原因からどう思考を持っていくか何も考えてなかった。
とりあえずこの6つから自分自身がどんな人間か読み取ってみる。
・オタク
・根暗
・消極的
・世間慣れしていない
自分自身に対して碌な形容が出て来なかったがしかし、こんな奴は現代社会だと掃いて捨てるほどいるだろう。
ということはみんな外に出さないだけで同じ考えを持つ人間が多くいる可能性は高い。
と、ここまで結果を想定せずにダラダラと文章を綴っていたが、ゴールが見えてきた。
気にしなければいいのである。
まわりからもそう見えるし、自分の内面にそう言い聞かせて納得させることもできる。
そういう意味では葬式自体がそもそも悲しくない人間も内包するようにできている。
つまり昔からそんな人間がいるということだ。何一つ精神的不具者ではない。
結論：場に適切な感情を抱けないことは想定済み。変に心配して自己嫌悪に陥ることのほうがよっぽどバカ
学校を卒業してSEに就職した。1ヶ月と少ししか経ってないが後悔している。
恥ずかしい程本当に甘く見てた。この時代にわずか数社目で内定が出て、儲け物という気持ちで入社した。
会社での仕事は、思っていた物とは二回りも違った。いくつか挙げると
モニタ、キーボード、マウスはメーカーPCの付属品以外使えず
エディタは(ライセンス違反で)某シェアソフトを強制的に使わされている。
学生の頃や家では、良いキーボードで、Vimを使っていたのでショックだった。
業務系SEでは当たり前なのかは分からないが、コードレビューが行われてるのに
平然とローマ字読みと英語の変数名が混ざっていたのもショックだった。
やたらとExcelに触る機会が多いことは、元から知っていたがその通りとなった。
(比較的)給料は高い方で、残業が少ない点は良かった。
でも、安給料でも、若い内だけでも構わないので
はてなで自慢できるほどのスキルや、アウトプットがある訳でないが
もう少し良い環境で、良いプログラミングに挑戦したい。
元々ゲームプログラマーに興味があったが、気がついたらここは業務系SEの道だった。
ある程度、我慢したら転職できればと思っているが
そもそも新卒1年や数年で、こういった理由での転職は有りなのか。
ここを見てる人で、似たような経験をした人はいないだろうか。
何でもお話聞かせて頂けたら幸い。
虫歯があるならすぐ治そう。時間に余裕のあるときこそチャンスだ。
特に歯が痛くなくても、半年に一度は歯医者に行こう。いわゆる予防歯科というやつだ。痛くなる前なら治療も簡単で費用も安く済む。
ニートになったらほぼ一日中モニタの前に座っていることになる。そして高い確率で痔になる。
そうなる前に低反発クッションを敷いておこう。尻への負担が大幅に減る。
虫歯・痔と並ぶニート三大病のラスト、糖尿病の予防だ。食い物を制限され、毎日インシュリン注射を打たなければならなくなる前に、運動する習慣を付けよう。
とはいえ、ジョギングや筋トレなんて無理だろう。だからせめて歩こう。近所のコンビニでもいい。毎日出歩く癖を付けよう。できることなら街を徘徊しよう。体は下半身から衰えるのだ。
2chみたいな年齢不詳の匿名掲示板で、15歳のゆとりが年上キャラを「ブライトさん」とか「タマ姉」って当たり前に呼ぶ。
それに合わせて35歳の、ゆとりの倍以上生きてるオッサンが「ブライトさん」とか「タマ姉」って当たり前に呼ぶ。
15歳のゆとりが20代のグラドルをババアと呼んでるのを見て、35歳のオッサンも20代をババアと呼ぶ権利があるように感じちゃうのと同じ心理じゃねえかな。
こういう事言っちゃうの、本気なのかな？
サザエさんに登場するフグ田マスオ を作品に倣って「マスオさん」と呼んだら、「同じ世界観内存在に無意識にしろなりきってる」とか言い出しちゃうの？
うわっ、きもっ。
呼び方についても、「ブライトさん」と呼ぶのも、「タマ姉」と呼ぶのも、作中でそう呼ばれてるからってだけで、「マミさん」も同様だ。
広義な意味での現実逃避であれば、ドラマや映画、パチンコに酒、行楽だって等しく現実逃避であって、現実逃避しない奴は、世界中にほぼ存在しない。
その上で、いつも現実逃避してる奴という限定条件を批判するなら、超絶リアルなドキュメンタリードラマに傾倒して、等身大の登場人物に没入してる奴でも一緒。
大元増田は社会適応できない『オタク』に言及してると言いたいだろうが、オタクであろうがなかろうが、対象がどんなものであれ、あの定義なら社会適応できない。
横だけど、
ツッコミが入ってるのはマンガやアニメの設定の無茶ぶりじゃなくて、それに乗りっぱなしのオタクの態度の方だから。
１３歳の超天才とか１５歳の超絶運動能力とかそれに由来したり伴ったりする彼らの万能感とか挫折体験に心理的に同一化して違和感まったくない３５歳とかの話。
いや、まず視聴者に合わせて感情移入できるキャラクタを想定して、そのキャラがそれなりに不自然でなく振る舞える舞台をしつらえてると思う。
第二次大戦の特攻隊とかだと既にオチがついてるのもあって盛り上がらないし新しい要素詰め込みづらいから架空の宇宙戦争になってるだけ。
呼び方についても、「ブライトさん」と呼ぶのも、「タマ姉」と呼ぶのも、作中でそう呼ばれてるからってだけで、「マミさん」も同様だ。
作中の呼称がモニタのこっち側に延長されているというのが既に現実逃避でなくてなんであろーか。
http://engineer-memo.com/blogs/engineer-memo/archive/2010/02/21/20100221_5F00_01.aspx
プロセスごとにパケットが仕分けされてる点が、Wireshark より使いやすそうだ。
反面、MSさんのことなので
他社独自はおろか、自分のとこの流儀に反するものはRFC公認パケットであろうと標準で表示されない。mDNSとか。
けど、自分で定義を記述すれば対応するみたいだ。つまり開発アプリ独自のパケットもParseさせられる。
あと、パケットの種類で色分けされない点では、Wireshark より使いづらいのかな？
まあ、両方使えばいいか。
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4865
http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=c3a54822-f858-494a-9d74-b811e29179e7
・LocalDB って機能が気になる。開発者用に切り離されたDB の機能のようだが、便利なものなのか？
・動的ポート割り当てがデフォになってるから、支障あるときは構成マネージャで1433などを静的指定しなくちゃならない。
・静的ポート運用のときには、ファイアウォールを1433/TCPだけじゃなくて1434/UDPも開けないとならない。
って、えらそうに書いたけど、
外部からパケットは1433も1434もちゃんと届いていることはパケットモニタで確認できるが
SQL Browser ってのを起動したら、つながった！
外部から名前付きインスタンスへつなげるときは、どうやらこれが必須みたいだ。
http://engineer-memo.com/blogs/engineer-memo/archive/2010/02/21/20100221_5F00_01.aspx
高専在学中, OB, OGの人達が高専に入ったきっかけとか、どういう系統のことが好きなのとか詳しく知りたいからできれば高専関係の方はブログに書いてほしいなーとかチラッと思った #kosen_opportunity
なんていうのがTLに流れて来てたので暇つぶしに高専入学の志望動機を思い出してみた。
なお、当時書いたであろう入学志望動機は現存してないのでやっぱり記憶を。
中2当時はご多分にも漏れず
人と違う何かをしたいとかそんなことを思ってたようで
中3で
old macを安く買ってPLLの定数変更してクロックアップに勤しんでみたり
そんな中学生でした。
ってのが育英に通うきっかけでした。
ちなみに志望学科は
航空が電子工学科→航空
にしたような。機械とかあんまし興味なかったですしね
第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 練習問題
会社のお仕事で、突然に展示会係になってしまった人用のメモであります。
主催者側からあらかじめ、小間のレンタルや看板の作成の案内がくる。明確なプランがあるのならば、自前で用意するのも手である。自前で工夫すると目立つ。その一点が最大のメリットである。
すでにあるのであれば、壁にたくさん貼る。細かい商品説明を書いてもなかなか読んでもらえないので、キャッチーなものがよい。浸透していないブランド名ならば、サービスの内容を大きく書いたほうがよい。
実演できる商品であれば、論より証拠、目の前で見せるのがよい。
忙しい来場者に瞬間で展示物のよさを知ってもらいつつ、来場者の出張報告の助けになるようにチラシはつくるべきである。チラシを作るときには、このチラシをもらって、出張報告書や稟議書がかけるのかどうかを基準としてみるとよい。
24インチのモニタにパソコンで作った動画を流せばOK。このあたりはスキルによって、簡単かもしれないし、難しいかもしれない。
自社の新製品よりも、誰がもらってもうれしいであろうすでに世の中で喜ばれているもので普段使いできるもので安価なものを配るのがよろしい。
すなわち、ボールペンやメモ用紙のようなものに新製品の名入れをして配ると、ターゲットとなる人が展示会会場を出て、家や会社まで持ち帰ってくれるという目的を達せられるはずだ。
持って帰れるものならば、サンプルの無料配布でもよい。もらってうれしいかを判断基準にすることは重要だ。
疲れている人もいるかもしれないので、缶ジュースや缶コーヒーのようなものを喜ばれる。
新入社員の女の子でもいいし、若い男性社員でもよい。兎に角、清潔感があって、話しかけやすい人を最前線に配置する。詳しい話を聞きたい人が現れたら、詳しい人が説明をすればよい。お金があれば、コンパニオンを雇うのだろう。
いすに座ったまま、黙っていたのでは人は集まらない。何か目新しいものはないかと、さまよっている人の注意をこちらに向けるには、声を出すのがよい。いすに座ったままでは横柄なので、目立つ場所に立って、この小間で何をしているのかを声に出してアピールする。そのときの声は、少しあざといアニメ声であったり、露天商のように通る声であったりすると雑踏の中でも注意を引ける。
くじ引きをしてもらうことで、話すきっかけを作る。あたりはずれで、ノベルティを分けてもいい。
集まった人の中から見込み客となる人を選別する。
アンケートを書いてもらい、名刺を集める。アンケートは選択式の簡単なものにする。答えに困るような質問は入れない。
当たり前のことかもしれないが、後日の連絡先をチラシに明記する。共同出店の場合は、特に詳しい人が小間にいないことが多いので、注意。
後日、集まった情報をもとにコンタクトを取ってみる。電話をしたり、パンフレットをもう一度送ったり、実際にアポイントをとって、商談につなげる。
近頃、ゲームを全くしなくなった事をよく実感する。学生の頃にはまっていたMMORPGをはじめとするネットゲームは勿論、Xbox360やPS3にも滅多にゲームディスクを挿入することなく、もっぱらDVDやブルーレイの鑑賞機器として稼働している。PSPやDSに至っては一年以上電源を入れていない。
と言っても、ゲーム自体が嫌いになったわけではない。今でもレースゲームやRPGにはわりと興味があるし、最近読み始めたライトノベルの影響か、ネットゲームに対する興味もやや増してきた。多分、これから先もゲームから完全に意識が遠ざかる事は難しいだろう。また、ネット上ではよく「体力が続かなくなった」という声を聞くけども、それも何か違う。確かに昔の様に丸一日をテレビやモニタの前で過ごせるほどの体力は無いとしても、半日くらいなら問題なく向かえるはずだ。
要するに、モチベーションの問題なのだと思う。ゲームなんてただのお遊び。そういう考えが板に付いてしまった。こんな事を言うと「仮想と現実の区別がついてない」という類いの批判を受けるかもしれないが、それに乗っかって言うなら、ゲームというものは仮想をもう一つの現実として扱うからこそ楽しかったんじゃないだろうか。少なくとも、子供の頃はそうだったと思う。勝った負けたに真剣に一喜一憂し、難題が持ち上がると全力で解こうとしていた。今の様に「暇だな。ゲームでもしようかな」ではなく、学校から帰るやいなや、ランドセルをほっぽり出して友人の家に駆けつけてはコントローラーを取り合っていた。
あの頃の俺にとってゲームは特別な存在だった。当時を思い出す度にその一端は感じられるだろう。しかし、今はもう違うらしい。では「今の自分にとって特別なもの」とは何なのか。ゲームに限らず、同じ様な事を感じた時は特にこの点を思い出して欲しいと思う。
例えば２Ｄ格闘ゲームなどは、今後かつてのようなものは生まれないと思っている。
スプライト全盛期の頃とくらべて、今のハードウェアは遅延がデカイ。液晶ＴＶも遅延がデカイ。目で見て入力して間に合わないというのはゲームとして致命的だ。
