 
|
はてなキーワード: チャンネルとは
分かりやすい「面白さ」というのは、送り手が読みやすいように情報に施した糖衣のようなものであって、情報そのものではない。「面白くて次々リンクをクリックしたりタブを展開したり」するのは、単に情報の送り手に踊らされているだけであって、情報強者どころではなく単なる情報の奴隷に過ぎない。一日24時間ＴＶを見て、チャンネルを変えてはゲラゲラ笑ったり、気が向いたら録画したりしているだけの人間を情報強者とは言わないのと同じ。情報に踊らされて自分を見失っているだけ。
そんなことよりも
…と思う、その感覚を大事にした方がいい。分かりにくい「面白さ」には価値があるし、それを分かるために「自分なりの」努力することにも価値がある。論理の「飛躍」ではない、自分にその論理が理解できていないだけだと思うべきだ。そして、そこからそういうモノを作りだせる人間になれば、それで飯を食っていける。分かったようなつもりでうまいこと言おうとするよりも大事なことがそこにある。
http://www.e-mansion.co.jp/bbs/thread/48216/all
by 匿名さん 2009-07-07 18:42:00
子犬の鳴き声よりも太鼓叩いている住人いますよね？時間関係なく…
by 匿名さん 2009-07-07 21:02:00
太鼓？何階ですか？
以前にも掲示板でドラム叩く人がいるって書き込みがありましたが。それとは別なんですかね。
そうです？そんな感じの音！多分高層階の人
太鼓かどうか分かりませんが、リズムよく音というか「ズンズン」って感じで聞こえる時があります。結構夜中ですよね。
家は上の階の人がまだ引越しして来ていないときに聞こえましたから大分広範囲に響いているのだと思います。
高層階です。
現在午前１時半？
祭りの太鼓なのかかなり迷惑なずんずんと響く音をならしているのはどこだ？
いい加減にしろ？？？
でていけ？
夜に太鼓なのかなんなのかしらないけど、うるせぇんだよ！
太鼓の音って南棟ですか？東棟ですか？
by 住民 2009-09-15 16:08:52
多分東棟じゃないですかねぇ？かなり時間無制限でやってますよね？前から気になってたんですけど｡でも響くとなると南棟なんですかねぇ？
http://www.e-mansion.co.jp/bbs/thread/72652/all
by 住人 2010-05-15 01:51:39
太鼓かドラムかドンドンなってるのうるさいって前いってましたよねぇ！わかりましたよー
１４階に南千住の有名な寺の住職さん、笑っていいともに出てたおかまっぽい住職知りません？
どうしますかねぇ?
お坊さんの太鼓､どうにかならないですかねぇ？自分の寺でやれよ！
太鼓？なんですかね。かなり響きますね。はっきり言って迷惑です。
この際、部屋番号を明らかにして抗議することが必要なのではないでしょうか。
御仏に使える身で、挨拶が出来ないとは…
あぁ。おねえの坊さん挨拶しないよね。
by マンション住民さん 2011-06-26 15:38:34
坊主に毛頭w
http://b.hatena.ne.jp/entry/www.shoenzan.com/index.html
この場所にあるマンションの一室に「水無昭善阿闍梨」の「祥炎山不動院東京道場」があります。
http://earthjp.net/mercury/1102270020.html
久慈市での評判
（うちのお母さんも、水○さんが、ブランド品いっぱい買いまくってるの見て、チャンネル変えてました。 ）
http://jbbs.livedoor.jp/bbs/read.cgi/travel/2258/1302627562/l50
http://ohtsuki-yoshihiko.cocolog-nifty.com/blog/2011/08/post-e5ed.html
http://itunes.apple.com/jp/app/xochi/id451940189?mt=8
YouTube上に違法アップロードがあるのを前提に作られたアプリとか色々あるけど、その作者はその点何も気にならないのかな。
「音楽はYouTubeで楽しんでます」みたいなことを平気で言えるような人達が、「このXochiってアプリ神だわーiPhoneでも音楽タダで聴き放題だわー」みたいなことをTwitterでツイートしたのをその開発者がリツイートしまくってたりしてて、見ていて「節度ねぇなぁ」と思う。
最近の音楽業界もねー自分が歳くってきたからかおもしろいものが減ってきていると思ったりもするけどねー、CDが売れるかどうかが死活問題な人達もいるわけで、そういう人たちの生活蝕んでるって意識とかないのかな。そういえば「君のラジオ」にも随分前に同じような事感じたなぁ。
まぁ悪いのは違法アップロードをしている連中なわけなんだけど。それを広めることに加担することへの意識というかなんというか。
かたやTwitterやってるミュージシャンがYouTube上の違法アップロード音源動画やMVを平気でツイートしてたりもするし。自分のもの、他者のもの含めて。そういうものへの考え方も色々だし単純でもないねぇ。
違法アップロードしてる連中全員いなくなれば良いし、代わりにミュージシャンオフィシャルチャンネルでMVフル視聴とかライブ映像一部視聴みたいなコンテンツがもっと増えて、そういうものを楽しむためのポータブルデバイスアプリなんかが出てきたら素敵なんだろうけどなぁ、と夢想する。
THE MANZAI って４時間くらいあったけど漫才部分だけ見たら単純に半分で済む量。とはいえ２時間で無駄なくやったら尺足らずだし、それはまあ説明部分もあるからよしとしよう。でもなげーよ。
他にももう、終わったな、と思わせる演出が多数あったが、とにかくキビキビとやってないんだよ。キビキビと。ダラダラしてる。
→参加意識を煽っているけれど、笑うたびにボタンを押すということは漫才の面白さに集中できない。仕様ミス。先にアプリを落として一斉に送信させるというのも、問題がある印象。フジの企画に問題がある。
ワラテンのグラフと一緒に、同じ番組内で同じ漫才を再鑑賞するのは、前半見ていなかった人向けのサービスのつもりだろうが、間延びしてしまいおかしい。参考にはなるが、「ほお」で終わり。ビデオなら絶対飛ばすところ。
問題２ 慢心した優勝特典
フジテレビレギュラー番組、漫才師だが漫才の番組が貰えるわけではない。漫才の番組が貰えるのなら嬉しいだろうが、単なるトークタレントとしての役回りが回ってくるのであれば矛盾しすぎている。副賞の各番組ゲスト、っていうのも結局はトークで呼ばれるのが半分以上だから名前を売る以上の意味が無い。まったく売れなかった若い人ならそれが価値を増すが、パンクブーブーではドラマを作れない。
結局は予算削減策でしかなく、フジも落ちる所まで落ちているとしかいいようがない。またフジは自分の価値を高く見い出しすぎ。
ただ控えめに協賛した、日清のどん兵衛はいいと思う。あんな数（１０年分）本人が食べたら確実に身体を壊すけど、楽屋において後輩にあげる分には後輩が何年も食に困らないからね。
問題３ 無駄な演出
フジの番組全般に生でやるとダラダラとした無駄な部分＋小難しい説明だらけである。進行押しの間の時間調節なら、わかるのだが、入場演出で無駄にリムジンとか入れて、オープニングから30分以上漫才が始まらないってどういうことだよ。ワラテンの説明も長い、フジのサイトにこさせるための小細工とはいえ。投票トラブルを避ける意味では完璧な説明であったが、視聴者にはまったく無駄でチャンネルを変えさせるレベルの話。あんなの事前に別番組で説明して分散ダウンロードさせるとか、Dボタン側に逃がして文字で済ますとかできるだろ！ 俺は一斉送信でサーバが落ちないかのほうが気になったよ。
あと、有名人を客席に散らせ「これくらい入れておけば受けるだろう」的な考え。
バブル期に入った人が作ってるんだと思うが、視聴者は漫才が見たいんだよ。モデルの顔が見たいんじゃねえんだよ。制作者側がバカにするのも大概にしろ。有名人を呼ぶならコメントを全員取れよ。メイクまで入れて客席で笑うだけで、ノーコメでギャラ貰って帰る奴を許すほど度量はこっちにはねえよ。
問題４ THE MANZAIの本来的な部分を踏襲していない点
初代のＴＨＥ ＭＡＮＺＡＩは元々洗練されてない舞台漫才をショー化するものであった。横澤さんが死んでいるとはいえ、当時のTHE MANZAIに敬意をはらっているのは西川さん位じゃないか…。２０１１年版としての進化がアレなのかもしれないし、余計なものを入れずに「４分見せている」ということは評価できるとはいえ、余計なものばかりつっこんでいる部分は「製作者側が漫才の力を信じていない」というようにしか取れないんだよ。
笑えるものを評価しよう、という意味合いでは、この矛盾があるものをあえて入れるという意味で審査は厳正であったのだろうが、全体には今回はコントっぽい物が多かった。コントであろうと面白いものを評価する、というのは正しいが漫才としてちゃんと漫才な作品をもっと増やさないと絶対的にダメだし、これも制作側がコントのほうが面白いと思っている証拠としか思えない。
あとたけしの茶番ダブルブッキング演出は不要。（いい訳としてはわかるが、別に漫才師がつっこみでいった通りOPが長くなければ全部の漫才を見れるわけだし、あとハラハラしないものを入れてどうするのかというか、単にたけしがTBSに入るまで、という尺を稼いだだけでしかない）
生で見なくてよかった。
また、１５年くらい不遇な人たちが多かったので、それに光が当たるのはとてもよいことなのだが、雇用されない関係のため数百円のギャラからのスタートでも文句を言わず、売れないまま１０年以上のキャリアが必要とされる日本では、漫才師として暮らしていくことが非常に難しいということがよくわかる。
皆主な仕事を漫才にして女の人に扶養してもらったりしているようだが、本来的な収入はある状態で、漫才は副業でやるのが適正だと思った。言ったらハングリーさがないといわれそうだが、べつに先輩たちが作ったストーリーに乗る必要ないだろ。黙ってればいいのだ。
最後数秒から数十秒単位で、終了前に動画が見れなくなってしまう。
http://blog.livedoor.jp/himasoku123/archives/51683817.html
こういう「良質」な番組があったとしても、母ちゃんは即座にチャンネルをフジテレビに変えてしまうから見れない。
自分が見て、「俺のほうが賢い」って思えるようなニュース以外は見ないから。
父ちゃんはマスコミは腐ってるといって自分のプライドを保ちたいだけで
別に自分が勉強してるわけではない。踊らされてるのをわかってない分ある意味母親より頭悪い。
で、私だが、これも弁護するつもりはない。私もダメだ。
そもそもテレビ見ない。
特にそういう真面目な話しとかに興味が有るわけではないし、
BBCニュースとか見ても、見方がわからん。あれ結構観るために基礎的な教養が必要だと思う。
子供の頃から見てれば自然に受け入れられるのかもしれないけれど、
多分、日本人が完全に日本語に翻訳されたBBCを見ても、わからんと思う。
「日経新聞の読み方」なんて本が売れるこの国で、
そして、それをありがたがって読んでいる俺が、BBCニュースを理解できるとは思わん。
そして、みんなそのこと＝自分はバカ、であることはよくわかっているが、
そのことを直視して受け止めるのがツラいので、
今日も一日バカ番組を見て何も考えないか、マスコミの餌に食いついてプライドを保つか、
ネットで他の人の手垢がベタベタついた偏見まみれの記事を真実と思い込むか、そんな事しかできない。
キャラクターの魅力はあったとおもうので、そういうのも大きかったけど
わからなくても、わかってる人間が並走してくれて、助けてくれると思うと何とかなる。
みんなニュースに興味がないわけではないが、見てもわからんのだと思う。
わかるなら見たいと思ってる人はいると思う。
しかし、誰もその役をやらない。代わりに、
そこでわからなくても楽しめるような「萌え要素」＝ニュースで言えば犯罪とか政治家の失脚とか、お笑い芸人とかコメンテーターの耳あたりの良い無責任発言ばっかり散りばめられた番組を作る。結局それで見る人ってのは、人格的にブヒブヒ言ってる萌え豚と一緒で数が限られる。しかも先細りしていく。
ちなみに池上さんはわかりやすかったけれど、そしたらそしたで
「ニュースは池上さんがやってるやつだけみればいいや」という独占状態になっていたなぁ。
俺も、禁書のアニメについては、アニメ自体は４倍速で見て、解説を読むとかやってたけど。
本当は池上さんがやってるような個別に丁寧解説とか要約じゃなくて、自分自身でニュースやコンテンツが楽しめるようになるためのメタ的な情報が必要なんだろうな。
歴史知識ないやつ向けのコンテンツって考えると、大河ドラマのように説明のための尺が十分に取れる作品でもお江みたいなのになっちゃうようだし、まして１クールのドラマやアニメなんてどうしようもないし、ドキュメンタリーについても掘り下げがむずかしいとかになるのか。はははどないせーちゅーねん。
第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 練習問題
http://anond.hatelabo.jp/20111210202721
俺のイメージだと飲み会は、韓流ドラマで例えたほうがしっくり来る。
食事時、母と姉がリビングで韓流ドラマを見ていて、二人で盛り上がっている。
俺は全く興味が無いので何も知らないため、一人だけ話題に加われない。
チャンネルを変えることも、ワンセグで別チャンネルを見ることも許されないし、
韓流ドラマ以外の話をしようと思っても「あんたは黙ってろ」と言われる。
一人だけしゃべることが無いので、黙々と手と口を動かしているとさっさと食べ終わってしまう。
さっさと食べ終わったので席をたとうとすると「ガツガツするな」「みんなが食事を食べ終わるまで座ってなさい」と言われる。
二人が楽しそうにしゃべくりながらだらだらとご飯を食べているのを横目で見ながら、
俺はひとりうつむきながら、じっと座って終わるのを待っている。
耐え切れなくてお茶をがぶがぶ飲むから、終わった頃には体調が悪くなっている。
次からは、ゆっくりと食べよう、噛み締めるように食べよう、そう思って席を立つ。
「あんた、皿洗いよろしくね。私たちはもう少しドラマ見てるから」
頑張って韓流ドラマに興味を持って、ちょっと勉強して話題に参加すれば楽しくなったのかもしれない。
頑張って後追いで参加してみても、向こうは私が付け焼刃の知識で参加しようとするのを歓迎しなかった。
「二人のほうが楽しく会話できる」のに、「わざわざレベルを落として一人新しく仲間を入れる」のを嫌がったのだと思う。
それでいて、「夕食の場はこうあるべき」というイメージを崩したくないから、楽しんでなくても自由に振る舞うやつがいることは許さなかった。
父はほとんど食卓にいない。残業ばかりでタイミングが合わないのだ。
彼がいるときだけ、彼がチャンネル決定権を握るため、韓流ドラマよりはましなニュースとかになる。
それとてニュースであって、バラエティなどが見れるわけではないけれど、ニュースならまだ喋れる、少なくとも「会話を禁じる」ようなことはない。
チャンネルが固定されて、特定の話題以外について発言することを禁じられて、退出も許されないあの苦痛な時間でさえなければ、私は満足だ。
俺はこの夕食に参加したくがないがために、夜遅くまで部活を張り切って、塾にも通って、見事に国立大学に合格できました。ありがとう韓流ドラマ。
飲みニケーションは、我が家の二人の女と同じウェットさを感じさせるので、嫌いだ。
多様な人が多様な形で楽しめるようになってない。 TVのチャンネルのように、楽しめる人たちだけで楽しんで、他の人達には何も与えない。
それでいて、「飲み会は楽しいものでなくてはいけない」「飲み会はみんなで揃っているものだ」みたいな枠に縛られて私達に何もさせない。
時間の無駄、なんてものじゃない。 自尊心をすり減らされる拷問なんですよ。
参加したくないんです。僕が参加してもどうせあなた方の足しにならない。だったら、楽しいと思う方だけ参加してください。その間は、無給で仕事するでもいいです。
あんな惨めな思いをさせられるくらいなら、その時間無給で働くか、英会話スクールにでも通ったほうがましです。
あと、リビングで韓流ドラマを見ている母親は、家族虐待だと思うので、いますぐもう一つテレビを買って、自室出一人で見てください。
韓流ドラマを否定するつもりはありません。 あなた方がそれを楽しむのは自由です。
ただ、一人とかふたりだけしか楽しめないものは、個別に楽しんでください。
「伝説の人事部長」に当社ジェネラルマネジャー今村が出演いたしました。
「IRチャンネル ズバット分析！注目企業」に代表石村が出演いたしました。
下記ページよりご視聴ください。
「IRチャンネル ズバット分析！注目企業」(2011.12.4放送分)（開始から18分後に出演）
※「IRチャネル～金田一洋次郎のズバッと分析！注目企業」の番組については、
こちらをご覧ください。
「通販サイトのアプリを配信 チヨダ」 アプリの開発は、通販サイト構築の協力企業であるEストアーが担当した、と掲載されています。
「チヨダ、ネット通販強化 スマホ用アプリ配信」電子商取引支援のEストアーが開発したシステムを採用、と掲載されています。
自社のフェイスブック内にECサイトのページを作成できるサービス「Eストアーコネクト」の提供を開始した、と掲載されています。
進むべき場所や、着地点が、いつまでも、わからず。明日、これから、今、何をすべきか、わからず。ただ、情報を、右から左へ、受け流す。何を入れて、何を処理して、何を吐き出すか、わからず。ただ、目の前にあるのは、真っ白い原稿用紙。何かを書きつけるための、原稿用紙。でも、何を書けばいいかわからず。どこから手をつけていいか、わからず。
何をすべきかわからず。ただ何もできず。
ペンは机の上。音楽をつける。一曲が終わらないままに、次の曲に早送りする。いつも、二つ以上のことを、同時にこなそうとして、一つのことも出来ず、ただ、何も生まれず。そうやって生きてきた26年間が、とても無意味に思えて。それでも、何か出来ると自分に言い聞かせて。きっと自分は特別なんだと言い聞かせて。20年後に自分が何をやっているか、わからず、何もわからず。今日もまた、意味もなくインターネットを歩き回り、エロ動画を見つけ、自慰にふけ、また何ごともせずに、トイレに行って、寝るだけ。
何をすべきかわからず。ただ何もできず。
目の前にあるのは、沸いたお湯と、カップ麺と。一杯のビール。それだけ。ただそれだけを、飲んで、食べる。考えがめぐり、テレビをつけ、全てを忘れ。番組が終わり、5分間のニュースが始まると、全てが終わったような気がして、別の番組をやっているチャンネルに切り替え。何をすべきかわからず。ただ目の前の時間を食べる虫を眺め、食パンは干からび、粉をふき、カビが生えている。
何をすべきかわからず。ただ何もできず。
春が来て、夏が来て、秋が来て、冬が来る。何もやってないけれど、季節はめぐり、半周遅れでついて行く。何もできず、何をすべきかわからず。何かをしようと思っても、集中力がもたず、常に言い訳をして、次の言い訳を考えている。外に出れば何かが生まれると信じて、外に出て、夕焼けの下散歩をして、何かが生まれると信じて、夜が来て、家に帰る。音がほしくて、テレビをつけ、9時から始まって、何も生まれず、12時が来て、風呂に入り、また眠りにつく。
何をすべきかわからず。ただ何もできず。
空を見上げても、何も感じず、感じようと思っても、何も生まれず、また眠りにつく。
何をすべきかわからず。ただ何もできず。
ファンキーモンキーベイビーズの歌が嫌いだ
店で彼らの曲が流れたらそそくさと店を出るし、テレビ番組で彼らが出るとチャンネルを返す程大嫌いだ
今、ネット中で大好評叩かれ中のJPOPの中で今が旬のヒルクライムや西野カナも嫌いだけど流れても店を出たりしない(チャンネルは回すけど…)
だから私のファンキーモンキーベイビーズとJPOPに対する嫌悪感の根本は深さも強さも違うと思う
で、ずっとヒルクライムとファンキーモンキーベイビーズが嫌いな理由って同じだと思ったんだよ
これら二つは歌詞に"愛してる"だとか"会いたい"とか簡単に洒落た比喩表現もなく書いちゃうからなのかなーって思ったんだけど、ちょっと前にシーブリーズのCMでファンキーモンキーベイビーズの曲起用してたじゃん？
「♪君の顔見てると胸が苦しくなるんだよー」って感じの歌
このCM流れてた時、ファンキーモンキーベイビーズにそんな嫌悪感抱いて無かったからチャンネルも回さずに聴いてたんだけど流れて行くうちに"この歌なんか間抜けだな」って思うようになったの
で この間抜けさなんだろうと思って考えてたらあることに気づいたの
「あっ この歌なんか棒読みだ」って
http://anond.hatelabo.jp/20110907193725
を書いた増田だけど久しぶりに増田にログインしたらトラバがついてたんでお返事。
http://anond.hatelabo.jp/20111005112736
見てるかわかんないけど。
これはそのつもりで書いてます。ブラックリストホワイトリストという言い方ではなくて、オプトイン、オプトアウトという考え方で。元記事にも書いてあるんだけど、日本の法律ではオプトアウト方式は認められていないので、合法にやるにはオプトイン方式でないと無理だと思っています。
オプトアウト方式が認められていないのに、著作権違反はいくら大規模にやろうと親告罪であると言うゆがみがあると思っているんで、個人的にはそこは改善されるべきだと思っているけど。フェアユース導入なり、大規模著作権違反の事案は摘発が可能なようにするとかバランスを取るべきだと思う。
例えば自炊依頼のために許諾を求める業者は、その結果に責任取れるんだろうか？
その責任の所在を、自炊業者に求めるなら、法的リスクと収益で割が合わないだろうし、事故として上限免責されてしまうなら、許諾するのが馬鹿らしい。
これはそもそも自炊業者には責任は発生しないと考えます。許諾を得ていればもちろんのこと、許諾を得ていない真っ黒な現状でも。
電子書籍でもDRMフリーで販売されているものがありますが、そのDRMフリーの電子書籍が違法に流通して実害が出たとしても、DRMフリーの電子書籍を正規に許諾を受けて販売した業者は責任を問われないのと同じです。違う言い方をすればコピー機を有料で貸し出しているコンビニや、ドキュメントスキャナ、コピー機を製造している業者が違法性を問われないのと一緒です。もちろん違法流通のために特別な何かをしている場合は別だし、幇助レベルではない別の違法行為があれば違います。
実際に裁判で訴えられるとしても訴える側が自炊業者側に違法性を予見して未必の故意があった等と言う事を証明しなきゃならない事になるわけだけれど、そんなことはまず無理だと思う。
証拠（因果関係）が希薄だから自炊業者無罪なら、余計悪い方向だ。
ちなみに。
電子透かしを求めようが、何をしようが、業者が故意に行うデータ流出は防げないし、アフィリ等で流出の方が儲かる事情があれば簡単に崩壊する。
これは信頼関係を築いていくしかないと思います。と言うのはこれ電子書籍に必ずついて回る問題だし、昔は書籍についても同じ問題がついて回っていたから。と言うのは、販売量は業者しか分からないと言う事だからです。
最近の本でも伝統がある出版社の本なら奥付に「検印廃止」って書かれているのを見る事ができると思いますが、これは何かと言えば昔は出版社が作者に内緒でたくさんすって売っているのではないか（いわゆる偽版）を防ぐために、著者が検印を押した紙で確認するという事が行われていた名残です。同じ版をつかって作者に内緒で刷って裏流通させているんじゃないかと言う疑惑があったんですね。また電子書籍でもDRMがあろうがなかろうが、電子書籍販売業者が横流ししていると言う疑惑は当然ついて回ります。
もちろん、「状況が同じだからって自炊業者が問題無いわけじゃないだろ」って話は当然あって、だからベンチャーなんかがぽっと出でやるのは難しくて、信頼のある印刷業者やら取次やらが既存の自炊業者をノウハウごと買収してやるのがいいんじゃないかと言う〆にしてあるわけです。
実は元記事では触れてなかったけど、ここにある需要があって商売になるかってのが最大の問題としてある。でこれについてはなかなか難しい。
今後電子書籍は黎明期を脱してくるだろう思う。Amazonが来るぞとか言う印象論ではなく、
などが主な理由で、つまりは大手出版社が本気になりつつあるからと言う事なのだけれど、だけどこれは新刊や比較的近年に発行されたものに限ると思うんだよ。
一方今自炊したいという人の話を聞くと、だいたい2種類需要があって
と言う所なんだけど、電子書籍が普及してくると前者の需要は尻すぼみになると思う。と言うかむしろ成りつつある。わざわざ同価で販売されている電子書籍をDRMがあるからといってわざわざ自炊する人間がどれだけいるのかというとそんなにいるとは思えない。
一方後者の需要なんだが、こちらはむしろ電子書籍が普及すれば普及するほど増加してくるんじゃないか。今でも切実にスペースが足りない人は多い。たとえば私もそう。で、電子書籍の環境がだんだん使い物になるようになってくると、その欲求はどんどん膨らんでいくと思う。
また電子書籍で本を読むことが当たり前になってくると、古い蔵書を読みたいという時、紙じゃなくて電子化して読みたいという需要もどんどん増えてくると思っています。
しかし、新刊書籍については需要もあるし、DTPデータも丸ごと保存された状態から発刊と同時に業務フローの一環で電子データを作る事ができるからコストは安くすむし、どんどん電子書籍が出るだろう。
一方、古い書籍はどうだろう？DTPデータが消えてしまっている、あるいはそもそもDTPで作られていないとかで電子書籍を作るコストも新刊書籍より高い。しかも需要はニッチだから作成コストがとれない。だから全ての書籍をカバーすることなんてとうてい無理だ。ただこう言った事情から電子書籍が出ないのであって、権利問題がある訳ではなかったりするのも多いでしょう。電子化するコストは多くの人が言うほど安くはありませんし。
そこに、自炊業者と言うのは存在していけるのではないかと思うのだけれどどうだろう。確かに今の違法でありつづけることで必要なコストを払わない対価ではとても無理だが、たとえば引っ越し業者などと提携して、貴方の蔵書丸ごと電子書籍化しますといったサービスとしてはありえるのではないか、許諾があるものは自炊し、許諾がないものは既存の電子書籍がある場合はそれを案内しつつ、どうしても許諾がなく電子書籍化もできないものは返却する。（希望に応じて裁断だけ手がける）電子書籍化の要望が強いが権利者不明などの理由によってできないものは裁定制度を利用するといった電子ライブラリ構築エージェント的になれないかと思うわけです。
一時期、PUNKにはまってたことがある。HR/HMを聴くことに疲れたときに、PUNKを聴くと元気が出た。毎月CD屋に行っては、視聴コーナーに陣取って、聞いたこともないバンドのCDを買っていた。
そんなときに買ったものの一つに、"Welcome To The Looserville / Son Of Dork"がある。日本発売は2006/02/22。ライナーノーツを見ると何か書いてあるんだけど、まあ詳しい経緯は置いておいて、このアルバムにも収録されている"Ticket Outta Loserville"(ほぼアルバムタイトルですね)は、en/Wikipediaにもある通りUKで初登場三位になったらしい。実際に聴くと、ポップで明るくて単純にいい曲なんだけどね。オマージュ云々はこの界隈の標準だし。しかし、このバンドは全く日本では流行らなかった。当時まだ、BURRNとか毎月読んでたころだと思うけど、特集記事を読んだ記憶もない。
そんなこともまあどうでもいい。所詮UK三位くらいじゃニュースバリューも小さいのかもね。でも、その"Ticket Outta Loserville"の歌詞は実は結構Nerdっぽかった。概ね、"17歳のときにフットボールチームに入れなくてチェス・クラブの会報を作っていたような人間だけど王様ゲームで周りに爆笑されながらデートに誘ったら上手くいって夢みたいで信じられないけどマジっぽいからもうSTAR TREKのコレクションはいらないからしまっちゃったんだけどマジになったらフラれちゃって夜になっても叫んで目を覚ます状態なのにスコッティは助言もしてくれないしまたSTAR TREKのコレクションを出してそろそろ諦めないとね"、という感じ。これは賛否両論いろんな意味で日本のサブカル界隈でも盛り上がるのでは、と思ったこともあったんだが、実際はそこでもまったく盛り上がらず。そのころは、"ハレ晴れユカイ"のオリコンランキング入りで忙しかったらしいね、その界隈は。
そのときにいわゆるオタクに対して思ったんだけど、「こいつら偉そうにいろんなこと言ってるけど、本当のところは自分の周りのチャンネル以外は全然見ていないし、かなりアンテナ低いんじゃねーの」って言われても仕方ないのでは。だって一応UK三位だぜ。それに比べて(文庫は名作と言えるかもしれないが)ハルヒのアニメの主題歌(EDか)ごときがなんだってのさ。
＃なんだかんだでニコ動にはあるみたいだけど、あること自体が著作権侵害的にどうだかっていう感じだしそもそもアップロード自体が日本発売からも遅いし盛り上がってもいないしなんなんだって感じ。
父はいつも日本のニュースはクソだとか言って自分の意識の高さを自慢していたのだが、アメリカから帰ってきたら意気消沈してた。
向こうの人にも日本のテレビメディアの質の低さについて語っていたら
「じゃああなたはどういう媒体から情報を得ているのですか？あなた自身はどういう情報を持っているのですか？」
と返され、しどろもどろになったあげく
「大衆向けメディアの悪口を言っている暇があるならもっとちゃんとした媒体を読んだほうがいいですよ」と言われたらしい。
ですよねー。
というか、なぜ日本ではオッサンたちがいつまでも若者の悪口とかメディアの悪口を言うだけでとどまっているのだろうか。
ニュース専門チャンネルと契約するか、とか専門雑誌を取るかって考えても奥さんがそれを許さなかったりするのかもしれない。
大企業とかでもせいぜい日経新聞を読んでれば話が通じるし、それ以上を求められることもないんだろうな。
テレビ見ててチャンネルを回していたらたまたま怒り新党っていう番組でファン心理について扱っていた。
「○○という歌手が好きなら××という曲を知らないとそのファンとは言えない」と言われてショックだったみたいなことだった。
ショックだと感じた人からすれば○○という歌手を好きであるという共通点があるなら「好き」の形は色々あっていいでしょと思ったんだろう。
一方でファンとは言えないと言った人の気持ちとしては
1：××という曲も知らないでファンを名乗るとはおこがましい、××という曲を知らない人間を下に見るというルールを作ることで自分はがいかに優れたファンであるか示したかった。
2：××という曲もいい曲だからあなたが知らない○○という歌手の一面も知って○○をもっと好きになって欲しい、そして同じ価値観を共有できる仲間になって欲しい
みたいなのがあるのかなぁと思った。番組の流れ的には1として扱ってたけど。
番組のトークでは○○という歌手をちあきなおみにして話してたけどファン歴が長いマツコ・デラックスにしてみれば喝采が好きって言うのは素人らしい。代表曲が好きだっていうのは素人ってことなんだろう多分。一方で「年上の人の中には喝采がヒットした年に生まれた人間にちあきなおみについて語るとは片腹痛いと思ってる人もいる」みたいなことも言っていた。○○が好きという気持ちから○○が一番好きなのは自分であり、他をひれ伏させることで満足感を得たいという気持ちへ変化する人が多いってことなんだろうと思った
何かを好きになってその好きになった対象についてもっと知ることでさらに好きになる反面でその対象についての知識量や好きになってから現在に到るまでの時間の長さ「だけ」を愛情量と捉えてしまってご新規さんに対して排他的になる・・・という風に感じた。「はじめはみんなに良さを知ってもらいたくて広めたけれどある程度すると私だけのものになって欲しいと思う」と番組内では表現されてたけどまさにそんな感じなのかなぁ、と
誤解があったらあれなんで一応念のため言っとくとこう書いてると古参が鬱陶しいみたいな書き方になってしまったけれど通ぶるにわかもやっぱり見てて痛いものはある。でも古参にしてもにわかにしてもどっちも「詳しい人」と讃えられて特別な一人になった気分に浸りたいというところは一緒なんじゃないかなぁと思う。それが大して詳しくもないのに詳しいフリをするかご新規さんを全員通ぶるにわかと捉えて排他的になるかの違いであって。
古参にしてみればいくら古参だって胎内から出た時から古参だったわけじゃないんだし誰だって駆け出しの時期はあったと思うからご新規さんに対しては若かりし頃の自分を当てはめてご新規さんが分からないことあったら問に答えてあげるとか丸くなることが必要なのかも知れない。ご新規さんにしても他の人が持ってないものを持ったら自慢するんじゃなくて軽い提案程度にとどめておくくらいがいいのかも知れない。特別な一人になった嬉しさから好きと思える仲間が増える嬉しさで心を満たす・・・そんな感じかなぁ。