 
|
はてなキーワード: パズルとは
ここでの一本道というのは、EDがひとつしかないという意味ではないことに留意。
中学高校と英語赤点だった。もう本当に簡単な文でもわからないレベル。英文法はパズルにしか思えなかった。
MtG をやって、少し英文を覚えた。ネットで調べ物してたらなんとなく何を書いてるか見当つけられるくらいにはなった。MtG でわかった事は、必要性に追われ、情報が経験と結びつけばアホでも覚えるということだった。小学生がポケモンを覚えるようなものだ。
そのあと、ネトゲで外人とチャットしてたらまた少し英語が(チャットで)通じるようになった。この通じるってのは、正しい英文を書けるって意味じゃない。ネトゲでは、その場で共有している話の流れや時間や場所やそういったコンテキストがある。これが学校で暗記としてやった英語とは大きな違いだった。でも、よく考えたら僕らが使っている言葉というのは、共有されたコンテキスト下に無い方が珍しい。FPS や MMORPG でわかった事は、共有されたコンテキスト下でやりとりする分には、正しさよりも返せるかどうかの方が重要だし、文としてあまり正しくない言葉でも、しゃべる必要がある時に何もしゃべらないよりは役をなすということだった。
通じるということのありがたみ、楽しさを知れたのが大きかった。学校時代は、英語が通じるかどうかは 0 or 1 で、間違ってるくらいなら話さない方がいいと思っていた。言葉は間違わないためにあるのではなく、少しでも通じるためにあるのだと当たり前のことに始めて気づいた。この 0 が 0.1 になる経験はとてつもなく大きかった。
そのあと、Flickr 等のコミュニティで沢山の人から英語でコメントをもらうようになった。自分の作品について言われてるわけだから当然理解したいし、僕の作品についてのそれぞれの人からの感想というコンテキストがはっきりしていて、ここでも必要に追われることと、共有されたコンテキストという条件にうまく当てはまっていた。
どう思ったか何を感じたかという文章が沢山書き込まれ、知らない表現も多く必死に調べながら読んだ。不思議と、感情のこもった言葉は記憶に残りやすかった。難しい言い回しでも、その意味がわかった時、「僕にこんなことを言っていてくれてたんだ！」と思うと、それが頭に残る。当然逆に「ばかやろう！こんちくしょう！んなことわかってんだよ！」でも頭に残るのだけど。
こうした作品に対するやりとりで学んだのは言葉の方向性のようなものだ。気持ちの方向性というか意思の方向性というのかな。言葉の一つ一つには今の自分の気持ちはこっち向きでこのくらい、とかこのくらい離れてる気持ちとか、このくらい近づきたい気持ち、という何かベースになるものがあると思う。日本語に翻訳してしまうと沢山の関係ない意味があるように思いがちだけど、それは表面的なもので･･･うまく言えないな。新しい言葉を覚える時に日本語訳を覚えるんじゃなくて、その気持ちの向きと強さを感じるようにするというのかな。気持ちのある言葉を投げかけられると、それが結びついて記憶に残るから、引き出しが増えるのかもしれない。
そうすると、自分の言いたい事を英語にするときも、日本語にしてからその通りに英語にするんじゃなくて、自分の中にある気持ちの向きと強さを直接英語にできる時があってびっくりする。多分これは英語力とはあまり関係ないと思う。語彙がなくても、そういう感覚がわかれば、そういう風になってくる気がする。
(追記: 僕がそう強く思い始めたのは、Flickr や deviantArt でコメントをもらうようになってからだ。おそらく、写真や絵といった言葉ではないものについて言葉をもらうことで、その作品が与えた事――これは日本語でも英語でもないもっと原始的なもの――につながる言葉という視点を得られたのだと思う。当然、小説でも一般の会話でも言葉は他者の内面で理解されてそれぞれに意味を発するので、本質的には絵や写真となんら変わらない。ただ、言葉を使ったコミュニケーションがあまりにも一般化されていることが、言葉も表現でしかないことを人に忘れさせ、自分の思う通りに伝わって当然の魔法のようなものだと慢心させてしまうのだと思う。)
僕は学校英語教育を否定したいわけじゃない。正しい英語を学ぶ事は必要だし。僕が言いたいのはそういうことではなくて。
学生時代の時は英語が使い物になるには "正しい英語を覚える→英語でやりとりできるようになる→英語で考えられるようになる" という順序をふまないといけなくて、前の段階がうまくいってなければ、到底次の段階にいくわけがないと思い込んでいた。
でも実際はそうではなくて、その三つは全て平行してるんじゃないかなって。学生時代に、英語の必要性に追われたり、もしくはすごく英語が役にたったり、ちょっとでも伝わって 0 が 0.1 になる経験や英語で気持ちが直接伝わってくる経験をしていれば、英語に対する印象も取り組み方も、当然正しい英語を学ぶことについてのやる気も、違ったんじゃないかなって。
そうしたものは、学校ではカバーできないから、あなたの努力と向上心がたりなかっただけですよ、勉強の出来る人はみな当然それもやってるのですよ、と言われると反論できないのだけど。僕が中学生だった時には、FPS や MMORPG はまだ一部の人の遊びだったし、スカイプなんてなかった。今ならもっと敷居は低いのかな、とは思う。
Webシステムとは縁遠い事務職のリーマンが、ある日思い立って、ニッチな用途の検索エンジンサービスを作ってみたので、ちょっと書いてみようと思います。
ちなみに、検索エンジンといっても、googleカスタム検索とかのお茶濁し系じゃなくて、apache Solrというオープンソース検索エンジンを、VPS上で動かしているという、それなりに本
気度の高いものです。
なんで素人がそんな物騒なものを動かす羽目になったかは、後述。
やりたい構想みたいなことを思いついたのは、もう6、7年前ほど前のこと。初めて独り暮らしを始めたときに、ひどく不便を感じたことがあり、こんなサービスがあったら便利だなあ、
ちなみにその妄想をふと高校の同期に話したとき、そのサービスはどこにあるのか？！と、えらくがっつかれたのを、覚えてます。まあ、俺と同じく偏執狂の奴だったからだと思います
が。
ただ、しがない事務職リーマンということもあり、当然、技術も無く、そのときは、やるならこんな名前のサービス名だろうなあ、とか、そんな妄想レベルで、話は終わっていました。
そんな感じで、5年ほど月日は経ち、なんとなくリーマン人生の流れも見えてきたところで、以前、妄想していたことを、ふと思い出しました。
5年も経ったら、さすがに自分が考えたようなこと、誰かがやっているだろうと調べてみたところ、意外なことに、競合になるようなサービスは存在せず。ちょうど異動があって、少し時
間が出来たこともあり、じゃあ、着手してみようかと思い立ちました。
やりたいことは、大手サイトの情報検索。ただ、商品ページ内の特定情報、それも、商品ごとに正規化されていない表記を、正規化して抽出する必要があったので、大手サイトの既設API
だけではとても実現不可能でした。
まあ、だからこそ、5年間、誰もやろうとしなかったんでしょうが。
ということで、とても一発では解決できなさそうな内容だったので、自分でなんとか実現できそうな機能に細分化して、各個撃破していくことにしました。
随分と考えた結果、
以上に区分できると考えて、これらを各個撃破していくこととしました。
また、技術もなく、プログラミングも出来ず、ましてやlinuxサーバのお守りをしたことなんて当然ないので、インターネット上に置くサーバですべての処理を完結させるのではなく、イ
ンターネット上に置くリソースは最小限に留め、できる限り、勝手がわかる自宅のwindowsパソコンで処理を行うことにしました。
ちなみにさらっと結論だけ書いてますが、ここまで至るまでに、いろいろと調べ続たり、考え込んだりしていたので、思い立ってから3ヵ月は掛かってます。。。
さて、やる方針を決めたあと、はじめに着手したのは、要の検索エンジンサーバです。
いろいろとググって調べて、mySQLというやつか、apache Solrというやつかに絞りましたが、結局、Solrを使うことにしました。
MySQLのほうが実績は多そうだったのですが、Solrのほうが検索専門で、滅茶苦茶動作が速いらしいということ、MySQLでも出来るが特に速度が遅いらしい全文検索機能も使いたかったこ
と、あとファセット機能がジャンル絞りこみに便利に使えそうだったので、というのが理由です。
ちょうどSolr本が発売されていたこともあり、それを参考に、自分が使うように設定ファイルを変更していきました。
しかし、初めは設定ファイルの内容も意味不明な上に、私の書き方も雑なのか、少しいじっただけでまったく動かなくなる。結局、設定ファイルを一文字ずつ変更しては動作検証、とい
った始末で、進捗は地を這うよう。ある程度思い通りにSolrを扱えるようになるまで、3ヵ月以上掛かったでしょうか。。。
さらに、検索エンジンのフロントエンド（Solrの検索結果を、htmlに変換するプログラム）も書かなければならない。プログラミングが出来ない人間には、これが本当に辛かった。
Solr本に、いろんなプログラミング言語でサンプルがあったのですが、迷った末に、わずか数行なら書いた（≒コピペした）経験があるという理由で、javascriptを苦渋の選択。
しかし、選択はしてみたが、基礎が本当に無いから内容がサッパリ頭に入ってこない。こちらも、わかるところから本当に1文字ずつ変えていくといった手探り状態。
プログラミングについては、今回のためだけだから、といった理由で、一切基礎をやらずに着手したのが裏目に出たのか、サンプルのソースをモノにして、書き上げるのに、ゆうに半年
以上。本当に時間が掛かりました。
さらに、Solr周りで計9ヶ月間ハマっていた頃、忘れもしない、kanzen21のおっさんが彗星のように現れて、衝撃を受けることになります。
大手サイトのページをクロールして検索エンジンを作る手法は、私と考えていた構想の枠組みとまさに「完全に一致」な訳で。。。
図書館事件に注目していたのも同じで、あまりの一致具合に衝撃を受けっぱなしでした。
その後の成り行き等も含めて、興味深く観察させて頂き、本当に参考になりました。
そんな感じで紆余曲折もありましたが、ようやく難題だった、プログラミング関連に目処が立ってきたので、あとはクローラと肝心のデータ処理です。ここからは、勝手知ったるwindows
まず、クローラですが、専用のクローラをwindows用に探してきたり、それを設定するのも大変なので、今回はテレホーダイ時代に使っていたような、フリーのweb巡回ソフトを利用する
こととしました。指定のhtmlをダウンロードしてくるだけなので、別に変に新しいものに手を出す必要もないので。
また、ダウンロードしてきたhtmlファイルについては、これまたフリーの日本語処理ツールでcsv方式に加工することにして、処理ルール部分を相当に作り込みました。
このあたりは、全体を通して見てもキモの部分なんですが、ある意味、ちょっとしたパズル感覚だったので、プログラミング言語の部分と違って、かなり楽しかったです。
あとは、msdosのバッチファイル（これは前から知っていた）で、これらの処理を繋ぎ、cygwinのcurlとかいうツールで、連続して検索エンジンサーバにcsvファイルをアップロードする
仕組みを作りました。
検索エンジンサーバには、容量は少ないが、安くて高性能という、今回の用途にピッタリだった、さくらのVPSを借りて設定。CentOSのサーバ構築ホームページを見ながら、サーバとか
Solr管理URLとかにセキュリティを掛けて、こちらも素人ながら、意外とすんなり設定。
ホームページは、vpsサーバに相乗りさせるのではなく、別にさくらのレンタルサーバを借りました。apacheの設定方法等を習得する必要がありませんし、vpsのリソースをapacheと分け
合う必要が無くなるので。ホームページのhtmlファイル、cssファイル等も調べながら設定し、画像も準備しました。
あと、構想を思いついたときに妄想していたサービス名の.comドメインは、すでに他者に取得されていたのですが、どうも使っている風にも見えなかったので、whoisで出てきたメールア
ドレスに連絡して交渉し、幾ばくか払って買い取りました。
結局、足かけ18か月。ようやく完成。
楽天市場の家具を、幅x奥行x高さ(家具サイズ)で検索できる、楽天市場・家具カテゴリ専門の検索エンジン
この商品数規模（データ収録約30万アイテム）で、1センチ単位で家具のサイズ指定検索が可能な手段は、商用サービスも含めて、ほかには存在しないと思います。
kanzen21と違って、エロじゃないから華はないけどね。。。
ちなみに冒頭で少し書いたきっかけですが、就職して独り暮らしを開始したときに、新しい家にピッタリサイズの家具が欲しかったのですが、これが楽天で探すのは至難の技でして。
楽天で家具を探してみようと思った人には判っていただけると思うのですが、楽天では、価格では範囲指定やソートができても、サイズでは検索出来ないんです。
これは、楽天では、商品のサイズ情報は商品の自由記述欄に記載することになっているためで、商品ごとにサイズの記載方法がバラバラのため、検索が事実上、不能となっています。
家電製品とかに関しては、種類が少ないこともあり、メーカーのホームページとかでサイズを確認した上で、商品型番で検索すればいいので、それほど問題にはならないのですが、家具
って、種類が非常に多く、型番もあったり無かったりで、家電のようにサイズを調べることができません。
・・・ということで、カグサイズでは、楽天の商品ページにいろいろな書式で書かれているサイズ情報を拾って解析して正規化し、範囲指定やソートして検索ができるようにしています
。
また、単に寸法サイズを拾うだけでは、梱包サイズとか引き出し内寸とかも引っ掛かってしまうので、それらは出来るだけ排除して、商品の外寸が優先して引っ掛かるよう、アルゴリズ
ムを調整しています。
単位（センチとミリ）に関しても、商品ごとにバラバラ（単に単位だけでなく、商品説明のどこに"センチ"とか"ミリ"と記載しているかについてもバラバラです。）なので、サイズ表記
の前後の状況をみて、正しいと思われる単位で拾うようにしています。
あと、変わった使い方としては、欲しい家具の価格比較みたいなこともできます。
家具は、同じ商品でも、店ごとに型番が違ったりすることがよくあり、簡単には価格の比較が行いづらいジャンルの商品です。
しかし、型番は違っても、同じ商品なら原則、サイズは同じですから、欲しい商品とまったく同じサイズで検索をかけると、同等商品があるのかどうか比較しやすい・・・といった使い
方もできます。
と、そんな感じで、しがない事務職リーマンが作ってみた、ニッチな用途の検索webサービスを、サービスインさせて頂きました。
一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値を創造できるんじゃないかという実験です。
もしよろしければ、ぜひ、使ってみてくださいー。それでは！
----------
第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 練習問題
あのアニメの一番すごいところは、データ放送を活用できているところだと思う。
パズルモード（強制的にデータ放送画面に移行してパズルを見せるところ）がRPGで言う全体マップ表示窓みたいな感じで分かりやすい。
アニメという時間軸が強引に進んでいくメディアでも、時間軸に影響されずに重要な情報をデータ放送で提供してもらえるのがいい。
その情報が不必要でストーリーだけ追いたいと思う人はdボタンで引っ込めればいいわけだし。
（知らないだけでそういう番組がもうあったりするのかな？）
でも、作中の問題がリアルタイムで解けるのはいいけど、ボタン操作がしづらくて困るんだよなー。
（反応がもっさり、間違った時に訂正できない）
女も「レディ」みたいな扱いに憧れるような前時代的な了見は捨てていくべきだ。
レディは封建時代の可哀想な幼稚な（幼稚で居ることしか許されなかった）女だ。
「愛され」とか馬鹿なこといつまで言ってるんだ。
レディが幼稚さしか選択肢がなかった可哀想な女性だったのかどうかはさておき、
脱愛され系目指す流れはホント欲しい。
なんかこう、被保護対象ポジの価値が過剰に高すぎてついていけない。
と思う反面、
男女どうこうとかあんま関係ない部分で、いわゆる「おごられ上手」的なスキル磨いておかないと今後は死ぬかもしれない気がする。
個人的におごられんの苦手なんだよね。自分で自分のケツも拭けないみたいじゃん。
でも人生いろいろあるわけだし、「気分良くおごらせてくれる相手」が必要な日だってあるじゃん。
いい大学のリア充とかそこらへんすごい洗練されてるんだよね。「おごられつつ媚びずしかしフォローも完璧」的で何かこう最強。
「自分は相手を必要としつつ、相手からも必要とされてる」的なあの感覚を人にもたらすのがすごく上手い。
そういうの見てるとケツ拭きとか単なる意地じゃね？ そんな安いプライド捨てれば？ みたいな気分になりながら、
いや安かろうと高かろうとそれがオノレなりの自己評価であり価値観であって
いわば組み上がった立体パズルのピースみたいなもんだからそんなあっさり捨てるべきじゃねーよ、と我にかえったりして面倒くさい。
当たり前ですがこれこじらせると自然と人と関わらなくなって社会的植物人間になります。どっかの殺人鬼の理想みてー。
まあ、目が覚めて良かったね、というか。まだ若いんだから大丈夫大丈夫。
そのポール・グレアムは何て言ってる?
「すごいことを成し遂げた人を見て、自分とは人種が違うと思うかもしれない。…こう考えるのは、おっかないことだ。彼らがぼくらと同じなんだとしたら、彼らはすごいことを成し遂げるためにものすごい努力をしたってことになる。そう思うのはこわいから、ぼくらは天才というものを信じたがるんだ。ぼくらが怠けている言い訳ができるからね。」
成功は一種類だけじゃないし、そこに至るルートも色々だ。一種類の人間だけが作る世界は息苦しい。世の中ってのは、パズルみたいにいろんな人間がいるから成り立ってるんだろ。他人のうまくいった人生と比較して何になるよ。やりたいことをとことんやるだけでいいんだよ。よそ見してる暇があったらさ。20過ぎになってから目覚めたあんたにしかできない何かが、もしかするとあるかもしれない。今日から始めればね。
(それでも成功するのは運次第だけど。少なくとも、人生の終わりに後悔することは少ないんじゃないかな。)
Shut the fuck up and write some code, or just do whatever you love.
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
例えば、
考えられるけど（というか、当時からその程度のことは考えていたけど）、
教師の言ってたのはどれでもなかったんだと思う。
というか、逆にどれでもあったんだろ。
数学ってすごいとか、神聖だとかいう話の補強でしかなかったように思う。
僕は自分のタイプに応じてどれかを選ぶなり優先順位を決めるなりして、手段を選択すべきだと考えてたけど。
暗記に関しては神聖性が犯されるから、言葉の響きが嫌だったんだと思うよ。
でも、のちに彼が言ってることは暗記となんら変わらないよね。
みんな理解がどうとか丸暗記がどうとか言うけど不可分だしね。
チャンクがどうこうみたいな話。
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブを受けた感想の多くは、初音ミク現象や初音ミクの海外進出などについて触れるのが主眼であり、ライブ自体への言及は意外と少ない。その中でも以下のエントリーはライブそのものに焦点を当て、その演出や音楽、聴衆の反応を報告している。既に日本からの参加者による様々なリポートが出ているが、外国人が見たミクノポリスを外国人向けにどう紹介しているかを知るという意味でも興味深いものである。
urlは以下の通り。
http://blog.animeinstrumentality.net/2011/07/anime-expo-2011-detox-and-brief-thoughts/
アニメ・エキスポ2011に関する私の第一報で言及したように、今年のミクノポリス・コンサートほど私を大混乱に陥れたイベントはなかった。ミクノポリス・コンサートは私の通常の経験領域を遥かに超えたものであり、そこから出てきた私の脳裏には回答よりも疑問の方がたくさんあった。まず、歌声合成を売り物にした演出の構想そのものが既に危険に満ちている。たとえ選曲が拙くなかったとしても、技術的な問題によってコンサート自体が台無しになるか、あるいは馬鹿げた振り付けによって、どんなボーカロイドのコンサートも決して完全にはなり得ないのではないか？
こうした質問に回答するうえで最も適切な人間とはいえない私は、おそらく聴衆の反応という意見に従った方がいいのだろう。私が見た限り、聴衆は完全に夢中になっていた。全体の意見はおそらく熱狂的な「イエス！」だろう。私が最初にいた見晴らしのいい張り出し席からは、聴衆が心から公演に参加し、そうすることによって彼ら自身の刻印をボーカロイド現象全体に刻み付けているのを見ることができた。コンサートの間、彼らはケミカルライトを爆発的なロックの時は熱狂的に、もっと優雅な曲の時はゆるやかに、あるいはミクや彼女の仲間たちが登場した時にはリズムなど気にもかけず興奮して動かしていた。
で、私は？ どういうわけか私はヴァーチャル・ディーヴァという観念を完全に受け入れるための心理的ハードルを突破できなかった。他の多くのコンサートが有しているある種の感情一体化と同じものがミクノポリス・コンサートになかったのが問題の一部にある。と言うのはつまり、私が思うにこのコンサートに人々が参加し楽しんだ理由は一つだけではないのだ。
そこにいた人々はテクノロジーを目撃したのか？ ミクと仲間たちが投影スクリーンを通じて生命を得るのを見るのは、一種のどえらい光学的な楽しみとして間違いなく極めてスリリングだった。聴衆に一息つくほんの僅かな余裕しか残さずに一つの曲から次へと素早く遷移したのは、目もくらむような効果をもたらした。ボーカロイド・キャラは、時に特定のキャラに対応した色の光の塊から実体化することで、興奮を高めた。例えばピンク色の光が巡音ルカのステージ登場の先触れとなったように。キャラの髪の毛や衣服が、彼らがステージで踊るたびにどれほど見事に揺れていたかに言及することなしに、技術面での議論を終えることはできない。中でも衣服は、懇願するような「炉心融解」の際にリンが身に着けていた黒と白のドレスや、「moon」でのミクの優雅な服装を含め、極めて魅力的だった。彼女らの服と髪はどれもキャラの動きと一緒に跳ね、揺らぎ、羽ばたき、その見栄え全てをまるで生きているかのように仕立てていた。もしテクノロジーの展示が目的なら、ミクノポリスは確かにこれらの高い期待に答えることで成功したと言えるだろう。
人々は単にミクと仲間たちを見に来たのか？ それはおそらく最も説明力に乏しい説だろう。ミク自身は、その上にファンたちが彼らの（Kylaranが書いたヴァーチャル・ディーヴァから引用するなら）「歌や動画という形式の小さな物語を書き込み、それが回りまわって単なるキャラを超えた生命を彼女にもたらす」ための一片の白紙に過ぎない。ミクと友人たちが、いかに彼らの人格の多くをクラウドソーシングと数百ものその解釈から効果的に得ているかを見れば、何人かのファンは単に彼らの最も好きなボーカロイド・キャラに属するある特定の性質を見せる特定の歌を聴くために参加していることも充分にあり得るだろう。
だが私にとっては、焦点はもっぱら音楽にあった。つまり私がミクノポリスで主に注目したのは、たまたま情報伝達手段としてボーカロイドを使った作曲家たちのショーケースとしての音楽祭という側面だった。そしてこれまた、いかに多数の調べるべき曲があったことか！ ミクノポリス・コンサートは23の楽曲［ママ］を含んでおり（文末にセットリストあり）、例えば古典的なryo（supercell）の歌「ワールドイズマイン」から、不明瞭な英語で歌われたwowakaの「ワールズエンド・ダンスホール」のような最近の曲まであった。ボーカロイドが人間を上回っている切れ味という点から、例えば「裏表ラバーズ」やcosMo（暴走P）の「初音ミクの消失」といった、どちらの歌も呼び物となっているミクが歌詞を速射砲のように歌う部分があり、どの人間にとっても明瞭に発音するには速すぎるため単なる人間には歌うことができないような曲の演奏を見るのも、一層興味深い。
しかしボーカロイドがステージ中央に陣取り注目を集めている一方、ミクと仲間たちを囲む人的要素の方が遥かに興味深いことに私は気づいた。コンサートの前に聴衆はダンスロイドによる型通りの演目を見たのだが、ボーカロイド現象が単にボーカロイド曲に合わせて踊るのが好きなだけのファングループを発生させたという事実に私は魅了された。彼女らが音楽に同期して動くやり方は、リズムとメロディーの視覚的側面をもたらし、歌を単なる聴覚上のものにとどまらずより多くのレベル全体にかかわるものとして表現している点で、実に楽しかった。彼女たちがコンサートの残り時間においてステージ近くにいなかったのは残念だった。人間のダンサーとミクが並んで演じる場面を見たかったのに。
ステージ上にいた人間の演奏家たちもまた素晴らしかった。ミクはエレキギター、ベース、パーカッション、キーボード、及び弦楽器の奏者たちを紹介するために時間を割いた。特にエレキギターはソロ演奏を通じてかなり目立っており、コンサートのボーカル部分からは失われていた名人芸の要素をもたらしていた。彼のリフは「StargazeR」の間奏において活力を高めるハイオクとなり、彼が見せるテクに私はずっと夢中になった。だが何より私が印象を受けたのは弦楽器とキーボードの編入だった。特に彼らが締めの「ハジメテノオト」で表現した驚くほど崇高なメロディーは、ボーカロイドの過去を作り上げてきた感情をもたらしながら、一方でその希望と楽観に満ちたやさしい音によって未来への道案内も務めていた。
そもそもこれほど多くのファンをノキア・シアターに連れてくるのに、唯一の尊大な理由があったとは思えない。テクノロジーの融合、キャラ/人格、そして丸見えになった音楽、さらにはその全ての体験が極めて刺激的だった。ボーカロイド技術はまだ音楽業界を支配するには程遠いし、そして現時点でのその化身は、まだ音楽の心臓部に横たわっている本物の人間ならではのある種感情的表現に取って代わる能力を持たない。これら全てを踏まえると、ボーカロイドはこれまでも、そして今のところなお、単に物珍しい存在にとどまっている。だが私は変化の地鳴りを感じている。予め歌声を調整された歌手の蔓延は、我々がヴァーチャル・アイドル界に後数歩まで迫っていることを意味しているのだろう。変化の風が人間の歌手を完全に吹き払ってしまうのか、誰にも分からないが、現時点で私はまだ人間の歌手が負ける方に賭ける準備はできていない。少なくとも今のところは。
1. Project Diva desu
2. ワールドイズマイン
3. えれくとりっく・えんじぇぅ
4. 恋スルVOC@LOID
6. ぽっぴっぽー
8. 裏表ラバーズ
9. パズル
11. 1/6
13. 初音ミクの消失
14. 右肩の蝶
15. 炉心融解
16. Just Be Friends
17. ワールズエンド・ダンスホール
18. from Y to Y
19. サイハテ
21. SPiCa
22. 愛言葉
24. ハジメテノオト
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人感想その２「再生の約束」フリーダム訳
http://anond.hatelabo.jp/20110708223459
初音ミクLAライブ、外国人感想その３「ミクノポリスのボカレタリアートたちよ、団結せよ！」
http://anond.hatelabo.jp/20110709211718
初音ミクLAライブ、外国人感想その４「仮想の歌姫：初音ミクの人気と未来の音色」
http://anond.hatelabo.jp/20110710234300
初音ミクLAライブ、外国人感想その５「オレはAXには行ってないけど、まあとにかく……」
http://anond.hatelabo.jp/20110711212701
初音ミクLAライブ、外国人感想その６「ミクノポリス：７月のクリスマスと世界征服」
http://anond.hatelabo.jp/20110712205546
初音ミクLAライブ、外国人感想その７「AX11：ミクノポリスの印象」
http://anond.hatelabo.jp/20110713211501
初音ミクLAライブ、外国人感想その９「アニメ・エキスポ：初音ミク」
http://anond.hatelabo.jp/20110715222900
初音ミクLAライブ、外国人感想その10「アニメ・エキスポ2011（抄訳）」
http://anond.hatelabo.jp/20110716194029
初音ミクLAライブ、外国人感想その11「世界は彼女のもの：初音ミクはいかにして全てを変えたのか」
http://anond.hatelabo.jp/20110717201147
初音ミクLAライブ、外国人感想その12「アニメ・エキスポ2011でのボーカロイド体験」
http://anond.hatelabo.jp/20110719031316
初音ミクLAライブ、外国人感想その13「ミク：日本のヴァーチャル・アイドルとメディア・プラットフォーム」
CDとは関係のない話だが、コンシューマゲーム市場では、ひとつのハードウェアがその使命を終えようとするとき、こぞって美少女ゲームだったり乙女ゲームがリリースされたそうだ。それと構造が似てたりする？ のかもしれないぜ。
コンシューマゲーム市場全体でそういった事態は確認されていない。
最後に美少女ゲームばかりになるのは、そのマシンのハードウェアが
「静止画の表示能力とメディアの容量がそこそこだが、派手な動きを演出する能力が時代遅れになった」
状態で終焉を迎えた場合による。具体的にはMSX2やPCエンジンやPC-88/98やサターン。
それはしかし美少女ゲームというジャンルが、マシンパワーを必要としないゲームだから、
逆に
「静止画の表示能力も時代遅れになった」「全体的に寂れた」「次世代マシンと比べて容量不足」
ようなパターン、たとえばメガドライブ・スーパーファミコン・ニンテンドウ64・X68kなどの場合は
最終的にはシューティングやパズルアクションあたりが出て終わる。
たとえばNintendoDSの終焉が美少女ゲームまみれになると思うか? 違うだろ。
それはNintendoDSの表示がしょぼいし、ROM容量に限界があるからなんだ。
今すぐ消費税の公平性の話をしよう - 赤沢 良太 （アゴラ） - Yahoo!ニュース
http://zasshi.news.yahoo.co.jp/article?a=20110602-00000002-agora-soci
この記事を読んで、世間の消費税の問題点の的外れさが気になったので書く。
世間一般的に消費税のことが語られるとき、次の2点が論点に出ると思う。というかこればっかりだ。
確かに理論的にはこの通りだ。が、それは机の上でのお話に過ぎない。ここで挙げる問題点に比べたら逆進性なんて小さな問題でしかない。
現実を見たらこんな理想論はどこにもない。消費税なんて無くなってしまえ、と思うに違いない。
まず最初に消費税の仕組みをおさらいしよう。ただし、理想論でのお話だ。
消費税に関しては、消費者は税の負担を追うけれど直接納付するわけではない消費税は間接税だ。では誰が納付するか（納税義務を負っているか）というとその消費税を預かった事業者である。
事業者は預かった消費税を消費者の代わりに国に納付するわけだけれど、事業者自身もモノを購入するような消費者の一面を持っており、消費税を支払っている。
事業者Aが支払った消費税はまた別の事業者Bが納付するわけだから、その分2重に納付されてしまわないように、自分が預かった消費税から自分が支払った消費税をさっ引いて国に納付することになる。
このように事業者間で消費税のリレーが行われ、末端の消費者が負担した消費税が国に入金される、というのが消費税の仕組みである。
机の上のパズルとしては非常に合理的に見える。
このようにして、「消費税ってのはうまくできてるんだよ」という説明で終わってしまっているが、それはある特殊な前提があった上でのお話だ。
その前提は、
というものだ。すべての取引に消費税がかかるのであれば、先ほどの仕組みは簡潔でスムーズにわかりやすい。
「えっ、違うの？」と思う人も居るかもしれない。消費税が全然理解されていない、いい証拠だと思う。
しかし、消費という感覚にふさわしくないとか、政策的な目的などから、消費税が課せられない取引が存在する。
給料の支払いや土地の売買、社会保険診療だったり、住宅家賃だったりが代表的なところだと思う。
これらの取引には消費税が課せられないが、これらを生業とする事業者はそこら中に存在する。
とある大家さんがいて、マンションの賃貸（消費税ナシ）と事務所の賃貸（消費税アリ）をやっている。
先ほどの消費税が国に入金されるまでの流れにこの大家さんを当てはめてみると、大家さんは、事務所家賃で預かった消費税から自分が払った消費税をさっ引いて納付するわけだが、大家さんが支払った消費税はマンションの修理代だったり、事務所の修理代だったりするわけだ。
ここで、「アパート修理代の消費税はさっ引いていいのか？」と疑問を持って欲しい。
事務所修理代についての消費税はそれに相応な事務所家賃という形で預かることになる。まさしく「預かったんだから納付する前にさっ引くよ」なのだ。
だが、アパート修理代についてはどうだろう。消費税を払うことは払うが、預かる消費税も存在しない。まさしく、大家さんが消費税を負担しなければならない状態になるのだ。
これを、アパート修理代の消費税をさっ引いてしまったら「預かってないけどさっ引くよ」という訳のわからないことになってしまう。
こういった問題があるため、消費税の納付額計算上もさっ引かせないように仕組みを作っているが、取引量を考えるとそんな個別に区分けなんてすることができないので、なぁなぁにされている。
基本的に、真っ黒以外は事業者有利なところでやっているのが現実だ。
消費税は↑のような面倒な区分集計をしないと納税額が計算できない。ちっちゃな事業者には大変でしょ？ということで「免税事業差」やら「簡易課税制度」やらがあります。
消費者の代わりに事業者がまとめて納付するんじゃなかったの？
百歩譲って小規模事業者保護がアリだとして、取引規模で判断する小規模事業者なんて、会社をたくさん作れば一社あたりの取引規模は自由に操作できる。
現実、取引規模を小さくしたペーパーカンパニーで人件費を計上して一切納税せず、本体の会社じゃその人件費分を業務委託費だとかいってさっ引く消費税を作って納税抑えるとか。
消費者が負担したと思ってるお金は実は事業者の懐に入ってた、とかどんな詐欺制度だよ。
それに、消費税は赤字でも納税が出るから滞納されやすい。滞納されたんじゃ税収増になんてならない。
こんな状態で税率を上げようとか言ってるのはバカかと思う。
こういう問題点が全然表に出てこない。増税論者も現実を知らずに、理想論だけでお話ししてる。
そして一般国民はそもそも消費税の仕組みさえ理想論以上のことを知らないで賛否を迫られてるとか。
なぜ増田で書いたのか。良くある話だけど、身バレしたくないのと、自分のブログでやるよりもみんなに見てもらえるかなぁと思ったから。
２０ミリシーベルト問題だが、実は放射線医学専門家は引き下げを主張したが、
文部科学省側が２０ミリシーベルト維持を押し切った、という未確認情報がある。
真相は未確認だが、私見では「さもありなん」という気がする。
より深刻なんじゃないか、と思う。
「自分たちが気付きあげた教育メソッドこそ最高」と固執して方針転換が遅れたり、
他学会から「教育界の常識を否定」された際にも直視しなかったりする。
例えば「教室の天井高は高ければ高いほうがいい」と教育界では信じられてきて、
文部官僚は地方自治体から申請あった「天井高の規制緩和」をかたくなに拒否してきたが、
しぶしぶ埼玉県で認めたところ、「かえって天井高が低くした方が、児童は心理的に落ち着く」という
あるいは「教育効果を上げるには少人数教室が最善」と教育関係者（文部官僚も日教組も）は主張し続けているが、
経済学者から「少人数教室にすると、トップ層が切磋琢磨しなくなり、かえって全体の平均学力は落ちる」と
今回の件についても、文部官僚は「屋外での体育活動が重要」とか
「子を疎開させて親と別離することは精神的に問題」という「もっともらしい理由」で
「できるのであれば２０ミリシーベルトを貫いて、中通りで極力平常どおりの教育をしたい」という思惑を貫こうとしている。
彼らは「体育活動が重要」「親子のコミュニケーションが重要」という「従来からの教育メソッドの固執」という発想しかできない。
緊急時には、それこそ体育授業の１年間停止とか学童疎開という非常手段も求められるのに、
そういう「従来の延長線上からかけ離れた措置」を文部官僚は非常に嫌がる。
前例踏襲主義、という点では、文部科学省、もっと言えば旧文部省こそ、「官僚の中の官僚」である。
福島の児童の不幸は、官僚の中の官僚に学校運営権を牛耳られたことである。
※作成にあたりhttp://anond.hatelabo.jp/20081215174950を参考にしています。元記事書いた方、勝手に使ってごめんなさい:-/
嫁をアイコンにしてる人々。一番多い？
憧れてます。
就職が心配されます。やたら言うのは良くないけど、頑張って下さい。
一般に浸透してきた証拠ですね。
きっと花開く。おそらく。
ただただ、和やかです。
見た事無いんですが…
○chに比べれば緩くていいです
お世話になります。
未だ出会った事が無いのは何故
この方々にはセンスが要求されますよね
DMC3序盤で苦戦してるんですがどうすれば←
ストリートファイターってまだ出てるんですね・・・
まとめても大丈夫でしょうか
僕の事ですか分かりません
ぐんまけん！
僕のこ（ry
うっかりというかやはりというか、中途半端に終わってしまいました:( しかもしょーもないコメント付き。
人間が百歳まで生きられるかどうかについてはさておき、百年というと長いと思うかもしれないが、日数にしてみると36500日だ。少し現実的な数値に思える。
Excelの行は確か65536行まで追加可能だ。もちろんこれは理論値で、実際は文字数などによって追加がこれ以上できなくなるということもあるだろうが、それでも、1日を1行としたときに、100年分は余裕で入る。
試しに自分の生まれた日から今日までの日にちを並べてみた。圧巻である。
自分の人生の日程を、全てこの一つのファイルに収めることが出来る。
『嬉しい』と思うのは、どこかで過去の自分を振り返りたい、出来れば簡潔にそれをまとめたい、と思う自分がいるからだろう。
パソコンが無い時代、自分史を作ろうとすれば、それは膨大な紙との戦いになる。しかも、全体を俯瞰するだけでも、物凄く重労働だ。
だから大勢の人は、自分の過去の人生を、『記憶という雲に包まれた、巨大であいまいなもの』として抱えていたんじゃないだろうか。そしてその巨大な曖昧さを抱えたまま死んでいく。
そういった意味では、命や原理に対して、昔の人は諦観を抱きやすかったのではないだろうか。
今はパソコンで何でも管理できる。人間の一生の記録も。好きなときに開いて、自分が十七年前の三月九日九時二十三分に何をしていたかを検索して知ることが出来る。（記録していればの話だが）全体を軽く俯瞰してニヤニヤすることも出来る。
単純に良い時代になったと思う。僕も死が近づく年齢になったら、エクセルで自分史を作り始めたい。少しずつ、魚の骨が取れるように記憶を思い出していくだろう。パズルのように自分の人生を埋める。それは永遠に片付かないデータの整理みたいで、かなり無駄で、ちょっと楽しい。
さまざまな人種が入り乱れる中、俺は図書室で一人で本を読むのが日課だった。
しかも少し前から気になっていたアジア人の女性へのデートの誘いを断られ、憂鬱になっていた。
だが図書室に行くのも気が重かった。なぜなら、とある一人のせいで、俺はゆっくり本を読めない。
髪の長い、ちょっと太った黒人の女の子。毎回といっていいほどよく俺に話しかけてくる。
図書館に行くたびに居る。俺を見るなり隣に座って、話を一方的に始める。邪険にもできず、俺は流される。
なんなんだ？こいつは俺に気があるのか？とちょっと思い始めた。
だが、相手は・・。俺は人種差別をするわけではないが、黒人の女の子はどうしても受け付けない。
話したいこともないし、可愛いとはお世辞にも言えない。背は俺より大きいし、黒々とした唇や顔に魅力を感じられない。
今日もあいつはいるのだろうか。やだな。悪いけど俺は君とは・・・・・・・
その時、パズルピースが頭の中で嵌った。恐ろしくも、当然の納得がいくことに気がついた。
仲良くなろうと、きっかけがあれば積極的に話しかけていたとき。
目が合ったら、なんとか印象を残そうと、微笑んだとき。
あの子は、俺と同じような感情だったんだろう。
迷惑。うっとおしい。早く消えてほしい。別の世界の人種なんだから。
俺は苦笑いを返して断った。彼女はちょっと残念そうな表情を、黒い肌の顔に浮かべた。
それ以来、会話もなくなった。