  |
はてなキーワード: 拡張とは
PCの方が開発は楽で、ダウンロード販売を使えば、物理的にも流通的にも中間マージンを大幅に排除できて
ゲーム会社は利益を得られやすくしかも価格も抑えられると思うんだよね。
PCの問題として、昔はメーカーマシンのゲーム描画能力が貧弱過ぎるという問題があった。
しかし、今はPC全体の性能向上とオンボード3D性能の向上によって、ある程度の描画能力までなら問題がなくなりだしている。
一方コンシューマでは、据え置き気に比べて絶対性能が微妙な携帯機が威力を発揮しているなど、ゲームそのものに求められる描画能力が昔程重視されなくなっている。
相対的にメーカーマシンでも要求されたゲーム性能を満たしやすくなっていて、障害はなくなっているように思える。
PCを持ってない人は少ないと思うけど、テレビ持ってない人は増えているのでは。
テレビとゲーム機を両方買うとかなりの出費で、スペースも食う。PCを拡張すれば問題ないけど…。
十分な開発環境やライブラリ、2Dツールはもちろん統合3Dツールまで無料で手に入るようになり、ゲーム製作の敷居はすごく下がっていると感じる。
ただ、HTMLの解析やJavaScriptの仕様（JScriptという独自言語を使ってたり・・・）がめちゃくちゃ。
クロスブラウザの敵であって最強の反逆者
個人的には、使う価値なし。
昔はこれが1番と言われていたが、最近はChromeに負けている。
拡張性はあるが、起動が重く、低スペックにはしんどいことがある。
Googleが作ったことだけあって起動もブラウジングもJavaScript実行も全てが早い。
最強。
ただし、ユーザーの声が開発者に届きにくすぎる（これはIEでも言えるが）
といった感じ。
一般人は手を出さなくてもいい
今年冬以降に発売されるandroid端末のメディアプレイヤーはHTTPヘッダのUser-Agentおよび拡張ヘッダにIMEI番号が含まれるということが分かり、騒動となった。
カレログ、applogに続きNTTドコモが参戦？ - http://togetter.com/li/202490
NTT docomo IMEI垂れ流し問題 http://togetter.com/li/202536
http://www.nttdocomo.co.jp/service/developer/smart_phone/service_lineup/music_movie/index.html
（魚拓）http://megalodon.jp/2011-1019-1834-56/www.nttdocomo.co.jp/service/developer/smart_phone/service_lineup/music_movie/index.html
こう記述されている。
Android端末の一部機種では、音楽・動画コンテンツを再生するためのメディアプレイヤーをドコモがプリインストールします。
メディアプレイヤーがプリインストールされる機種は2011年度下期モデル以降の主なAndroid端末となります。
ユーザエージェント
メディアプレイヤーがHTTP通信を行う際のUser-Agentヘッダは以下となります。
User-Agent:＜SP＞DOCOMO/2.0＜SP＞[AAA](MP;[BBB];Android;[CCC];[DDD]);imei:[xxxxxxxxxxxxxxx];networkoperator:[yyyzz]＜CR＞＜LF＞
＜SP＞：半角スペース
[]以外は固定値
AAA：機種名
xxxxxxxxxxxxxxx[15桁]：IMEI
yyy[3桁]：Mobile Country Code
HTTP通信時の拡張ヘッダ付加情報
メディアプレイヤーがHTTP通信を行う際は、以下の拡張ヘッダが付与されます。
x-dcmstore-imei:＜SP＞ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ＜CR＞＜LF＞
＜SP＞：半角スペース
xxxxxxxxxxxxxxx[15桁]：IMEI
ケータイ用語の基礎知識http://k-tai.impress.co.jp/cda/article/keyword/43518.html
によれば、
とある。
端末に固有の番号であるという認識でよいだろう。パソコンで言うMACアドレスのようなものだ。
重複する部分もあるが、いくつかの問題が含まれているように思える。
twitterで見られた反応をいくつか整理してみた。
これが最も大きい問題。twitterでIMEIってつぶやいている人の大半はこれを問題視している。
IMEI番号をそのまま送信している。
すなわち、コンテンツプロバイダ(CP)Aにも、CP-Bにも同じ番号が送信されている。
CP-AとCP-BでIMEI番号を突き合せて、収集した情報をリンクさせることができてしまう。
IMEI番号は端末に紐付けられている。
したがって端末を買い替えない限り番号は変わらない。
これが問題。
10年以上前から同じことが繰り返されているため、空間的時間的に広い共通IDを使うことの「何が問題か」知りたいなら過去の事例を参照するとよい。
等
高木浩光氏による行動トラッキングの歴史と境界線についての備忘録 http://togetter.com/li/197732
インターネットにおけるIDとトレーサビリティ(2003年)高木浩光氏 http://www.nic.ad.jp/ja/materials/iw/2003/main/ipmeeting/panel-takagi.pdf
Tracking Cookie - Symantec http://www.symantec.com/ja/jp/security_response/writeup.jsp?docid=2006-080217-3524-99
まだIMEI送信機能付きandroid端末が発売されていないので、どういう実装か不明のため、これは想像上の懸念だ。
このIMEI番号送信機能は、おそらくDRMに利用することが目的の一つだろう。
特定の機種でのみ購入した音楽が再生できる機能が組み込まれている可能性がある。
その場合、機種変更をするとIMEI番号が変わるために購入したコンテンツを利用できなくなる可能性がある。
あるいは一人で二台以上の端末を所有する場合、どちらか一方の端末でしかコンテンツが利用できない可能性もある。
実際、iPhoneにおいて似た事例が発生していた。認証にUDID（端末固有ID）を用いていたアプリが機種変更ののちに使えなくなる事例があった。
また、それまで利用していた端末をオークション等で販売する可能性もある。
その場合、端末の新しい所有者が、古い所有者の購入したコンテンツを利用できてしまう可能性もある。
ただしこれらは想像上の懸念だ。
UserAgentまたは拡張ヘッダに記述されたIMEI番号をもとに認証を行うサイトの出現が懸念される。
参考：かんたんログインの事例 http://www.atmarkit.co.jp/fsecurity/rensai/keitaiweb02/keitaiweb01.html
そもそもIMEI番号の取得はかんたんだ。
友達が不用意にその辺に放置した端末で「*#06#」と入力すれば取得できてしまう。
送信される番号はどのサイトに対しても共通なので、他のサイトで使うことができる。
そしてなりすましも容易だ。
とか。
ぼくよくわかんない＞＜
プライバシに関する専門家でもないので、補足訂正おねがいしまーす。
あと、この問題を扱うに当たって、何を「個人情報」だとするのかとらえ方が人によって違うことに注意したほうが余計な労力を使わなくて済む、と思いまーす。
そんでもって、 Microsoft は持っている。僕同様、みんなも知ってると思うけど、なんと驚くべきことに、 Microsoft はそれをよく理解していない。実に。でも彼らは、純粋に、偶然、プラットフォームを提供するビジネスから始まって成長してきたから、プラットフォームを分かっているんだ。彼らはその領域で30数年やってきた。 msdn.com に行って、少しの間ブラウジングしてみればわかる。もし見たことが無ければ、驚く準備をしておいた方が良い。なぜならそれがとてつもなく巨大だからだ。何千の、何千の、何千もの API コールがある。彼らは巨大なプラットフォームを持っている。実際の処大きすぎて、全く統率が取れていないけれど、少なくとも彼らはやっている。
Amazon は自分のものにしている。 Amazon の AWS （ aws.amazon.com ）は途方も無くすばらしい。行ってみてご覧よ。クリックして回ってみるんだ。全く恥ずかしくなる。僕らはこれらのひとかけらも持ち合わせていない。
Apple も、明確に、自分のものにしている。彼らは基本的にクローズな選択を、特にモバイルプラットフォーム周りでしているけれど、アクセシビリティを理解しているし、サードパーティ開発者の力もよく分かっていて、自分たちのドッグフードを食べている。それでさ、わかるだろ？。彼らは実に見事なドッグフードを作る。彼らの APIコールは Microsoft のそれに比べて実にクリーンで、ずっと昔からそれを維持している。
Facebookも持ってる。だからこそ心配になるんだ。ぐうたらな僕をここまでして書かせた理由はそれだ。僕は元来ブログするのも、プラスする（って言うのかどうか知らないけど）のも嫌いだ。そもそもGoogle+はぶっちゃけ話をするのにはひどい場所だけど、とにかくやらなきゃならない。Googleに成功して欲しいと思ったらね。で、僕は成功して欲しい！。まあ要は Facebook が僕を呼んでいるし、きっとそっちでやるほうがずっと楽なんだろうけど、Google は僕にとって家だし、だからこういう家族同士のお節介焼きのようなことをやっていこうよと言ってるわけだ。（訳注：この辺の訳怪しい。トラバで指摘いただいたのがすてきだったのでまるっと差し替え！。"アドバイス" thx ！）
Microsoft と Amazon 、それに Facebook （たぶん。実際僕はよく見ていないんだ。だってすごく落ち込むからね…）の提供するプラットフォームに驚いた後に、 developers.google.com に行ってちょっとブラウズしてみて欲しい。ね？大きな差だろう？。まるで君の5年生の甥っ子が、巨大で強力なプラットフォーム企業がもしリソース的に独りの小学5年生しか人を割けないって時に作るようなものをデモしてみなさい、なんていう宿題でもでっち上げたみたいな感じだよ。
どうか悪く思わないで欲しい。 Developer relations チームが、これを外部に提供できる形にするためにとんでもない努力をしてきたってことを僕は分かっている。僕が知る限り、彼らはとにかくケツを蹴り上げつつけている。なぜなら彼らはプラットフォームを理解しているからさ。プラットフォームに対して実に冷淡で、しかも時には敵対心さえあらわにされるような環境の中で、彼らは英雄のように努力している。
僕は率直に、 developer.google.com が外部の人にとってどう見えるかを説明しているだけさ。全く幼稚に見えるだろう。 Maps API は一体どこにあるっていうんだ？。いくつかはなんだかよくわからないラボプロジェクトとやらに入っている。で、いざたどり着いてみれば、そこにある API は全くけちな代物だ。まさに本当の意味でドッグフードだ。オーガニックなんかとは無縁だね。僕らの内部 API に比べれば、まるで不格好な別物だよ。
Google+ についても、悪く思わないで欲しい。到底彼らだけが違反者ってわけじゃない。文化的なものが絡んでいるんだ。僕らが内部でやってることっていうのはさ、基本的には、惨めでマイノリティなプラットフォーム部隊が、無敵で予算も自信もたっぷりのプロダクト部隊に多かれ少なかれ負け続けている、そんな戦争なんだよ。
ゼロから構築したプログラマブルなプラットフォームになるべきなんだってうまく気づいたチームってのはみんな弱者さ。 Maps や Docs なんかが思い浮かぶ。 Gmail もなんとなくそっちの方に進みはじめたように見える。でも彼らがそのために予算を獲得するのは実に難しい。なぜなら、それは僕らのカルチャーじゃないんだ。 Maestro の予算なんか、 壮大な Microsoft Office プログラミングプラットフォームの足下にも及ばないちっぽけなものだ。ふわふわ毛皮のうさぎちゃんと、 T-Rex の対決みたいなものさ。 Docs チームだって、このスクリプティング機能が無ければ Office に太刀打ちできないってのはよく分かっているんだ。でも残念なことに、予算が付かない。つまりさ、そうじゃないとは思うんだけど、現状 Apps スクリプトが Spreadsheet だけで動作して、 API の一部としてキーボードショートカットすらない。まさにチームが愛されていないって思うしか無いよね。
皮肉にも、 Wave は偉大なプラットフォームだった。冥福を祈りたい。でもプラットフォーム的な何かを作るっていうことは、そのまますなわち成功を意味するって訳じゃあ無い。プラットフォームにはキラーアプリが必要だ。 Facebook そのもの（つまり、 wall やら friends やらなんやらというデフォルトの機能）が、 Facebook プラットフォームのキラーアプリだ。そして、 Facebook アプリが、 Facebook プラットフォーム無しで成功できると結論づけるのは、深刻な誤りだと僕は思う。
みんなは、外の人たちが Google は傲慢だって言い続けているの、知っているよね？。僕は Googler だ。だから、みんなと同じように、外の人たちがそう言っているといらいらとする。僕らは全般的に見て全く傲慢じゃ無い。僕らは、まあ、99%は傲慢じゃない。僕はこの文章をこう始めた（遠い記憶をさかのぼってよ）、 Google は「正しいことだけをする」って表現した。僕らはよかれと思ったことだけをしている。だから、人々が僕らが傲慢だって言うときは、まあ大抵彼らを雇ってあげなかったときか、僕らのポリシーに不満があるか、まあそんなようなところじゃないかな。彼らはそれで気分が良くなるから、傲慢だ傲慢だと言っているんだろう。
でも、もし僕らが、僕らは全ての人に対して完璧なプロダクトをデザインする方法を知っているだなんて、そんなスタンスを取るんだとしたら、僕を信用してくれて良いと思うけど、結構そういう話を聞くんだけど、僕らは飛んだ間抜けになる。それを傲慢って言ったり、無邪気さって言ったり、なんて言ってもいいけど、結局の処、それは愚かさに他ならない。全ての人にとって完璧なプロダクトなんて、無いんだ。
デフォルトフォントサイズを設定できないブラウザについて話してこの話題を締めくくろうか。アクセシビリティへの侮辱ってやつについて語ろう。つまり、いずれ僕は年を取って、ほとんど目が見えなくなる。事実そうだと思う。僕は人生でずっと近視だったし、40歳にもなれば今度は近いものが見えなくなる。そうなればフォントの選択ってのは生死を分ける重要なポイントだ。それは君を完全にその製品から追い出してしまう。ところがどっこい Chrome チームってのははっきりと傲慢だから、彼らはゼロコンフィギュレーションプロダクトなんて言ってて、まったく厚かましくも、もし目が見えなかったり耳が聞こえないなりなんなりするなら、お前はファックユーだぜってなもんだ。残りの人生、全てのページを表示する度に Ctrl-+ を押せって言うんだよ。
これは彼らの問題じゃ無い。みんなの問題だ。僕らが徹底してプロダクト企業だということが問題だ。僕らは広くアピールするプロダクトを作った。例えば検索がそうだ。そのあまりにもひどい成功が、僕らの目をくらませてしまった。
Amazon もまたプロダクト企業だった。だから。 Bezos にプラットフォームの必要性を理解させるのには、外部の力が必要だった。その力ってのはどんどんと蒸発していく利幅だった。彼は追い詰められて、脱出方法を考えなければならなかった。でも彼の持ちえたものは、エンジニア達とコンピュータの群れだった。そこからどうにかマネタイズするには…？。結果論だけれど、そうして彼は AWS にたどり着いたわけだ。
Microsoft はプラットフォームとして始まった。だから彼らにはたくさんの習慣があった。
でも、 Facebook は…、彼らは僕を不安にさせる。僕はエキスパートではないけれど、でも、彼らは最初プロダクトとしてスタートして、そしてそれをうまく成功につなげていたことは確かだ。だから、彼らがどうやってプラットフォームへと変革を遂げたのか、僕にはわからない。それは比較的昔のことだったろうと思う。 Mafia Wars のようなものが現れる前に、彼らがプラットフォームにならなければならなかった時よりもずっと昔。
たぶん彼らは僕らを見て、こう自問したのかも知れない。「どうやったら Google を倒せる？。 Google に足りないものはなんだ？」
僕らが直面している問題はとても大きい。僕らがキャッチアップを始めるには、めざましい文化的な改革が必要だ。僕らは内部的にもサービス指向なプラットフォームを持っていないし、同じように外部的にもそうだ。この「自分のものにしていない」感じは、まさに会社全体を覆う風土病だ。 PM は分かってない。エンジニアも分かってない。プロダクトチームも分かってない。誰も分かっていない。たとえ一個人で分かっている人間がいたとしても、もしそれが君だとしても、僕らがそれを総力を挙げて緊急事態として扱わなければ、これっぽっちも意味が無いんだ。僕らはプロダクトをローンチして、それを後から魔法のように美しい外部拡張可能なプラットフォームに成長させられる、そんなふりをし続けることを、やめなければならない。何度もやって、だめだったじゃないか。
プラットフォームの黄金律「自分のドッグフードを食べろ」はこう言い換えることができる。「プラットフォームから始めろ。そしてそれをなんにでも使え」（訳注："アドバイス" thx ！）。後からちゃんとやるなんて不可能だ。少なくとも、簡単には無理だ。 MS Office をプラットフォーム化した人たちに尋ねてみればいい。あるいは Amazon をプラットフォーム化する為に努力した人たちに。遅れてしまえば、正しく立て直すのに10倍の苦労が必要になるだろう。ごまかしはできない。内部アプリが特別な優先アクセスを受けられるようなバックドアを秘密に仕込むなんて、どんな理由があっても不可能だ。難しい問題から、まず最初に解決しなければならないんだ。
僕は遅すぎると言いたいわけじゃ無い。けれど、待てば待つほど、致命的な遅れへとどんどん近づいてゆく。
この記事をどう纏めて終えればいいか、正直よくわからない。言うべきことは全て言ったと思う。この記事はできあがるのに6年かかっていると言える。僕が紳士的ではなくて申し訳ないと思う。プロダクトやチーム、個人を僕が誤解していたら申し訳ないと思う。もし僕らがたくさんのプラットフォームを実は作っていて、僕や、僕が話した人たちみんなが偶然知らないだけだったとしたら、申し訳ないと思う。
でも、僕らは今すぐに始めないとならない。
この努力は僕が Google に来る為に Amazonを離れた2005年半ばも続いていた。でももっとずっと進化していたよ。 Bezos が命令を出してから僕が離れるまでの間に、 Amazon は全てにおいてまず最初にサービスを考える企業へと文化的に変化していった。外部の日の目を決して見ることの無いような、スタッフへの内部的なデザインも含めて、今ではそれがデザインというもの全てに対しての基本的なアプローチになっている。
その時点では、彼らはもはや解雇の恐怖からそうしているわけではなかった。つまり、もちろんビビってはいたけれど、ドレッドヘアの海賊 Bezos 様にご奉仕するのは日常生活の一部だからね。そうじゃなく、彼らはそれが正しいことだと理解したから、サービスを提供しているんだ。確かに SOA のアプローチには長所も短所もあるし、短所を書き出してみたら切りが無い。でも全体として、 SOA ドリブンのデザインというものこそが、プラットフォームを可能にする、これは正しいことだ。
これが、 Bezos が彼の指令書で企んだことだった。彼はチームの健康状態なんて興味もなかったし（今もそうかも）、使われている技術もそうだったし、結局の処のどう取りかかるかなんて結果ができあがるまで気にもしていなかった。けれど Bezos は、 Amazon 社員の大多数が理解する前に、 Amazon はプラットフォームにならなければならないということを悟っていたんだ。
だって考えてもみてよ。なんで一オンライン書店が、拡張可能な、プログラマブルなプラットフォームになる必要がある、なんてことを考える？。そうだろ？
ともかく、 Bezos が気づいた最初の大きなポイントは、本を売り、出荷し、色々とやる仕組みが、素晴らしいコンピューティングプラットフォームに再利用でき得るということだ。だから今、彼らには Amazon Elastic Compute Cloud があるし、 Amazon Elastic MapReduce があるし、 Amazon Relational Database Service があるし、その他たくさんの aws.amazon.com で見つけられるサービスを持っている。しかもこれらのサービスは大成功した企業のバックエンドを努めていたりもする。 reddit なんか僕のお気に入りだね。
もう一つ、彼が理解した大きなポイントは、常にいつでも正しい、そんなものを作ることはできないということだ。これは Larry Tesler が、ママはこのくそったれサイトを全く使えないよと言ってのけたりでもした時に、 Bezos にピンと来るものがあったんだと思う。誰のママのことを言ったのかははっきりしないし、そんなことは問題じゃ無い。問題は、誰のママだろうとそのウンコサイトを使えないってことだ（訳注：アドバイス thx ！）。実際、僕自身、そこで5年ほど働いていたわけだけど、あのサイトは胸がザワザワするくらいひどいと思う。でも僕はその気が散るようなサイトに慣れてしまって、トップページのど真ん中あたりの数万ピクセルに集中できるようになったんだからね。
とまあ、実際の処 Bezos がどうやってその理解、一つのプロダクトで、全ての人にとってふさわしいものを作り上げることはできないということに、たどり着いたのかは定かじゃあ無い。でもその方法は問題じゃ無くて、彼は理解してるってことが重要だ。実のところこの現象には正式な名前だってある。そう、それはアクセシビリティと呼ばれるものだ。コンピューティングの世界で最も重要なものだ。
君は思うかも知れないね。「はあ？つまりそれって、目が見えない人や耳が聞こえない人のあれ？あのアクセシビリティ？」ってね。まあ君だけじゃないと思う。とにかく世間には、アクセシビリティってものを正しく理解していない、君みたいな人たちがいっぱいいっぱいいるんだから。ただそこにたどり着いてない人たちがね。だから、アクセシビリティを理解していないのは、目の見えない人や耳の聞こえない人や手足が不自由な人やその他障碍のある人の責任じゃないように、君の責任じゃない。ソフトウェアが（この場合アイデアウェアといった方が正しいかもしれない）何らかの理由で誰かにとってアクセシブルでないというとき、それはソフトウェア自身の、あるいはアイデアの伝え方そのものに責任があるんだ。それがアクセシビリティの失敗というやつなんだ。
人生における重要なその他もろもろと一緒でさ、アクセシビリティには邪悪な双子がついている。小さいときにパパとママの偏った愛情で見捨てられて、今や同じくらいの力を持つまでに育った宿敵って奴がね（もちろんアクセシビリティには宿敵はたくさんいる）。それはセキュリティだ。一体全体こいつらが仲良くやっていること何てあるかい？
でも、僕は主張したい。アクセシビリティは実際の処セキュリティより重要だということを。だって、アクセシビリティを0にダイアルするってことは、何のプロダクトも持たないってことさ。セキュリティを0にダイアルしたって、そこそこのプロダクトを持つことはできるだろう？ Playstation Network みたいにさ。
まあつまりですね、僕はみんなが分かってくれないんだったら一冊丸々この話題で本を書くことだってできるよ。分厚くて、僕が働いてた会社のありんことピコピコハンマーのエピソードで一杯の面白いやつをね。でも僕がこの話を公開しなかったら、みんなが目にすることも無いだろう。そろそろまとめに入らなきゃ。
Google がうまくやれていない最後の一つは、プラットフォームだ。僕らはプラットフォームを理解していない。僕らはプラットフォームを自分のものにしていない。みんなの中にできている人はいるだろう。でも、そんな君はマイノリティだ。辛いことだけれど、これはこの6年で僕にはっきりと感じられた。僕は競争相手のプレッシャー、 Microsoft や Amazon や最近じゃ Facebook なんかが、僕らを一斉に目覚めさせて、ユニバーサルにサービスを始めるのを期待したりもした。アドホックな、中途半端なやり方じゃなくて、多かれ少なかれ Amazon がやったようにだ。一度に全てを。マジで。偽りなしに。今その瞬間から最優先事項として扱うというように。
でも、そうはなっていない。10番やら11番めくらいのプライオリティだね。いや15番かも？。知らないけど、とにかく低い。真剣に取り組んでいるチームもいくつかあるけど、多くのチームは考えてもいない。一度もだ。ごく一部の人々がちょっとした規模でやっているだけだ。
多くのチームに、彼らのデータと処理に対してプログラマティックにアクセスできるような、ちょっとしたサービスを提供させるのだって大変だ。彼らのほとんどは、俺達はプロダクトを作っているんだ、って思っているからね。そんでもってそのちょっとしたサービスなんてのはみじめなもんさ。 Amazon の教訓に戻ってリストを見てくれよ。そんで今すぐ使えるサービスを持ってきて見てくれ。僕が知る限りでは、そんなものはない。小ビンってのは便利かもしれないけどさ、そんなの車がいる時だけだろ？（訳注：この人、 Stubby という小瓶のビールと、 stubby という「ちょっとした・不格好な」という形容詞をひっかけてしゃべってます）
プラットフォームが無ければ、プロダクトなんて使い物にならない。いやもっと正確に言うならば、プラットフォームの無いプロダクトは、いずれ同等の機能を持ったプラットフォーム化されたプロダクトに、取って代わられる。
Google+ ってのはまったくまさに、エグゼクティブリーダーシップのとても高いレベルから（やあ Larry 、 Sergey 、 Eric 、 Vic 、やあやあ）枝葉の使いっ走りまで（やあ、君だよ）、全くプラットフォームを理解していないっていう良い例だ。そう、僕らはみんな、全く理解できていない。プラットフォームの黄金律ってのは、自分のドッグフードを食えってことだ。 Google+ プラットフォームってのは惨めなまでに後知恵だ。ローンチ時には一つたりとも API が無かった。そんで最後にチェックしたときには、僕らが提供してたのはわずかばかりのほんのちっぽけな API さ。ローンチの時、あるチームのメンバーが行進してきて僕にそれを説明してくれた。だから僕は訊いたんだ「でさ、これはストーカー用 API？」って。彼女はむすっとして、「ええ」ってだけ言った。いやジョークなんだよ…いや…ジョークじゃ無いんだ…僕らが提供する唯一の API は、誰かのストリームを読み出すだけ…。うーん、僕が間違ってたのか？
Microsoft はこの20年間ドッグフードルールで知られてる。この時代の彼らにとっての文化の一つなのさ。デベロッパにドッグフードを食わせて、僕らだけ人間のご飯を食べようってわけにはいかない。それは単に短期の成功のために長期のプラットフォーム価値を損なう行為だ。プラットフォームってのはまったく長期的な視点が必要なんだよ。
Google+ は脊髄反射の代物さ。 Facebook が成功したのは、彼らがすばらしいプロダクトを作ったからだって言う、まあ実に近視眼的なものの見方の結果として生まれたものだ。でももちろん彼らが成功したのはそんな理由じゃ無い。 Facebook は他の人たちにも何かをさせてあげられる、プロダクトの美しい集合全体を作り上げたから、成功したんだ。だから Facebook はみんなにとってそれぞれ違うものだ。 Mafia Wars に全ての時間を費やす人もいれば、 Farmville で遊ぶ人もいる。何百の、いや何千の、質の高い、暇つぶしができるってわけさ。つまり、みんなのためにふさわしい何かが必ずあるんだよ。
僕らの Google+ チームは、プロダクトを出した後のマーケットを見てこう思った。「おっとっと、我々もいくつかゲームが必要みたいだな。さっそくどこかと契約して、我々のために作ってもらおう」。これが信じられないくらい間違った考え方だってことが、君にもわかってきたかい？。問題なのは、僕らが、人々がほしい物を予測して、それを提供しようとしているということだ。
そんなことは出来ないんだよ。現実的にはね。確実にやる方法なんてない。もちろんコンピューティングの歴史全体を見渡せば、それを確実に信頼性を持ってできる人間ってのがごく数人いることにはいる。 Steve Jobs がそうだろう。でも、僕らの処には Steve Jobs はいない。悪いけど、いないんだよ。
Larry Tesler は、 Bezos が Steve Jobs じゃないってことを口説いたかもしれない。でも Bezos には分かっていた。全ての人にふさわしいプロダクトを提供する為に、彼が Steve Jobs になる必要はないっていうことを。インターフェースとワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティの開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。
僕の言っていることが、あまりにも明白なことだろって感じているみんな（多かったらいいな）には申し訳ない。とにかくもうびっくりするほど自明なことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。
6 Reasons We're In Another 'Book-Burning' Period in History | Cracked.com
By: S Peter Davis
これを聞いた人の8割は私の顔を殴りたくなるだろうが、端的に言おう。
稀覯本を含む本を数万冊以上捨ててきた。
焚書と聞いて、一般にはおそらくナチスドイツを連想する人が多いんじゃないだろうか。
それは不寛容と反知性の象徴だ。
だが今回の焚書は違う理由で起こっている。
本を捨てているのは、利用者が誰もいないような辺鄙な田舎の図書館だけじゃない。
おそらく世界最高の権威がある図書館、大英図書館でも、本の廃棄が産業的な規模で行われている。
オーストラリアのニュー・サウス・ウェールズ大学やそのほかいくつかの大学では最近、本の処分に関するスキャンダルが起きた。
今年ボーダーズという書店がつぶれたときには、在庫は寄付されるのではなく廃棄された。
捨てられているのは、『TVガイド』とか重複所蔵の本だけじゃない。
17世紀に美麗に印刷されたシェイクスピアの作品集を想像してみてほしい。
奥付のページには、遠い昔に亡くなった所有者からの達筆なメッセージが付いている。
それをゴミ箱に捨てるのだ。
私は何度もその場にいた。
持ち帰ってeBayに出して売って、何百ドルかにはなったんじゃないだろうか。
これはオバマの共産ナチ新世界秩序に操られたソビエトの秘密作戦か何かではない。
血も涙もない官僚主義によって起こっているのだ。
というのも……
誰しも思うのは、恵まれない人たちに寄付すればいいんじゃないの、ということだ。
囚人でも、病気の子供でも、独立系の新興書店でもいい。寄付すればタダじゃないの、と。
蔵書であることが分かるようになっている。
その本を寄付したり売ったりするときには、印を消さなければならない。
盗品でないと分かるようにするためだ。
そればかりか、所蔵印が残っている本は、親切な人が見つけて図書館に返しに来てくれちゃったりもする。
そして、処理すべき本はとても多い。
図書館はやっきになって蔵書を減らそうとしている。
図書館館長になったつもりで、10万冊を処分しなればならないという報告を受けたと考えてみてほしい。
選択肢は二つ。
学者を何十人か雇って蔵書目録をもとに重要度や価値を評価させて、
また何十人かを雇って重要度の低い10万冊に一冊一冊処分の印を押させる、
というのがひとつ。
第二の選択肢は、コンピュータで貸出回数の少ない10万冊を列挙して、
数人に館内を回って集めさせて、シュレッダーにかけさせること。
第二の選択肢のほうがずっと速くて安いことはお分かりだろう。
そうなれば儲けがでることもある。
ことに司書にとっては、それはまるで、
ゾンビに噛まれた親友を前にして、自分だけが銃を持っているようなものだ。
それに、捨てられた本のなかに救われるべき本が埋もれてしまうことも忘れてはならない。
このやり方では明らかに、ものすごく貴重な本が引っかかってしまうことがある。
2011年版が書架にあるのに、『白鯨』の初版本を書庫から借りようとする人がいるだろうか。
コンピュータで出した貸出数ランキングではそうした区別ができない。
また、このやり方をする場合は、本は完全に破壊しなければならない。
ただゴミ箱に放り込むだけでは不十分だ。
盗られるかもしれないからだ。
誰も読もうとしないように本を引き裂くか、ゴミ箱に漂白剤を入れておく必要がある。
とにかく、ゴミ箱が「ご自由にお取りください」状態になってはまずい。
そして作業をする図書館員が16世紀の貴重書を見つけたとしても、
館長はそれを救えとは言えない。
捨てる代わりに調べるように命じていることになりかねないからだ。
どんな本か分からなければ捨てるのも楽になる。
みなさんがこの事実をご存じなかったとすれば、
ほとんどの場合、一般人が気づくのはゴミ箱に大量の本が入っているのを誰かが目撃してからのことだ。
とはいえ司書がこっそり話し合っている掲示板はいくらか見受けられるが。
2004年ごろ、ニュージーランドのビクトリア大学は13万冊の本を廃棄することを決めた。
計画では、廃棄対象の本に赤いテープを貼り、
それを救いたい人がペンでチェックマークを付けることになっていた。
ご想像のとおり、誰もが怒りをあらわにした。
ある教授は図書館を「野蛮人」と呼んで学内に電子メールを回し、
図書館をめぐりすべてのテープ付きの本にチェックを入れるよう、
職員と学生に呼びかけた。
私の場合は、本の廃棄に気づいたのはそれを盗んで逮捕された人だけだ。
一般人が気づくころには、すべて終わっていて、反乱の機会はなかった。
それに図書館は気づかせることのないよう巧妙な言い回しを使う。
たくさんの書架を空にして、本を書庫に送ったというとき、彼らは嘘をついているわけではない。
ただ、書庫はすでにいっぱいで、新しい書庫行きの本の分だけ廃棄をしているということを言わないだけだ。
本の廃棄を推進する人たちは、図書館の機能を「本の博物館」だとする見方に反対する。
みなさんは愛すべき古典文学の書架に代表されるたくさんの書架の集合こそが図書館だとお思いかもしれない。
通貨が少し下がったり上がったりすれば、外国雑誌の価格も少し変わるだろう。
さてここで、購読するのは数冊ではなく10万冊だと考えてみてほしい。
そして、いま降りかかっているのは小さな変動ではなく、大恐慌時代以来の最悪の不況だ、と。
これは一夜にして旅客機一台分が財布から飛んでいくことを意味する。
その旅客機の代金が払えないと、まずいことになる。
そうなったらとりうる手段は、燃え盛る蜂の巣を手放すように、
購読を打ちきることしかない……とお思いだろうか？
ところがそれは図書館のパワーユーザー、学者と学生が毎日必要とするものなのだ。
必要のないもの、それはたとえば、手書き挿絵の入ったネクロノミコンだ。
どれほどかけがえのない所蔵物であろうと、とにかく場所がないのだ。
というのも……
図書館が蔵書を引き裂く必要がある理由のひとつは、この不況だ。
悲しいことだが、それはそれで仕方ない。
コーヒーショップと引きかえに土塊にされているとしたらどうだろうか？
オーストラリアのニューサウスウェールズ大学でまさにそれが起こっている。
その図書館では、社交的空間を作るため、1850年代からの蔵書と新聞雑誌が廃棄された。
ピーター・スレツァク教授はそれを、図書館を「スターバックスのようなもの」に変えるものだと評している。
しかし、図書館の立場にたってみれば、それを要求しているのは、
彼らは本を保管することだけではなく、本を使う場所を図書館に求めているのである。
そして出版社は無数の本を出してくる。
ということで、図書館は、一方では新刊書を所蔵するために拡張を迫られ、
一方ではカプチーノを飲んで腰を下ろす場所を作れと言われているのだ。
問題は、その費用を誰も出してくれないということだ。
この報告書でも分かるように、図書館へお金を出している組織は予算増額をものすごくいやがる。
図書館が「拡張の資金が必要」と言えば、大学当局は「他を当たってくれ」と言うだろう。
ほとんどの図書館に他の当てはない（建物に放火して保険金をせしめるという手を勘定にいれなければ）。
本はもはや流行らない。このことは認めざるをえないだろう。
2010年最後の三カ月のAmazonの売上データで、電子書籍は紙の書籍を上回りはじめた。
最近のハードディスクであれば、場所をとらずに事実上無限の数の本を入れることができる。
小さめの図書館ならUSBメモリ一つでで置き換えられるとしたら、
巨大な防火設備で本を守り続けさせる原動力は、人々の愛しかない。
現在の経済状況下では、その愛はなかなか発揮されることがない。
この動きは三十年前に遡る。
1980年代、図書館のスペース問題を解決したのは電子化ではなくマイクロフィルムと呼ばれる新技術だった。
本や新聞雑誌をスキャンしてマイクロフィルムとして保存すれば、
図書館ひとつがキャビネットひとつに収まるというのが謳い文句だった。
ニコルソン・ベイカーは、マイクロフィルムブームの悲痛な記録を本にした。
それによると、大英図書館、アメリカ議会図書館といった世界の名だたる図書館が、
数千冊の古い貴重書を引き裂いてスキャンし廃棄したそうだ。
世界中の本好きたちがこれに抗議したところ、司書がマイクロフィルムを掲げて
今日では、インターネットの普及によって、本の圧縮はますます推進されるばかりだ。
ある組織では廃棄する本の選定にあたって、グーグルブックスに載っているかどうかというシンプルな基準を用いているそうだ。
もちろん、本好きの心はそれだけでは慰められない。
彼らは本の内容だけではなく、本それ自体に価値があると信じている。
彼らにとっては、同じ版の本がほかの場所にあるからといって、
貴重な書物を捨てることは正当化できない。
道は事務書類で敷き詰められていて、
これが現実だ。
あるレイプ被害者の事で、何とも言えない気にさせられた事があるので。
その時は、ここに書いたような事を書いていたわけではありません。
何を言っても、言う方がものすごく悪いものにされてしまうかのような、何とも言えない罪悪感とか、まるで弱者の暴力だなと思いました。
その時は、違う事で精神的にまいっていて、違う事で聞く必要なある事があったので、ブログに質問しに行ったのですが
その人は私の事を人間だと思っていないかのような態度を取りました。それでも、それを厳しく指摘したりすると、こちらが傷ついた人にきつい事を言う鬼畜にされてしまう・・・という矛盾
弱者というポジションが取れたら、勝ちな世界があると思うけど、ああいうのはその際たるもので、女権拡張論者の垂涎の武器になるアイテムがレイプ被害者なんだなと思いました。
ああいうのを、何とかしないと、健全な社会参加がしたい女性性を持った人間の人の迷惑ではないかと思います。
こっちも絞めとくから、お前らも絞めろ！と自我が肥大化したような主張をする一部男性を一般男性に、止めるようにいう事もできないのではないかと思ってしまいます。
http://yomi.mobi/read.cgi/toki/toki_news4viptasu_1315333365/973-975 変な広告がうざいけど
ここに書いたような事を、スレ立てて、公表した場合、メリット・デメリット 考えても、親戚に働きかける事を考えても、その方が良いと思う。
今までは、証拠のなさや、色々勘案して、やめてたけど
今の状況を考えると・・・・・
公務員が叩きたいでも、公務員の潤沢な退職金でぬくぬくしてる人を叩きたい でも良いので ( 親や親戚はそういう人が多い )
973 名前： ◆XfjNhg8RkI mailto:sage [2011/09/28(水) 14:34:53.54 ID:tp4j/Mhr0]
まだ、スレありましたね。>>357です。そのせつは、どうも。
今度、呼びかけじゃなくて、「精神病院から逃げてｘｘ年で、住んでたアパートも立退きで違法に半壊にされ、避難状態なんだけど、なんか質問ある？」
というスレを立ち上げて、まずは、呼びかけじゃなくてコミュニケーションを取ってみようかなと思ってます。
驚かせてごめんね。
精神病院基礎知識 こんなとこ 院長逮捕で廃院になった所の儲けは、2年24億だそうです。
http://www.youtube.com/watch?v=ihkqaeDP7ys
頭がおかしくなくても・・・ http://blog.goo.ne.jp/publicult/m/200809 週刊spa!ある日突然[精神科に突然入院]
こういう事もあるってだけで、全部がそうだとは思いませんし、のんだ事はありませんが、統合失調症の陽性症状には薬は効果的らしいです。
こういう事ブログで書く人の中には、かなり過激に煽り立てる人もいます。ああいうのもちょっとなぁ、と思います。
974 名前： ◆XfjNhg8RkI mailto:sage [2011/09/28(水) 14:50:49.30 ID:tp4j/Mhr0]
まあ、記念カキコ的なアレなんで
アパートについては、こういう感じ http://sky.geocities.jp/oooquree/fax.html 画像は一番下
これは、知恵袋の質問の補助的な説明として作ったもので、前に作ったのには、病院関係のも載せてた。
いきなり色々盛り込みすぎると、見た人が混乱するかなと、質問に必要な部分だけをまとめた。
ここでは、精神病院の事も書いたから、こっちを載せてもいいんだけど http://sky.geocities.jp/nanami061106/
アパートからも避難を余儀なくされて、・・・←今ここ みたいな
これは、インパクトあるし、この事件が新聞ネタやワイドショーねたになったんなら、これも(アパート破壊)拡散できないかなと。それが助かる道かなと。
http://megalodon.jp/2011-0918-0731-21/www.chunichi.co.jp/s/article/2011091790102222.html
アパート破壊については、上のyahooのサイトには書いてなかったけど、警察も関係してる。
こんなかんじで、警察ヤバすｗ http://anond.hatelabo.jp/20110919111536
975 名前： ◆XfjNhg8RkI mailto:sage [2011/09/28(水) 15:15:39.05 ID:y0JMA0aF0
マコトくんは、vipでスレ立ててそこそこ話題になったらしく、まとめサイトにも出てるんだけどなぁ・・・
http://blog.livedoor.jp/insidears/archives/52097322.html
こういうのは、偏見的な言い方になってしまうかもしれないけど、やっぱり妄想的なものを持ってるのに気がつかない滑稽さなんかが、受けてるんだろうか？
前に、うつ病か何かで自分で(自分でと言っても親のお金らしかったけど)これから入院する、今までからんでくれてありがとう！というようなスレ立てて、普通に話してみんなに見送られて行った人もいたけどなぁ。
あ、あともう一つ、何で拡散と考えたかと言うと、異様な(異常と診断できるわけではないから)親の事で困らせられている人はいて、親から逃げてる人たちの情報交換のスレもあるから(被虐待者を叩きたい人も混じってるかもしれないけど)
http://alfalfalfa.com/archives/1494324.html 一人暮らしで親と絶縁
精神的な問題じゃなくて、実害がある。親に借金されたとかｗ そこまで行くと弁護士頼んだらしいけど。 ここで交換されてる逃げる生々しい知識は、本来なら要らない知識のはずで、こういうやり取りが為されているという事が、
逃げなくてはいけない困った親もいるという事実を浮かび上がらせていると思う。
親に対して、何か問題があると言う話になると、思ったよりネット上でも(ネットだからかもしれないが)否定されてる。 親のわかりにくい意味不明な虐待というのも証明しにくかったり、親教信者には攻撃対象にされがち
それに対しての証拠になる、という意味では、意味があるスレだと思う。でも、そこで交わされている情報は本来は意味が無く、本当は国や行政にも言うべき事で、社会問題として取り上げられるべきだと思う。
女の人は女権拡張の利権になるからか、手厚すぎる保護を受けさせられてしまう。そのノウハウをちょっと活かせばかなり保護できるだろうに、と思う。
シェルター入所や(シェルターも被害女性を隔離し監視し洗脳してるとかも言われてるけど) DV法の適用(ドメスティックバイオレンスなのに、親子間には適用されない)とか
昔ルポを書いたＡ日新聞元記者のサイトのメールフォームから、書き込んでも返事は来ないのに、Ｊ党市議のメールフォームからの書き込みには、メールで返信が来た！！
どーなってんの？！
ってかんじ
政治をやってる人と言うのは、利害の調整をして、自分にメリットがある所に肩入れする事で、その見返りや恩恵を受け、それをさらに還元したり、何だろうな、とにかく、それで味方とか自分の陣地とかを増やして、最終的には数で勝たないといけないわけだし、多数派に入ってないと何もできないわけだし・・・ ていうか、うまく説明できないけど、そのへんをごにょごにょして何とかやっている人たちなわけで
そのへんを勘案すると、自分の状態の人を救済しても、Ｊ党的には見返りは何にもないのではないかと思うので、何だか心苦しい気もする。
まだ、わからないけど、メールフォームから書き込みしても、あとは残らない。メールで返信すると、ヘッダー情報があるから、返信したというあとが残ってしまう。無視するつもりならわざわざ返さないのではないかと思う。
いつものように増田への投げ売り堂の9月の結果と雑感を書き込みます。今日は長めになりそうで。
| 項目名 | 9月 | 8月 | 増減 |
|---|---|---|---|
| ユニークユーザー | 1983 | 690 | +1293 |
| ページビュー | 8777 | 3086 | +5691 |
| 平均ページビュー | 1.60 | 1.89 | -0.29 |
| 平均滞在時間 | 2.59 | 1.33 | +1.26 |
| 新規訪問数 | 29.90% | 31.79％ | -1.89％ |
詳細はいつものように以下の Analytics の PDF に書いてあります。
ごらんのとおり、アクセス数とユーザー数が伸びていますが、それ関連で色々やったこと。
リリース後にすぐに載せたんですが、そこまで効力が無く・・・。一回沈んだらそのままな感じなので仕方ない感じでしょうか。
これが一番やり方としてはダメですが、一番伸びた大きい要因でした・・・。
12日以降に定期的に投げ売り堂の URL をそれなりに関係があるかもしれないところに張って・・・。
申し訳ないと思いつつ、手っ取り早く広める。というのは素人にはやっぱりこれが一番なのかなと再確認をした感じです。
そもそも手っ取り早くな事を考えているのが甘いんですが。
今月の10/26から適応される、Amazon Product Advertising APIの仕様変更
の対策を全くメールを見てなかったので失念していて、ItemPage をガッツリ使っているこちらとしては、このままでは存続自体が危ない感じなので対策をしました。
まずはフィギュアだけなんですが、ItemSearch の際に KeyWords を使って複数検索をかけるように変更しました。
・「1/4」などのスケール
・「PVC」などの素材
これによって、ItemPage が400→10件に減らされても品揃えは遜色ないように出来ました。
DVD・BDとゲームもあるんですが、もう少し工夫をして今と同等にしようと思います。
しかし今回の API 仕様変更は困る人が多いんだろうなぁ・・・。
この辺で詳しくは述べてますが、料金は抑えることが出来そうです。
今月はサービスに直結する対策を色々とやりました。
サービスの拡張はやれなかったですが、存続の危機になりかねない事だったので色々と勉強になって結果良かったなーと思っています。
はてなの増田のみなさんは、ここを観念的なやり取りの場と考えている使っている人が多いみたいなので、こういうのは珍しがられるかもしれませんが、私はもうちょっと直截的に使ってもいいんじゃないかなと思います。
相談に乗ってください
力になって下さい
みたいなのは、あまり歓迎されないかもしれませんが、それなりに人が見るところでは、２ｃｈよりいいかもしれないと思うので
２ｃｈでも訴えかけ方にもよるし、その時見ている人にもよるし、板にもよると思いますが
また２ｃｈでも呼びかけるかもしれません。
何かを叩くのが好きな人でも良いのです。うちの親や親戚には公務員が多いです。そういう人を叩きたい人でも結構です、と2chでは呼びかけるかも。
私は、親から長い事逃げて暮らしてきました。当たり前ですが経済的にも別です。居場所がわかったら、親はカギを交換し施錠して行きました。何といって良いのかうまい説明が見つかりません。カギを実際に換えたのは家主かもしれません。しかし部屋に帰ったらドアに「カギをとりかえましたので・・」という貼り紙がしてあり両親の名前と携帯番号が書かれて連絡下さい、としてありました。父親の直筆でした。
詳しくは、ここにあります。 http://sky.geocities.jp/oooquree/fax.html
そこだと下の方になっているので、事情の概要がわかるネット相談の行政書士のメールコピペを貼ります。以下コピペ
ご相談者 様
まず鍵を親立会いのもとで交換した場合は、ご相談者様が未成年の場合、親に監督する義務があるので損害賠償請求は難しいでしょう。
次にご相談者様が成年の場合、賃借人に賃料滞納等の債務不履行がない場合、勝手に鍵を交換することは器物損壊罪にも問われますし、そのことが原因で部屋に入れず、ホテル等に泊まって宿泊費などを払った場合は、その費用を損害賠償請求できます。
建物譲渡により所有者（家主）が変わった場合は、賃借人に対する義務は新家主が引き継ぎます。（敷金等は新家主から返還してもらうことになります。
次に家主が賃貸借契約を更新をせず契約解除を求める場合、期間満了の６ヶ月〜１年前に通知をしなければなりません。
しかも契約解除を求めるには「正当事由」といって、家主側に解除を求めるしかるべき理由がなければなりません。（賃借人に重大な債務不履行のない限り裁判所は認めません。）
家主に大した理由もなく、どうしても賃借人に明渡してもらいたい場合には、明渡し料を支払って明渡してもらう場合もあります。
何れにしろ「借地借家法」は賃借人を保護する法律ですからご相談者様に債務不履行がなければそこにいればよいのです。
あまり今の家主の行いが目に余る場合は警察に被害届を出したら如何でしょう？（受理するかは被害の程度にもよりますが・・・）
以上でお役に立つかどうか分かりませんが、ご返事とさせて頂きます。
> 鍵を無断で大家と親が勝手に交換してしまった場合、両方ともに損害賠償請求出来るのでしょうか？
> 元の大家さんが亡くなられて相続した息子さんが、賃借人付きで有限会社の不動産屋にアパートを売却し、その不動産屋は他の部屋の人たちは荷物置きに使ってたからもあるだろうけど、みな無料で追い出しました。
> 残った私には、書くと長くなりますが、今までにも色々やって来ました。
> 住んでいる状態で自分の部屋と下の部屋以外ギリギリまで壊されている状態です。解除通知出さない状態でここまでされました。
> 倉庫に使ってたパン屋さんも、話が通じない昔の地上げ屋のような人だと言って出て行きました。
> 私は退去を求めるなら、精神的に圧迫するような退去の求め方ではなく、解除通知を出して、借地借家法に基づいた交渉をして下さいと言って、こちらから調停を申し立てました。
> 壊された時点で取り下げましたが。
> 解除通知が出たのは壊して調停取り下げてしばらくしてからです。
> 弁護士司法書士行政書士ではなく不動産屋社長が自分で書いた内容証明でした。
> 退去を求める内容証明は、書式の本を見ても、お願いするという形の文章が普通ですが、強制力があるような書き方でしたし、○日までに連絡する事というような事も書いてありました。
>
> その時もその社長は「キッチリした話し合い」がしたいと言って中々渡そうとしませんでした。
>
> 親との関係は、親の虐待から逃げて長い間暮らして来たような状態で、親を呼ぶと携帯電話で話してたので、親戚に来ないように言って欲しい、それとこの業者は住んでいる人がいる状態でアパートを壊すような人だからと伝えて欲しいと頼んだのですが。。。
>
まず、業者(転売目的現家主)から始まった、いろいろな問題一覧
時期的には、2種類の弁護士の間
法律を知らない現場警官の心無い言動で非常に傷ついた。親に電話をかけつつ、君が何を考えているかわからないと言ったり、内容証明に強制力があるかのように勘違いしていて、おそろしく法的に無知な奴もいた。( これは交番 ) ( こっちは警察署→ )家主との法的な場以外での面談を警官が応援するかのような発言や、強要する発言や、「この人も商売なんだから」「あんたは親兄弟でもそんな言い方するのか」などの発言 こちらは弁護士に言われてICレコーダーも買っていたので、家主とのやり取りは証拠として残さないといけないし、はっきりさせるところははっきりさせないといけないから、違法性をどれくらい自覚しているか、はっきりと確認できる形にした方がいいから、あえて挑発的とも取れるような言い方もしているかもしれない。 しかし、私はこの時、いろいろあったせいで丸2日くらいちゃんと睡眠をとってない状態で、しかもアパートに帰ったら、鍵が施錠されていた、これが怒らずに居られるか！！！！！ 名古屋の人はちょっとおかしいと思う。 店屋で物買うときでも、客側が遠慮している つづきはあとで
下級官吏ほど威張りたがるの法則というのが、あるなぁとおもっていたが、検察もご他聞に漏れず、そうだったｗ 検察官ではない。 いきなり来た人にほんとの検事が合うわけない。 検察事務員 事務官？ という国２くらいの人だと思う。
ここまで、2種の弁護士の間
こんな風に何の役にも立たないのに、言わなくていい人格否定みたいな事は言う。 電話で役に立たないアドバイスや、既にこちらが知っている知識などを言ってきて、それは無理でしたとか、難しいと思いますと言うと、怒ってきた人がいる。 だいたい声が綺麗な騙されてる感じの人が多かった(女の朝知恵的な)ように思ったが、夜中に電話した時、まだ若そうな声で嫌な感じの低音の人に「あなたは何でも正しい事を通そうとするから」とか言われ人格否定された。でもそのアドバイス実際役所に掛け合ってくれるならわからないでもないけど、言うだけ言いっぱなしでは、湯浅氏が前いた団体で言ったら、「福祉課、民生課というところがあるので、そこで生活保護の手続きして下さい」と案内だけして付き添い同行しないようなもんではないのか？ なんでこんなところを紹介しているのかわからない。公費を引っ張ってた事もあるし、その時も聞いてもいなかったのに、お金の出どころは言えません、前は内閣府でしたとか言ってきた。 ( お金のでどころと言われても何の事かわからなかったが、完全ボランティアではないという事なのだろうか？電話代など全国対応にしてるから膨大なのかもしれない。) 湯浅氏のいた団体にその女性団体にも属してる人がいるというので、電話をかわられて、そう言われた。
第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 まとめ
以下を全てGoogle Reader上で行いたい。
タイトルをクリックしたら自動的に全文を取得して表示して欲しい。以下の設定を行うと出来る。
ブコメが表示されないので、これを直したい。
id:northappleさんが「googleリーダー内ではてなブックマークのコメントを参照したいで.. - 人力検索はてな」という質問の回答及びコメント欄でこれを直す方法を教えてくれている。よって、その通りに変更すると直る。2ヶ所置換が必要。
以下、Google Reader plus Hatenaの変更点です。変更するには、Firefoxの右上にある猿（Greasemonkey）のアイコンの右にある下矢印をクリック→「ユーザスクリプトの管理」をクリック→「Google Reader plus Hatena」の「設定」をクリック→「このユーザスクリプトを編集します」をクリックするとエディタで「Google Reader plus Hatena」のスクリプトが表示されるのでそれを編集する。
62行目
mySpan.innerHTML = '<a href="http://b.hatena.ne.jp/entry/'+url+'" onClick="window.open(this.href,\'\',\'status=yes,scrollbars=yes,directories=yes,menubar=yes,resizable=yes,toolbar=yes\'); return false;" ><img src="'+ BookmarkImageURL +'" /></a>';
を、
mySpan.innerHTML = '<a href="http://b.hatena.ne.jp/my/add.confirm?url='+url+'"><img src="'+ BookmarkImageURL +'" /></a>';
に変更。これで「○○ users」をクリックすると、目的のウィンドウが開くようになる。
147行目
var t = bookmark.timestamp.split(" ")[0].split("/");
を、
var t = bookmark.timestamp;
に変更。
156行目、
html += "<li><span class=\"__hatena_bookmark_anywhere_timestamp\">"+escapeHTML(t[0])+"年"+escapeHTML(t[1])+"月"+escapeHTML(t[2])+"日</span><img src=\"http://www.hatena.ne.jp/users/"+escapeHTML(bookmark.user.substring(0,2))+"/"+bookmark.user+"/profile_s.gif\" width=\"16\" height=\"16\"><a href=\"http://b.hatena.ne.jp/"+escapeHTML(bookmark.user)+"/"+escapeHTML(t.join(""))+"\" class=\"hatena_bookmark_anywhere_user\">"+escapeHTML(bookmark.user)+"</a><span class=\"hatena_bookmark_anywhere_tags\">"+tags.join(", ")+"</span>"+escapeHTML(bookmark.comment)+"</li>";
を、
html += "<li><span class=\"__hatena_bookmark_anywhere_timestamp\">"+escapeHTML(t.slice(2,-3))+"</span><img src=\"http://www.hatena.ne.jp/users/"+escapeHTML(bookmark.user.substring(0,2))+"/"+bookmark.user+"/profile_s.gif\" width=\"16\" height=\"16\"><a href=\"http://b.hatena.ne.jp/"+escapeHTML(bookmark.user)+"/"+escapeHTML(t.split(" ")[0].split("/").join(""))+"#bookmark-"+escapeHTML(json.eid)+"\" class=\"hatena_bookmark_anywhere_user\">"+escapeHTML(bookmark.user)+"</a><span class=\"hatena_bookmark_anywhere_tags\">"+tags.join(", ")+"</span>"+escapeHTML(bookmark.comment)+"</li>";
に変更。
# ブコメのはてなスターを取得しやすいように、ブコメのリンクもブコメのパーマリンクへ変更してあります。
を、
var evt = document.createEvent( "MouseEvents" ); evt.initEvent( "click", false, true ); createSpan.dispatchEvent( evt );
に変更。（「 JavaScriptの動かないコード (中級編) clickイベントを強制的に発生させたい （fireEvent/createEventの使い方） - 主に言語とシステム開発に関して」を参考にさせて頂きました。）
出来た。けど、めちゃくちゃソースが汚いので、差分として公開するのが難しい。ごめんなさい。
第1章 有限オートマトン D.Perrin：橋口攻三郎 1. 序論 2. 有限オートマトンと認識可能集合 3. 有理表現 4. Kleeneの定理 5. 星の高さ 6. 星自由集合 7. 特殊なオートマトン 8. 数の認識可能集合 第2章 文脈自由言語 J.Berstel and L.Boasson：富田 悦次 1. 序論 2. 言語 2.1 記法と例 2.2 Hotz 群 2.3 曖昧性と超越性 3. 反復 3.1 反復補題 3.2 交換補題 3.3 退化 4. 非生成元の探求 4.1 準備 4.2 生成元 4.3 非生成元と代入 4.4 非生成元と決定性 4.5 主錐の共通部分 5. 文脈自由群 5.1 文脈自由群 5.2 Cayleyグラフ 5.3 終端 第3章 形式言語とべき級数 A.Salomaa：河原 康雄 1. 序論 2. 準備 3. 書換え系と文法 4. Post正準系 5. Markov系 6. 並列書換え系 7. 射と言語 8. 有理べき級数 9. 代数的べき級数 10. べき級数の応用 第4章 無限の対象上のオートマトン W.Thomas：山崎 秀記 序論 Ⅰ部 無限語上のオートマトン 記法 1. Buchiオートマトン 2. 合同関係と補集合演算 3. 列計算 4. 決定性とMcNaughtonの定理 5. 受理条件とBorelクラス 6. スター自由ω言語と時制論理 7. 文脈自由ω言語 Ⅱ部 無限木上のオートマトン 記法 8. 木オートマトン 9. 空問題と正則木 10. 補集合演算とゲームの決定性 11. 木の単項理論と決定問題 12. Rabin認識可能な集合の分類 12.1 制限された単項2階論理 12.2 Rabin木オートマトンにおける制限 12.3 不動点計算 第5章 グラフ書換え：代数的・論理的アプローチ B.Courcelle：會澤 邦夫 1. 序論 2. 論理言語とグラフの性質 2.1 単純有向グラフの類S 2.2 グラフの類D(A) 2.3 グラフの性質 2.4 1階のグラフの性質 2.5 単項2階のグラフの性質 2.6 2階のグラフの性質 2.7 定理 3. グラフ演算とグラフの表現 3.1 源点付きグラフ 3.2 源点付き超グラフ 3.3 超グラフ上の演算 3.4 超グラフの幅 3.5 導来演算 3.6 超辺置換 3.7 圏における書換え規則 3.8 超グラフ書換え規則 4. 超グラフの文脈自由集合 4.1 超辺置換文法 4.2 HR文法に伴う正規木文法 4.3 超グラフの等式集合 4.4 超グラフの文脈自由集合の性質 5. 超グラフの文脈自由集合の論理的性質 5.1 述語の帰納的集合 5.2 論理構造としての超グラフ 5.3 有限超グラフの可認識集合 6. 禁止小グラフで定義される有限グラフの集合 6.1 小グラフ包含 6.2 木幅と木分解 6.3 比較図 7. 計算量の問題 8. 無限超グラフ 8.1 無限超グラフ表現 8.2 無限超グラフの単項性質 8.3 超グラフにおける等式系 8.4 関手の初期不動点 8.5 超グラフにおける等式系の初期解 8.6 等式的超グラフの単項性質 第6章 書換え系 N.Dershowitz and J.-P.Jouannaud：稲垣 康善，直井 徹 1. 序論 2. 構文論 2.1 項 2.2 等式 2.3 書換え規則 2.4 決定手続き 2.5 書換え系の拡張 3. 意味論 3.1 代数 3.2 始代数 3.3 計算可能代数 4. Church-Rosser性 4.1 合流性 4.2 調和性 5. 停止性 5.1 簡約順序 5.2 単純化順序 5.3 経路順序 5.4 書換え系の組合せ 6. 充足可能性 6.1 構文論的単一化 6.2 意味論的単一化 6.3 ナローイング 7. 危険対 7.1 項書換え 7.2 直交書換え系 7.3 類書換え 7.4 順序付き書換え 7.5 既約な書換え系 8. 完備化 8.1 抽象完備化 8.2 公平性 8.3 完備化の拡張 8.4 順序付き書換え 8.5 機能的定理証明 8.6 1階述語論理の定理証明 9. 書換え概念の拡張 9.1 順序ソート書換え 9.2 条件付き書換え 9.3 優先度付き書換え 9.4 グラフ書換え 第7章 関数型プログラミングとラムダ計算 H.P.Barendregt：横内 寛文 1. 関数型計算モデル 2. ラムダ計算 2.1 変換 2.2 計算可能関数の表現 3. 意味論 3.1 操作的意味論：簡約と戦略 3.2 表示的意味論：ラムダモデル 4. 言語の拡張 4.1 デルタ規則 4.2 型 5. 組合せ子論理と実装手法 5.1 組合せ子論理 5.2 実装の問題 第8章 プログラミング言語における型理論 J.C.Mitchell：林 晋 1. 序論 1.1 概論 1.2 純粋および応用ラムダ計算 2. 関数の型をもつ型付きラムダ計算 2.1 型 2.2 項 2.3 証明系 2.4 意味論と健全性 2.5 再帰的関数論的モデル 2.6 領域理論的モデル 2.7 カルテシアン閉圏 2.8 Kripkeラムダモデル 3. 論理的関係 3.1 はじめに 3.2 作用的構造上の論理的関係 3.3 論理的部分関数と論理的同値関係 3.4 証明論的応用 3.5 表現独立性 3.6 論理的関係の変種 4. 多相型入門 4.1 引数としての型 4.2 可述的な多相的計算系 4.3 非可述的な多相型 4.4 データ抽象と存在型 4.5 型推論入門 4.6 型変数をもつλ→の型推論 4.7 多相的宣言の型推論 4.8 他の型概念 第9章 帰納的な関数型プログラム図式 B.Courcelle：深澤 良彰 1. 序論 2. 準備としての例 3. 基本的な定義 3.1 多ソート代数 3.2 帰納的な関数型プログラム図式 3.3 同値な図式 4. 離散的解釈における操作的意味論 4.1 部分関数と平板な半順序 4.2 離散的解釈 4.3 書換えによる評価 4.4 意味写像 4.5 計算規則 5. 連続的解釈における操作的意味論 5.1 連続代数としての解釈 5.2 有限の極大要素と停止した計算 6. 解釈のクラス 6.1 汎用の解釈 6.2 代表解釈 6.3 解釈の方程式的クラス 6.4 解釈の代数的クラス 7. 最小不動点意味論 7.1 最小で唯一の解を得る不動点理論 7.2 Scottの帰納原理 7.3 Kleeneの列と打切り帰納法 8. プログラム図式の変換 8.1 プログラム図式における同値性の推論 8.2 畳込み，展開，書換え 8.3 制限された畳込み展開 9. 研究の歴史，他の形式のプログラム図式，文献ガイド 9.1 流れ図 9.2 固定された条件をもつ一様な帰納的関数型プログラム図式 9.3 多様な帰納的関数型プログラム図式 9.4 代数的理論 9.5 プログラムの生成と検証に対する応用 第10章 論理プログラミング K.R.Apt：筧 捷彦 1. 序論 1.1 背景 1.2 論文の構成 2. 構文と証明論 2.1 1階言語 2.2 論理プログラム 2.3 代入 2.4 単一化子 2.5 計算過程―SLD溶融 2.6 例 2.7 SLD導出の特性 2.8 反駁手続き―SLD木 3. 意味論 3.1 1階論理の意味論 3.2 SLD溶融の安全性 3.3 Herbrand模型 3.4 直接帰結演算子 3.5 演算子とその不動点 3.6 最小Herbrand模型 3.7 SLD溶融の完全性 3.8 正解代入 3.9 SLD溶融の強安全性 3.10 手続き的解釈と宣言的解釈 4. 計算力 4.1 計算力と定義力 4.2 ULの枚挙可能性 4.3 帰納的関数 4.4 帰納的関数の計算力 4.5 TFの閉包順序数 5. 否定情報 5.1 非単調推論 5.2 閉世界仮説 5.3 失敗即否定規則 5.4 有限的失敗の特徴付け 5.5 プログラムの完備化 5.6 完備化の模型 5.7 失敗即否定規則の安全性 5.8 失敗即否定規則の完全性 5.9 等号公理と恒等 5.10 まとめ 6. 一般目標 6.1 SLDNF-溶融 6.2 SLDNF-導出の安全性 6.3 はまり 6.4 SLDNF-溶融の限定的な完全性 6.5 許容性 7. 層状プログラム 7.1 準備 7.2 層別 7.3 非単調演算子とその不動点 7.4 層状プログラムの意味論 7.5 完全模型意味論 8. 関連事項 8.1 一般プログラム 8.2 他の方法 8.3 演繹的データベース 8.4 PROLOG 8.5 論理プログラミングと関数プログラミングの統合 8.6 人工知能への応用 第11章 表示的意味論 P.D.Mosses：山田 眞市 1. 序論 2. 構文論 2.1 具象構文論 2.2 抽象構文 2.3 文脈依存構文 3. 意味論 3.1 表示的意味論 3.2 意味関数 3.3 記法の慣例 4. 領域 4.1 領域の構造 4.2 領域の記法 4.3 記法上の約束事 5. 意味の記述法 5.1 リテラル 5.2 式 5.3 定数宣言 5.4 関数の抽象 5.5 変数宣言 5.6 文 5.7 手続き抽象 5.8 プログラム 5.9 非決定性 5.10 並行性 6. 文献ノート 6.1 発展 6.2 解説 6.3 変形 第12章 意味領域 C.A.Gunter and D.S.Scott：山田 眞市 1. 序論 2. 関数の帰納的定義 2.1 cpoと不動点定理 2.2 不動点定理の応用 2.3 一様性 3. エフェクティブに表現した領域 3.1 正規部分posetと射影 3.2 エフェクティブに表現した領域 4. 作用素と関数 4.1 積 4.2 Churchのラムダ記法 4.3 破砕積 4.4 和と引上げ 4.5 同形と閉包性 5. べき領域 5.1 直観的説明 5.2 形式的定義 5.3 普遍性と閉包性 6. 双有限領域 6.1 Poltkin順序 6.2 閉包性 7. 領域の帰納的定義 7.1 閉包を使う領域方程式の解法 7.2 無型ラムダ記法のモデル 7.3 射影を使う領域方程式の解法 7.4 双有限領域上の作用素の表現 第13章 代数的仕様 M.Wirsing：稲垣 康善，坂部 俊樹 1. 序論 2. 抽象データ型 2.1 シグニチャと項 2.2 代数と計算構造 2.3 抽象データ型 2.4 抽象データ型の計算可能性 3. 代数的仕様 3.1 論理式と理論 3.2 代数的仕様とその意味論 3.3 他の意味論的理解 4. 単純仕様 4.1 束と存在定理 4.2 単純仕様の表現能力 5. 隠蔽関数と構成子をもつ仕様 5.1 構文と意味論 5.2 束と存在定理 5.3 隠蔽記号と構成子をもつ仕様の表現能力 5.4 階層的仕様 6. 構造化仕様 6.1 構造化仕様の意味論 6.2 隠蔽関数のない構造化仕様 6.3 構成演算 6.4 拡張 6.5 観測的抽象化 6.6 構造化仕様の代数 7. パラメータ化仕様 7.1 型付きラムダ計算によるアプローチ 7.2 プッシュアウトアプローチ 8. 実現 8.1 詳細化による実現 8.2 他の実現概念 8.3 パラメータ化された構成子実現と抽象化子実現 8.4 実行可能仕様 9. 仕様記述言語 9.1 CLEAR 9.2 OBJ2 9.3 ASL 9.4 Larch 9.5 その他の仕様記述言語 第14章 プログラムの論理 D.Kozen and J.Tiuryn：西村 泰一，近藤 通朗 1. 序論 1.1 状態，入出力関係，軌跡 1.2 外的論理，内的論理 1.3 歴史ノート 2. 命題動的論理 2.1 基本的定義 2.2 PDLに対する演繹体系 2.3 基本的性質 2.4 有限モデル特性 2.5 演繹的完全性 2.6 PDLの充足可能性問題の計算量 2.7 PDLの変形種 3. 1階の動的論理 3.1 構文論 3.2 意味論 3.3 計算量 3.4 演繹体系 3.5 表現力 3.6 操作的vs.公理的意味論 3.7 他のプログラミング言語 4. 他のアプローチ 4.1 超準動的論理 4.2 アルゴリズム的論理 4.3 有効的定義の論理 4.4 時制論理 第15章 プログラム証明のための手法と論理 P.Cousot：細野 千春，富田 康治 1. 序論 1.1 Hoareの萌芽的な論文の解説 1.2 C.A.R.HoareによるHoare論理のその後の研究 1.3 プログラムに関する推論を行うための手法に関するC.A.R.Hoareによるその後の研究 1.4 Hoare論理の概観 1.5 要約 1.6 この概観を読むためのヒント 2. 論理的，集合論的，順序論的記法 3. プログラミング言語の構文論と意味論 3.1 構文論 3.2 操作的意味論 3.3 関係的意味論 4. 命令の部分正当性 5. Floyd-Naurの部分正当性証明手法とその同値な変形 5.1 Floyd-Naurの手法による部分正当性の証明の例 5.2 段階的なFloyd-Naurの部分正当性証明手法 5.3 合成的なFloyd-Naurの部分正当性証明手法 5.4 Floyd-Naurの部分正当性の段階的な証明と合成的な証明の同値性 5.5 Floyd-Naurの部分正当性証明手法の変形 6. ライブネスの証明手法 6.1 実行トレース 6.2 全正当性 6.3 整礎関係，整列集合，順序数 6.4 Floydの整礎集合法による停止性の証明 6.5 ライブネス 6.6 Floydの全正当性の証明手法からライブネスへの一般化 6.7 Burstallの全正当性証明手法とその一般化 7. Hoare論理 7.1 意味論的な観点から見たHoare論理 7.2 構文論的な観点から見たHoare論理 7.3 Hoare論理の意味論 7.4 構文論と意味論の間の関係：Hoare論理の健全性と完全性の問題 8. Hoare論理の補足 8.1 データ構造 8.2 手続き 8.3 未定義 8.4 別名と副作用 8.5 ブロック構造の局所変数 8.6 goto文 8.7 （副作用のある）関数と式 8.8 コルーチン 8.9 並行プログラム 8.10 全正当性 8.11 プログラム検証の例 8.12 プログラムに対して1階論理を拡張した他の論理 第16章 様相論理と時間論理 E.A.Emerson：志村 立矢 1. 序論 2. 時間論理の分類 2.1 命題論理 対 1階述語論理 2.2 大域的と合成的 2.3 分岐的 対 線形 2.4 時点と時区間 2.5 離散 対 連続 2.6 過去時制 対 未来時制 3. 線形時間論理の技術的基礎 3.1 タイムライン 3.2 命題線形時間論理 3.3 1階の線形時間論理 4. 分岐的時間論理の技術的基礎 4.1 樹状構造 4.2 命題分岐的時間論理 4.3 1階の分岐的時間論理 5. 並行計算：その基礎 5.1 非決定性と公平性による並列性のモデル化 5.2 並列計算の抽象モデル 5.3 並列計算の具体的なモデル 5.4 並列計算の枠組みと時間論理の結び付き 6. 理論的見地からの時間論理 6.1 表現可能性 6.2 命題時間論理の決定手続き 6.3 演繹体系 6.4 モデル性の判定 6.5 無限の対象の上のオートマトン 7. 時間論理のプログラムの検証への応用 7.1 並行プログラムの正当性に関する性質 7.2 並行プログラムの検証：証明論的方法 7.3 時間論理による仕様からの並行プログラムの機械合成 7.4 有限状態並行システムの自動検証 8. 計算機科学における他の様相論理と時間論理 8.1 古典様相論理 8.2 命題動的論理 8.3 確率論理 8.4 不動点論理 8.5 知識 第17章 関係データベース理論の構成要素 P.C.Kanellakis：鈴木 晋 1. 序論 1.1 動機と歴史 1.2 内容についての案内 2. 関係データモデル 2.1 関係代数と関係従属性 2.2 なぜ関係代数か 2.3 なぜ関係従属性か 2.4 超グラフとデータベーススキーマの構文について 2.5 論理とデータベースの意味について 3. 従属性とデータベーススキーマ設計 3.1 従属性の分類 3.2 データベーススキーマ設計 4. 問合わせデータベース論理プログラム 4.1 問合わせの分類 4.2 データベース論理プログラム 4.3 問合わせ言語と複合オブジェクトデータモデル 5. 議論：関係データベース理論のその他の話題 5.1 不完全情報の問題 5.2 データベース更新の問題 6. 結論 第18章 分散計算：モデルと手法 L.Lamport and N.Lynch：山下 雅史 1. 分散計算とは何か 2. 分散システムのモデル 2.1 メッセージ伝達モデル 2.2 それ以外のモデル 2.3 基礎的概念 3. 分散アルゴリズムの理解 3.1 挙動の集合としてのシステム 3.2 安全性と活性 3.3 システムの記述 3.4 主張に基づく理解 3.5 アルゴリズムの導出 3.6 仕様記述 4. 典型的な分散アルゴリズム 4.1 共有変数アルゴリズム 4.2 分散合意 4.3 ネットワークアルゴリズム 4.4 データベースにおける並行性制御 第19章 並行プロセスの操作的および代数的意味論 R.Milner：稲垣 康善，結縁 祥治 1. 序論 2. 基本言語 2.1 構文および記法 2.2 操作的意味論 2.3 導出木と遷移グラフ 2.4 ソート 2.5 フローグラフ 2.6 拡張言語 2.7 その他の動作式の構成 3. プロセスの強合同関係 3.1 議論 3.2 強双模倣関係 3.3 等式による強合同関係の性質 3.4 強合同関係における置換え可能性 3.5 強等価関係上での不動点の唯一性 4. プロセスの観測合同関係 4.1 観測等価性 4.2 双模倣関係 4.3 観測合同関係 4.4 プロセス等価性上での不動点の唯一性 4.5 等式規則の完全性 4.6 プロセスの等価性に対するその他の概念 5. 双模倣等価関係の解析 5.1 等価性の階層構造 5.2 階層構造の論理的特性化 6. 合流性をもつプロセス 6.1 決定性 6.2 合流性 6.3 合流性を保存する構成子 7. 関連する重要な文献
投げ売り堂で行っているGoogle App Engine の新料金体系 の対応についてのその2です。
Cron 処理を Backends の無料枠で対応できそうだったので、無料分で収まるように Cron で行っている処理を Backends でやるようにしました。
その結果、日額0.1～0.2ドルで月間で3～6ドル程度になりました。
なんとか、1000円以内に抑える事が出来、このままだとなんとか大きな課金になる事無く対応は出来そうです。
これに加え、新課金体系への移行についてに書いてあるとおり
新料金体系の適応が11/1 になったので、落ち着いて作業を行えるようになったのですが
現時点においてギリギリでやってる為、 Google App Engine のままだとなかなか拡張もやりにくい事もあります。
ですので、やはり通常のサーバーでも動かせるように移植のほうも進めます。
Java 以外で使い慣れている PHP を使って同じシステムを作成しようと思います。
全ての商品を1時間に1回商品情報の更新や、フィギュア・DVD・BD・ゲーム以外の商品情報も集めるようにし
Cookie で表示商品の種類のカスタマイズ等などを組み込もうかなと思います。
http://anond.hatelabo.jp/20110908093243を可能な限り段落を再現してエキサイト先生に翻訳して頂きました！
長い間、私は暗箱にいます。
私が箱の外部で聞いた誰かのコメントによれば、劇薬を含んでいる小さなボトルは、この箱に位置します。ボトルは完全に密閉されますが、ハンマーはボトルの近くに配置します。また、彼らは、ハンマーがある時に倒れるだろうと言いました。
いつになるかは「ある時間」です?私は知りません。このまさに瞬間に?あるいは遠い将来?恐らく、それは既に来ました(私はそれに関して考えたくありません)。誰もハンマーに影響することができません。独立事象として、それは、見込みで50%倒れるでしょう。見込みはちょうど50%です。ひょっとしたら、ボトルは壊されるかもしれないしあるいはだろう。自分に関して、死者、あるいは、生きている。
私は言わなければなりません、状況はどれくらい恐ろしいですか。
私は、猛烈な憤慨を持たないようにはすることができません。私の人生(私のための最も重要な問題)は、私から完全に離れており、単純な図、FIFTY PERCENTに単独で依存します!あまりに恐ろしい。
さらに、私は、それは完全に不合理であると思います(そして)。私は、ちょうど50%で見込みを維持する多くの方法で束縛されます。
視覚。箱は、任意の光から完全に保護されます。それは、ボトルと装置を見つけるおよび破壊することから私を回避するためにあります。完全な暗さ。私は完全な暗さにいます。したがって、今、私は、自分のアウトラインさえ見ることができません。恐らく、それは奇妙に思えます。暗さは私に私の体自体の存在について疑問を抱かせます。
聴覚の知覚。恐らく、私が上に言及した理由から、完全な遮音は使用されます。私は、私自身の音声さえ聞くことができません。私はメカニズムを知りません。まず第1に、私は、何も見ることができないとともに、どのようにそれを調査することができますか。したがって、これは恐らく推測だけです、私の鼓膜はこの箱の中の包囲の前に破損されました、あるいは、ある特別の資料は箱の壁に使用されます。
とにかく、光と音の保護であまりによい暗箱では、ちょうど用語が示すように、私の視覚的・聴覚の知覚は死んでいます。
あたかも一層の確認が必要かのように、私を極度に圧迫する巨大な疲労は私のための別の拘束物です。それらは努力から私を回避するために私にある種類の筋弛緩剤を与えたように見えます。私が同じ姿勢から変わることができないとともに、私の触覚はほとんど麻痺しています。
光はありません。音はありません。匂いと味は信頼性が低い。触覚は不調にあります。私は操り人形に似ています。すべての五感は私のコントロールが不足しています。あまりに残酷です。完全な拘束物。それらが睡眠薬を与えていた場合、私は望みます。私は、外傷のない苦悩にいると思います。私の生活(私の存在(自体))は完全に無視されます。そのような屈辱は私の正気を維持します。そのような屈辱だけができます。
自分の生および死をコントロールする権利は完全に奪われます。私はそのような状況を嫌います。私の生活の連続性の中核決定要素は完全に依存します、で、単独で、で、純粋な見込み。誰からでも完全に遠方に、意志があります。私は再びそれを嫌います。私はそれを嫌います!
なぜ私は、そのような箱で囲まれなければなりませんか。そのような途方もない箱では、なぜ私は、そのような完全な拘束物を備えた、生命不安および死にいなければなりませんか。
私は孤独です。私は、中身がなく、水平に感じていますか。すすり泣かないようにすることが困難です?番号私の孤独ははるかに深い。私は空間の海でいます。私は一人です。完全に孤独です。孤児として、私はこの無限の暗さに向けられました。私は絶対零度の中で震動しています。
この箱に展望はありません。暗さだけがここにあります。私はボトルとハンマーを感じることができません。私は壁、底および天井をまた感じることができません。それらはそこにあるに違いありません。しかし、私の五感がすべて奪われます。何もないように、私は感じます。それらのものがいくつかの意味を持っている一方。
正直に話して、私は、箱にいるかどうかそれほど分かりません。私は、私の姿が存在すると確信します。私は考えています。私は空想しています。それは証拠である、私の独自性を示すこと、呼ばれる、自我あるいは意識、あるいは心、固体です。しかし、独自性はありますか、本当に箱で囲まれる?それが別のスペースで浮かんでいることはありえますか。私はそのような疑問を除去することができません。
恐らく、私がここでであるものは、宇宙に結局浮かんでいるか、あるいはマリアナ海溝の底に横になっています。あるいは恐らくキラウエア火山の穴から下降して行くこと。
私には、箱(私を囲んで)がどのようにか知る方法がありません。私の感覚はすべて死んでいます。私は、ここに、箱の内部があるかどうか判断することができません。
私は、本当に生きているように、それに加えて、確かではありません。私には、そんな単純なものを確認する方法がありません。恐らく、50%の見込みは私を越えて既に通過しました。恐らく、私は既に死んでいます。私はまだ、恐らく生きています。浅くて、筋弛緩剤を注入された、呼吸する、弱い心臓の鼓動。あるいはそれらのすべての停止(単に去る肉大型丸薬)。
私は私自身の身体をコントロールする任意の能力を奪われます。誰が私の心が重大な活動を継続する身体に存在すると言うことができますか。五感は完全な暗さで毒されました。それらは感覚器として機能することができません。私は、真実を知る見込みがありません。恐らく、どんな推測も一人で作り上げられます。私を包む状況および自分の独自性は恐らくプログラムされた回転プレーのコンポーネントです。
私の存在に関して、私は振る舞いを決定することができません。私は、それを認めることを嫌います。しかし、私は変動の最中です。
私は、誰かが私を見つけることができたらと思います。私は、誰かが箱を開くことができ私がいかがか言うことができた、らと思い、私がどういう人か決めることができました。私の内側にそうするのに十分な力はありません。私ができるのは孤独の中で震動し続けることです。
もし神ならば、私は言うことができるでしょう「そこにさせる、軽い。」私は、それが不可能なことを知っています。しかし、私は、私がそのように言うことができたならばどれくらい素晴らしいだろうか思わざるをえません。
私自身の自由意志!それは、自分を取り巻くすべての変動を固定することができました!
同時に、切望は影を生産します。箱が開かれるなら、私は見つかり観察されましょう。その結果、私の姿は決定されるでしょう。実を言えば、私は決定を心配しているという事実から視線をそらすことができません。
一人で生きているか死んでいるかどうか判断することができませんが、私は死を恐れています。残念ながら、私は死者として決定します。私は受理することができません。まだ、私は感じることができません。私は特定の現象として死を想像することができません。恐らく、そのため、私は死を恐れています。
いいえ、それは私に制限されるべきではありません。高潔なキング。致命的な殺害者。規則的な人々。すべての同じ。恐らく、悪い疾病の年上の人々あるいは患者は、十分に真実の死に近いある想像を持つことができました。しかし、それでも、死の特定の経験を知ることができません。
結局、死は圧倒する重要性を備えた最終仕向地です。時間と意識は絶対的な不可逆性を持っています。死にはさらに変更することができない完全無欠さがあります。それが儀式の通過点あるいは顕著な印象的な出来事でも。
私自身、ここの私の心はそうです、そのときは消えられるだろう、どれ、私がいかがかが決定されます。それらが生ぬるい水(私はその中で温度を感じることができない)から奪う場合、私は、大気に身をさらさないようにはすることができません。
私はそのような不可逆変化を恐れています。それは死の決定に制限されていません。さらに、非常に心配しているので、私は生きていて決定されます。
自分の現在の存在は、無限のポイント上に立っている小さく小さな幻覚に似ています。それほど大きくない。それほど小さくない。それほど長くない。それほど短くない。拡張はありません。収縮はありません。ユニークな単一のポイントで立っていること。それは数学上正確です。私は、自分の同一性に関する混乱があるそのようなポイントでとどまるゴーストのようなものです。
ポイントは同時(ある位置で既存でない)に座標の飛行機ですべての位置で存在します。ある出来事が生じれば、その瞬間においては、それは、すべての地空(あたかも私の招待がバスから降りるかのように、出来事がその中で生じた)中の単一のポイントに私を集中させるでしょう。関係なしで。ポイントと私がものだったとしても。
幻覚(それはそのようなポイントでとどまった)は、等しい程度に対して、実際で霧のように消されているの可能性を持っています。
さて、私はすべての配当通過時間の中で既存です。そして、私はすべての自然を持っています。同時に、私は孤独からそれを受けています、私はすべての自然から離れています。私は、誰かが私を見つけることができることを望みます。同時に、私は非常に心配しています、私はどこにいてそれ、私はその瞬間にいかがでしょうか。
判例って、これのことかしらん？
東京高等裁判所第9刑事部昭和52年11月28日判決(東京高等裁判所（刑事）判決時報28巻11号142頁)
「そこで考察すると、公衆に著しく迷惑をかける暴力的不良行為等の防止に関する条例（昭和三七年一〇月一一日東京都条例第一〇三号）は、当初，街頭における犯罪を防止し、街頭を明るくきれいにするという理念のもとに立案されたものであるが、その後制定の過程で、必ずしも街頭における暴力犯罪に該当しない場合でも、いやしくも都民生活に直接迷惑や不安を与えるような、いわゆる小暴力事犯をすべて取締ることとし、もって都民生活の平穏を保持することを目的とし（同条例一条参照）、小暴力事犯の予防と取締り上の既存法令の不備を補うために制定されたものであるから、右条例制定の趣旨に鑑みれば、同条例五条一項にいう「婦女を著しくしゅう恥させ、または不安を覚えさせる卑わいな言動」とは、都民の善良な風俗環境を害し、法的安全の意識を脅かすような卑わいな言動であって、善良な性的通義観念に反するいわゆる猥褻な行為には達しないものがこれにあたると解すべきであって（なお、附言すると、軽犯罪法一条二〇号所定の、一般公衆にけん悪の情を催させる行為と対比すれば、本条例違反の罪は、特定の婦女を対象とするものであって、行為の悪性において罪質が右軽犯罪法違反の罪より重い点で、明確に区別される。
）、このような卑わいな言動に該当するかどうかは、健全な社会常識に基づいて、その言動自体のほか、対象となった婦女の年令、その際の周囲の状況等をも考慮して決定すべきものであるといわなければならない。」
千葉県の迷惑防止条例も、第1条を見る限り、東京都の条例とほぼ同趣旨らしいから、これは先例となりそうな気がする。
車中で寝ている顔写真を勝手に撮るのは、「都民の善良な風俗環境を害し、法的安全の意識を脅かす」可能性が全然無いかというと、そうでもない。
結局のところ問題は、「卑猥」っていう概念をどこまで拡張して良いか、っていうところに帰着しそうだなあ。
そして、僕は確信をもってこれはセーフと断言するのはちょいと憚るなあ。アウトだとも言いたくないんだけど。
web製作に関しては素人なので用語などわからぬことも多いのですがご容赦くださいませ。
最近スマートフォンを買いまして、android 2.3.3ちゃん可愛いなあペロペロという生活をしています。
＜!DOCTYPE html＞ ＜html lang="ja" xmlns:fb="http://www.facebook.com/2008/fbml"＞ ＜head＞＜title＞サイトタイトル＜/title＞＜/head＞ ＜body＞ ＜div id="fb-root"＞＜/div＞ ＜script src="http://connect.facebook.net/en_US/all.js"＞＜/script＞ ＜script＞ FB.init({appId : 'xxxxxx', status : true, cookie : true, xfbml : true }); ＜/script＞ ＜div style="border:1px red solid;"＞ ＜fb:comments href="example.com" num_posts="2" width="500"＞＜/fb:comments＞ ＜/div＞ ＜/body＞＜/html＞
こんな感じのコードをスマホのブラウザから表示すると、赤い枠がどんどん拡張していくのですが何故でしょう？
https://developers.facebook.com/docs/plugins/
ここにあるプラグインのうちいくつかはandroidブラウザでも正常に動き、
いくつかは縦にどんどん伸びていくし、いくつかは横にどんどん伸びていくみたいです。
このあたりの動作の影響なのか、スマホで閲覧ができないサイトが、一部ではクラッシュまでしてしまうサイトもあるようです。
あるサイトXでは横幅・縦幅がどんどん大きくなっていくので、
文章の入ったコンテナ部分がどこか遠くに行ってしまい読みようがないのです。
あるサイトYでは、FBその他のプラグインを大量に張っており、相性の問題もあるのか
私が検証した範囲では、
Opera mini：問題なし
でした。
これって私だけ？
覚えている限りの時間の流れの中から、世の中に存在するコンテンツを分けてみるテストです。
パソコンが外につながっていることが珍しかった時代。新大陸が見つかった状態。新し物好きかつパソコン好きが移民していった。パソコン通信くらいしか商売になっていなかった。作る人と使う人がイコールだった。何かをするにはコマンドを打つ必要があった。
最初は、学者さんの論文の発表やストックするのに使われていた。
イギリスのホストにつないでmozaicでなんて時代には、論文の延長のノリで研究室のメンバーの自己紹介ってのがあった。実は、実名うんぬんってのは、一番最初にやっていた。
ここで、実名を名乗るのかペンネームを名乗るのかの分かれ道。すでに実社会でしっかりと活動している人は、実名でやっていただろうし、ひとりで楽しむような趣味の人や背徳感がある人はペンネームやハンドルネームになったんだろう。
全国の日帰り温泉のまとめのような個人が足で調べた価値の高い情報が高い確率で存在した。
まめな人は自己紹介のついでに日記を書いていた。当時はコンテンツマネージメントシステムは一般に普及していなかったので、htmlを手打ちして、ftpコマンドで送信。量が増えると大変だった。メールをみるときはなんちゃらtermというソフトでコマンドを打ちながら見ていた。
デジカメが普及するまでは、写真を取り込んだりイラストを取り込んだりするのは、お金がかかることだった。まして、高価なグラフィックソフトなど夢のまた夢。デジカメが普及したあとは当たり前になった。
取り込むためには専用の拡張ボードが必要だった。カメラも高価だったし。2GBの壁があって、長い動画は編集できなかった。高画質な動画に仕上げるためには職人芸が必須だった。大容量の動画をあげるサーバーはほとんどなかった。
音楽を作る人は、midiの配布していた。有名な曲のコピーが多かったので、大人の事情でほとんど閉鎖。
無料のホームページとセットのような感じ普及。ホームページ自体散発的なもので、同じ趣味趣向の人たちで同盟とか組んでいたよね。
大量に生成されるコンテンツは個人の手を離れていった。新大陸はいくつかの勢力に分かれて群雄割拠の状態。広告枠として大きなお金が動くようになった。作る人と使う人が区別されるようになった。グラフィカルユーザーインターフェイス(GUI)が、あたりまえになり、コマンドを打つ必要はなくなった。
地図が見れるようになった。パソコンにインストールしていた時刻表やルート検索がwebになった。
コンテンツマネージメントシステムが無料開放された。htmlの作成もftpも必要なくなり、気持ちや感情の発露のみを文章や写真にすればよくなった。改行を大量に挿入してスクロールバーを有効にして、文章を読むためにマウスのホイールをまわして文章を読むときに指の動きを加えて、読んだ感を高める手法が流行る。
会員制の閉じたサービスが登場する。内容は日記、掲示板と基本は同じだが、個人が設定する必要はない。テクニカルな要素がなくなったので、気持ちや感情の発露のみを文章や写真にすればよくなった。携帯電話からコンテンツを作る文化の先駆者ともいえる。携帯しか使わないユーザー層があらわれる。
写真のアップロードも無制限になった。デジカメの画質が上がってもリサイズする必要もなくなった。
動画を受け止めてくれるサーバーも増えた。ブログやSNSのおまけ的存在だったが、Youtubeの登場で無差別級のサービスになった。カメラで撮影した時点で、パソコン用のファイルになっているのも参入障壁を下げた。
たとえば、全国の飲食店をすべて載せるとかそこに感想や評価を付けるようなサイト。個人が手弁当でまとめていた情報を商売にする会社があらわれた。
感情の発露がリアルタイムになる。「つぶやき」という概念が生まれた。新大陸を制覇しようとする勢力の攻勢が高まる。作る人と使う人に加えて踊らされる人が登場した。「更新されたよ」ボタンをクリックするだけで、ダラ見ができるコンテンツが優勢となる気配。
ゲームとかやることが多くなりすぎた。
発展期に登場した便利サービスの中で脱落するサービスがあらわれ始めた。
大きな掲示板のスレッドには、約1000個の書き込みがある。その中から文章を選んでコンテンツを作る手法。新聞の読者投書欄のように投書されたご意見の中から好きな意見を載せることができる。文章ロンダリングやソースロンダリングという言葉が生まれた。
コンテンツの提供形式として、素人作成風味の味付けをする企業・組織があらわれた。個人が大きくなったのかもしれないし、何者かに組織されたのかもしれない。この手の人たちは頼んでもいないのにどんどんコンテンツを作る。
midiサイトに対する警告に比べると2次元コンテンツはゆるい。コンテンツホルダーの手が回らないくらいにあふれいるのか、あえてあふれさせているのかはわからない。黎明期ならばまつりになっているような内容のものがあふれいる。包括的に権利処理されているのかもしれない。
趣味じゃなくて仕事の人が増えたのだろうか。仕事でwebに出るといっても会社の看板を背負うと個人ではなかなか発言できないはずなんだけど。よくわからない。
だったら、どう違うか相対的な整合性を仮定しなきゃ
まったく意味がないよな。
個人的な経験則は無効だぞ。
まあ本格的なバカみたいだから簡単に設問すると、
僕はその問題に少しだけ詳しいので知っていることを説明します
あなたもご存知の通り、
風俗がオナニーよりなぜ気持ちいいのかという設問は長らく論争の的でした
いまだに決着していないといってもよいその議論は
とりもなおさず生命とは何かということの定義あるいは自己複製へのイデオロギー的確信に
世界中の科学者、研究者がこの人類に残された究極にして最後の謎、
暗い闇の中を手探り状態で開拓しはじめたのが今から70年程まえです
著者はサイモン・プライマー、題名が「断片の創造性にかかる自己複製への影響の解釈」という
この科学論文が英国科学研究機構に提出されたのが今から71年前のこと、
当時この論文にはさほど科学的に重大な発見が記されているとは思われていませんでした
そこに書かれていたのは、自己複製の連続性つまり人類の生命誕生における
遺伝子決定に関してたんぱく質が影響をおよぼす断片的な創造性の思想的な解釈でした
それはDNAの2重螺旋構造をセントラル・ドグマとした当時のある種流行とも呼べるテーマでした
この全体としていささかインパクトにかける無名の生物学者が書いた論文に
たった一行それはあまりにもさりげなくしかし後の科学にとっては非常に重要な示唆が挿入され
それをあくまで直感的に解釈するプライマーの言葉が短くしるされていました
それが以下、
私はこの等式記号がただちにオナニーの快感を否定するものではないことを承知するが
さしあたって風俗での射精との関連についての演算的なゴールであることを定義するものであること
でした。
ここに風俗とオナニーに関する科学史の始まりとそして同時に終末が同時に記されたのです。
あるいは当時この示唆はあまりにも大胆な飛躍ととられたのかもしれない。
しかし、このほんの小さな一陣の風の前に
一人の研究者が現れることで科学史は大きなうねりを持ち始めるのでした
意味はわからないかもしれませんけど、まだ始まったばかりですから
最終的に風俗がオナニーよりなぜ気持ち良いのか科学的に証明するところまで
行くのにあと３００レスは必要なんだしその頃には分かるんじゃないかと思います
ごめん終わらせちゃっていい？
天才だなお前
ちょっと待ってくれ。
>>37がやろうとしていることは生命科学だよな。
おまえがやろうとしているのは疑似科学だ。
捏造することもできない。
僕はそれを証明しようとしてるだけだし
それを疑似科学だとか言うならそもそも君の設問がナンセンスだってことになるよ
それに僕はオナニーでの射精から得られた精液から得られた微量のゲノムDNAサンプルと
風俗での射精から得られた精液から得られたゲノムＤＮＡサンプルのＲＣＡ解析の結果を2次元下で
モデル化することで余剰次元の素粒子標準の不明点は切り離せると考えてるし
あくまで演算的に設問を証明しようとしてるわけだから可視化の力学的性質だけで
検出できない微小なプロセスは物理的な効果も無視されるのがふつうだ。
君の考えていることとはベクトルがまるっきり逆だと思う
射精のメカニズムを解析するのではなく射精された精液に含まれるＤＮＡのふるまいによる
観察結果がおのずと回答を導くんだ。だから300レスで十分に証明可能なんじゃないか。
間違えたＰＣＲでの解析だ。ＲＣＡじゃヒッグス機構と階層性問題の内部対称性が示せない。
超対称性を取り入れた標準モデルの拡張性の大きな強みは、粒子とスーパーパートナーの
双方から仮想の寄与があるとき、超対称性によって仮想フェルミオンと仮想ボソンそれぞれの量子補正が
実現できるてことになるから。とにかくＲＣＡじゃなくてＰＣＲでの解析を比較します。
読んでて頭が割れそうだ。
週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい！と柄にもなく思ってしまった。
ここまで、日本語でウケを取り、アメリカ人にしか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・！
この人のセッション、ブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルのセッションに格上げされた。こんな人がいるとは。
で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ：
Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。
なんという激熱トーク。本当に小さかった南米のRubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で８０箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。
最後の時間オーバー後の「あと一言だけ（本当はあと１分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w）」でどんなにダメだとされていても、諦めずに進めという、過去の偉人が貶められたり失意にあった時代の動画もよかった（もっとも、この話は知っていたのでインパクト自体は薄めだった）。
この後はLTとクロージング。
インパクト強すぎｗ
これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと
真面目に受け取ったらヤバイ発言多すぎだろ・・・
こ れ が 締 め の 講 演 か よ ！
そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。
その後の高橋さんの最後の挨拶とスタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。
隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミングが大事！とすぱっと立ち上がってみてよかった。その後前列の人がみんな！立とうよ！みたいにやって一気に雪崩状態。
これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、
こんな一日だった。熱かった・・・
